panbanda/omen

Call-graph reports expose callresolutions (symbol) and input-wide
resolutionsummary (impact). These distinguish unique name candidates from
ambiguous and unresolved calls. Unique candidates are not compiler-proven
bindings; excluded edges do not establish that an edit is safe. See the
improvement standard and
measured results for limits and regression gates.
Your AI writes code without knowing where the landmines are.
Omen gives AI assistants the context they need: complexity hotspots, hidden dependencies, defect-prone files, and self-admitted debt. One command surfaces what's invisible.
Why "Omen"? An omen is a sign of things to come - good or bad. Your codebase is full of omens: low complexity and clean architecture signal smooth sailing ahead, while high churn, technical debt, and code clones warn of trouble brewing. Omen surfaces these signals so you can act before that "temporary fix" celebrates its third anniversary in production.
## Features
Complexity Analysis - How hard your code is to understand and test
There are two types of complexity:
Cyclomatic Complexity counts the number of different paths through your code. Every if, for, while, or switch creates a new path. A function with cyclomatic complexity of 10 means there are 10 different ways to run through it. The higher the number, the more test cases you need to cover all scenarios.
Cognitive Complexity measures how hard code is for a human to read. It penalizes deeply nested code (like an if inside a for inside another if) more than flat code. Two functions can have the same cyclomatic complexity, but the one with deeper nesting will have higher cognitive complexity because it's harder to keep track of.
Why it matters: Research shows that complex code has more bugs and takes longer to fix. McCabe's original 1976 paper found that functions with complexity over 10 are significantly harder to maintain. SonarSource's cognitive complexity builds on this by measuring what actually confuses developers.
> [!TIP]
> Keep cyclomatic complexity under 10 and cognitive complexity under 15 per function.
Self-Admitted Technical Debt (SATD) - Comments where developers admit they took shortcuts
When developers write TODO: fix this later or HACK: this is terrible but works, they're creating technical debt and admitting it. Omen finds these comments and groups them by type:
| Category | Markers | What it means |
| Design | HACK, KLUDGE, SMELL | Architecture shortcuts that need rethinking |
| Defect | BUG, FIXME, BROKEN | Known bugs that haven't been fixed |
| Requirement | TODO, FEAT | Missing features or incomplete implementations |
| Test | FAILING, SKIP, DISABLED | Tests that are broken or turned off |
| Performance | SLOW, OPTIMIZE, PERF | Code that works but needs to be faster |
| Security | SECURITY, VULN, UNSAFE | Known security issues |
Why it matters: Potdar and Shihab's 2014 study found that SATD comments often stay in codebases for years. The longer they stay, the harder they are to fix because people forget the context. Maldonado and Shihab (2015) showed that design debt is the most common and most dangerous type.
> [!TIP]
> Review SATD weekly. If a TODO is older than 6 months, either fix it or delete it.