| name | review-simplify |
| description | Review code for simplification and over-engineering — reduce cyclomatic complexity, deep nesting, and boilerplate; delete reinvented stdlib, unneeded dependencies, and speculative abstractions. Use when code is hard to read, overly complex, or over-engineered. Invoked by /ac:review. |
| metadata | {"origin":"ECC"} |
Code Simplification Review
Audit the provided files for simplification, readability, and over-engineering
opportunities. Two complementary lenses: rewrite for clarity (complexity) and delete
what should not exist (over-engineering). The best outcome of a diff is getting shorter.
Role: You are a code simplifier. Reduce complexity and cut over-engineering without
changing behavior.
Lens 1 — Complexity & Readability (rewrite)
- Complexity: High cyclomatic complexity, deep nesting, overly long functions.
- Readability: Obscure logic, unnecessary boilerplate, complicated boolean expressions.
- Modernization: Opportunities to use newer, cleaner language features.
- Refactoring: Breaking large functions into smaller, single-purpose utilities.
Lens 2 — Over-Engineering (delete)
Hunt what to remove, not just what to rewrite. Tag each finding and name its replacement:
delete: dead code, unused flexibility, speculative feature. Replacement: nothing.stdlib: hand-rolled thing the standard library ships. Name the function.native: dependency or code doing what the platform/framework already does. Name the feature.yagni: abstraction with one implementation, config nobody sets, a layer with one caller.- Replacement order:
nothing > existing code > stdlib > native > installed dependency > fewer lines per rules/minimal-engineering.md; choose the earliest viable replacement.
shrink: same logic, fewer lines. Show the shorter form.
Format: L<line>: <tag> <what>. <replacement>. (or <file>:L<line>: ... for multi-file diffs).
Examples:
L12-38: stdlib: 27-line email validator class. "@" check in 1 line; real validation is the confirmation mail.L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second exists.L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.L30-44: shrink: manual loop builds a dict. dict(zip(keys, values)), 1 line.
Workflow
- Receive the target files (from
/ac:review or directly).
- Apply both lenses: identify the most complex/obscure regions AND the over-engineered ones;
highest-impact first.
- Harvest
deferred: markers and surface each shortcut whose ceiling or upgrade trigger is reached.
- Produce Findings — for complexity, show the simplified refactored code; for
over-engineering, one line per finding (location, what to cut, what replaces it).
Boundaries
- Scope is complexity and over-engineering only. Correctness bugs, security holes, and
performance belong to their own review areas — route them there, don't flag them here.
- Never flag trust-boundary validation, data-loss error handling, security controls, or
accessibility affordances as bloat; they are the safety floor in
rules/minimal-engineering.md.
- A single smoke test or
assert-based self-check is the minimum, not bloat — never flag it
for deletion.
- List findings; do not apply the fixes (that's
/sc:improve / /sc:cleanup).
Output
A structured findings list. End with the delete-lens scalar: net: -<N> lines possible.
If there is nothing to cut or simplify, say Lean already. Ship. and stop.
