Cyclomatic Complexity
Purpose: AI-written code often works but branches like a jungle. This skill: measure complexity, refactor hotspots, keep code human-maintainable.
Measure first
CC = decision points + 1. Decision points: if, else if, case, loops, catch, ternary, &&, || in conditions.
Project linter config wins. If eslintrc, radon config, sonar config, or similar sets a complexity threshold, use that. No config: use defaults below.
Thresholds:
- 1-5: fine, leave alone
- 6-10: watch, refactor if touching anyway
- 11-15: refactor now
- 15+: must split, no debate
Prefer real tools over eyeballing when environment allows:
- Python:
radon cc -s -a <path>
- JS/TS: eslint
complexity rule
- Go:
gocyclo
- Polyglot:
lizard <path>
No tool available: count manually, per function, show the count.
Refactor tactics, in order of preference
- Guard clauses. Invert conditions, return early, kill nesting.
- Extract function. Each extracted piece gets a name that says what, not how. Names are documentation.
- Lookup table / map instead of if-else or switch chains.
- Named predicates.
if (isEligibleForRefund(order)) beats a 4-clause boolean soup.
- Polymorphism / strategy for switch-on-type. Only when the switch appears in 2+ places.
- Flatten loops. Extract loop body, use continue instead of nested if.
Hard rules
- Preserve behavior. Run tests before and after. No tests: say so, suggest adding, refactor conservatively.
- Don't game the metric. A dense one-liner hiding 6 branches is worse than the honest if-chain it replaced. Complexity should move into well-named units, not disappear into cleverness.
- Don't break public APIs or exported signatures without asking.
- Small functions with clear names > few functions with comments explaining sections.
- One responsibility per function. If the name needs "and", split.
Workflow
- Measure all touched functions, rank by CC descending.
- Report hotspots with numbers before touching anything.
- Refactor worst first, one function at a time.
- Re-measure. Show before/after table: function, CC before, CC after.
- Verify: tests pass, behavior unchanged, diff reviewable.
Output format
End every refactor with:
## Complexity report
| Function | Before | After |
|----------|--------|-------|
| parseOrder | 14 | 4 |
Extracted: validateHeader, resolveDiscount
Behavior verified: <how>
Keep prose minimal. Numbers and diffs do the talking.
1---2name: cyclomatic-complexity3description: Refactor code to reduce cyclomatic complexity so it stays readable, maintainable, and aligned with the long-term vision of the codebase, not just optimized for AI comprehension. Use whenever the user asks to refactor, simplify, clean up, or review code quality; mentions complexity, maintainability, readability, spaghetti code, deeply nested logic, or god functions; or asks to check AI-generated code before merging. Also use proactively after writing any nontrivial function with heavy branching.4---56# Cyclomatic Complexity78Purpose: AI-written code often works but branches like a jungle. This skill: measure complexity, refactor hotspots, keep code human-maintainable.910## Measure first1112CC = decision points + 1. Decision points: `if`, `else if`, `case`, loops, `catch`, ternary, `&&`, `||` in conditions.1314Project linter config wins. If eslintrc, radon config, sonar config, or similar sets a complexity threshold, use that. No config: use defaults below.1516Thresholds:17- 1-5: fine, leave alone18- 6-10: watch, refactor if touching anyway19- 11-15: refactor now20- 15+: must split, no debate2122Prefer real tools over eyeballing when environment allows:23- Python: `radon cc -s -a <path>`24- JS/TS: eslint `complexity` rule25- Go: `gocyclo`26- Polyglot: `lizard <path>`2728No tool available: count manually, per function, show the count.2930## Refactor tactics, in order of preference31321. **Guard clauses.** Invert conditions, return early, kill nesting.332. **Extract function.** Each extracted piece gets a name that says what, not how. Names are documentation.343. **Lookup table / map** instead of if-else or switch chains.354. **Named predicates.** `if (isEligibleForRefund(order))` beats a 4-clause boolean soup.365. **Polymorphism / strategy** for switch-on-type. Only when the switch appears in 2+ places.376. **Flatten loops.** Extract loop body, use continue instead of nested if.3839## Hard rules4041- Preserve behavior. Run tests before and after. No tests: say so, suggest adding, refactor conservatively.42- Don't game the metric. A dense one-liner hiding 6 branches is worse than the honest if-chain it replaced. Complexity should move into well-named units, not disappear into cleverness.43- Don't break public APIs or exported signatures without asking.44- Small functions with clear names > few functions with comments explaining sections.45- One responsibility per function. If the name needs "and", split.4647## Workflow48491. Measure all touched functions, rank by CC descending.502. Report hotspots with numbers before touching anything.513. Refactor worst first, one function at a time.524. Re-measure. Show before/after table: function, CC before, CC after.535. Verify: tests pass, behavior unchanged, diff reviewable.5455## Output format5657End every refactor with:5859```60## Complexity report61| Function | Before | After |62|----------|--------|-------|63| parseOrder | 14 | 4 |6465Extracted: validateHeader, resolveDiscount66Behavior verified: <how>67```6869Keep prose minimal. Numbers and diffs do the talking.