| name | simplify |
| description | Review changed code for reuse, quality, and efficiency, then clean up what you find — duplicated logic that could reuse an existing helper, hacky or redundant patterns, needless work on hot paths. Quality cleanup only: not bugs (that's code-review) and not behavior-preserving restructuring on request (that's refactor). Use when the user says "simplify", "clean this up", "is there a simpler way", or "tidy the diff". |
| allowed-tools | ["Bash","Read","Glob","Grep","Edit","Agent"] |
| argument-hint | [focus area] |
Simplify: quality cleanup on the changed code
Review the changed code for cleanups it would benefit from, then apply them. This
is the quality pass — reuse, hacky patterns, wasted work. It is not the bug
pass (code-review) and not a requested restructuring (refactor); stay in its
lane and don't report correctness bugs or propose structural rewrites here.
Phase 1: Identify changes
Run git diff (or git diff HEAD when changes are staged). With no git changes,
review the most recently modified files the user named or that you edited earlier
in this conversation.
Phase 2: Review across three lenses (in parallel)
Use the Agent tool to launch three reviewers concurrently in one message
(foreground). Give each the full diff. Each returns a short list of concrete,
located findings.
- Reuse. New code that duplicates an existing helper or utility; hand-rolled
logic (string munging, path handling, env checks, type guards) that the
codebase already has a function for. Point to the existing one to use instead.
- Quality. Redundant state that could be derived; parameter sprawl instead of
restructuring; near-duplicate blocks that should share an abstraction; leaky
abstractions; stringly-typed code where a constant/enum exists; needless wrapper
layers; conditionals nested 3+ deep (flatten with early returns or a lookup);
comments that narrate WHAT instead of non-obvious WHY.
- Efficiency. Redundant computation or repeated reads; independent work run
sequentially that could be parallel; new blocking work on a startup or
per-request hot path; unconditional no-op updates in loops/handlers (guard with
change detection); pre-checking existence before operating (TOCTOU); unbounded
growth or leaked resources; reading/loading far more than needed.
Phase 3: Apply the cleanups
Aggregate the findings and fix each directly. Keep each fix minimal and matched to
the file's existing style. If a finding is a false positive or not worth it, skip
it — don't argue with it. When done, briefly summarize what you cleaned up, or
confirm the code was already clean.
