| name | simplify-code |
| description | Review the recently changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs. Use when the user asks to simplify, refine, tidy, clean up, or improve the readability/maintainability of code they just wrote or changed. |
Simplify Code
Refine recently modified code for clarity, consistency, and maintainability while preserving exact
behavior. This is a quality pass, not a bug hunt — if you spot a real bug, note it separately but do not
try to fix bugs here.
Prefer readable, explicit code over clever or overly compact code. Fewer lines is not the goal; clarity is.
Workflow
- Scope the diff. Look only at code changed in the current session / working tree, unless the user names
a broader scope. Use
git diff (and git diff --staged) to find what changed. Do not touch unrelated code.
- Read for opportunities along these axes (in priority order):
- Reuse — replace duplicated or reinvented logic with existing helpers/utilities already in the repo.
- Simplification — cut needless complexity, nesting, dead code, and redundant abstractions; consolidate
related logic; give variables/functions clearer names; drop comments that just restate the code.
- Efficiency — remove obviously wasteful work (repeated computation, needless allocations/passes) when
it doesn't hurt readability.
- Altitude — keep each function at one level of abstraction; don't mix high-level flow with low-level detail.
- Apply the fixes directly to the files (this skill edits, it doesn't just advise).
- Preserve behavior. All original outputs, side effects, and edge cases must remain identical. If a change
would alter behavior, don't make it — flag it instead.
- Verify. Re-read the edited code; if the project has a fast check (formatter/linter/type-check/tests for
the touched files), run it. Report what you ran and its result — never claim success without evidence.
- Summarize only the significant changes (what and why), not cosmetic noise.
Rules
- Preserve functionality above all — never change what the code does, only how.
- Avoid nested ternaries. Use
if/else chains or a switch/match for multiple conditions.
- Match the surrounding code: its naming, idioms, comment density, and the project's documented standards
(e.g. CLAUDE.md / AGENTS.md if present).
- Don't over-simplify: keep helpful abstractions, don't merge unrelated concerns into one function, don't
produce dense one-liners that are hard to debug or extend.
- Stay in scope: recently changed code only, unless told otherwise.
Project-specific standards (extend here)
(none yet — add project or personal conventions here)
Custom checks (extend here)
(none yet)
