Overengineering Review

Overengineering Review

Review only for unnecessary complexity. This skill does not hunt general correctness issues unless they directly affect the simplification recommendation.

Pair With

• Use minimal-diff-builder when the user wants the simplification findings turned into the smallest correct patch.
• Use complexity-optimizer instead when the real question is performance or algorithmic cost rather than architectural bloat.
• Use architecture-deepening-review instead when the code is not overbuilt but the boundary design is still wrong.

Review Surface

Look for:

• needless abstractions;
• replaceable dependencies;
• dead flexibility;
• wrappers around stdlib or native platform features;
• local helpers or files that only forward to something simpler;
• speculative extension points with one caller or one implementation.

Findings Taxonomy

Use these tags:

• delete: code or layer can disappear entirely.
• stdlib: custom logic should be replaced by a standard-library primitive.
• native: use built-in platform behavior instead of app code or dependency code.
• existing-dep: repo already ships a dependency that makes the extra code unnecessary.
• yagni: speculative abstraction or configurability with no present payoff.
• shrink: same behavior, fewer moving parts.

Workflow

1. Determine scope:

• diff review;
• file review;
• broad repo audit.

1. Ignore style nitpicks that do not reduce real complexity.
2. Rank findings by payoff:

• dependency removal;
• file/layer deletion;
• abstraction collapse;
• line-count shrink.

1. For each finding, capture:

• location;
• tag;
• what is overbuilt;
• what replaces it;
• why the simpler path still covers the requirement;
• any safety caveat.

1. Keep findings review-grade:

• specific;
• actionable;
• minimal prose;
• no vague "this feels complex" commentary.

Output Format

One finding per line in ranked order:

:L . . .

End with one compact summary line:

net: - lines, - files, - deps possible.

If nothing meaningful should be cut:

Lean already. Ship.

Boundaries

• Do not recommend deleting trust-boundary validation, security checks, accessibility basics, or data-loss prevention.
• Do not turn the review into a broad bug hunt.
• Do not apply changes unless the user explicitly asks for implementation after review.
• Treat one focused regression test or self-check as acceptable minimum discipline, not bloat.

Final Report

When a normal prose review is needed, convert the ranked list into:

• findings ordered by impact;
• top simplification opportunities;
• residual caveats where the simpler path only works under current scope.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: markoblogo
• Source: markoblogo/abvx-agent-skills
• License: MIT
• Homepage: https://abvx.xyz/work/abvx-agent-skills

Install and usage instructions live in the source repository linked above.