Simplify Code

Simplify Code — Sequential Review & Cleanup

Review your recent code changes with three focused lenses, aggregate findings, and apply the fixes worth applying.

Core principle: Three narrow reviews beat one broad review. Each one deeply searches the codebase for a single class of problem — reuse, quality, efficiency — without diluting attention across all three.

Poirot note: The original skill runs 3 reviewers in parallel via subagent delegation. Poirot has no subagents, so this version runs the 3 lenses sequentially in the same context. The methodology is identical; only the concurrency is lost.

When to Use

Trigger this skill when the user says any of:

• "simplify" / "simplify my changes" / "simplify these changes"
• "review my code" / "review my recent changes" / "clean up my changes"

Optional modifiers the user may add — honor them:

• Focus: "simplify focus on efficiency" → run only the efficiency lens. Recognized focuses: reuse, quality, efficiency.
• Dry run: "simplify but don't change anything" / "just report" → run the three lenses, present findings, apply NOTHING. Ask before applying.
• Scope: "simplify the last commit" / "simplify staged" / "simplify src/foo.py" → narrow the diff source accordingly.

Do NOT auto-run this after every edit. Invoke it only when the user asks.

The Process

Phase 1 — Identify the changes

Capture the diff to review. Pick the source by what the user asked for:

# 1. Default: uncommitted working-tree changes (tracked files)
git diff

# 2. If that's empty, include staged changes
git diff HEAD

# 3. Scoped variants:
git diff --staged                 # "staged changes"
git diff HEAD~1                    # "the last commit"
git diff main...HEAD              # "this branch" / "my PR"
git diff -- src/foo.py            # specific file(s)

If git diff and git diff HEAD are both empty, fall back to files the user explicitly named or recently edited in this session. If you can't find any changed code, say so and stop.

Capture the full diff text. Note its size: if >2000 changed lines, warn the user and offer to scope down before proceeding.

Phase 2 — Run three lenses (sequentially)

Each lens gets the complete diff (not fragments — cross-file issues hide in the gaps) plus the repo path so it can search the wider codebase via bash (grep) and read_file.

For each lens:

• Search the existing codebase for evidence (don't reason from the diff alone).
• Apply Chesterton's Fence: before flagging anything for removal, run git blame on the line to understand why it exists. If you can't determine the original purpose, mark it confidence: low.
• Report findings as structured output:

  file:line → problem → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY

  • SAFE = proven not to affect behavior (unused imports, commented-out code, pass-through wrappers). Auto-apply these.
  • CAREFUL = improves without changing semantics (rename local variable, flatten nested ternary, extract helper). Apply with test verification.
  • RISKY = may change behavior or breaks public contracts. Flag for human review — do NOT auto-apply.
• Skip nits and style-only churn.

Run these three lenses (skip any the user's focus excludes):

Lens 1 — Code Reuse

Review this diff for code that duplicates functionality already in the codebase. Search utility modules, shared helpers, and adjacent files (use bash grep) for existing functions, constants, or patterns the new code could call instead of reimplementing. Flag: new functions that duplicate existing ones; hand-rolled logic that an existing utility already does. For each, name the existing thing to use and where it lives.

Lens 2 — Code Quality

Review this diff for quality problems. Look for: redundant state; parameter sprawl; copy-paste-with-variation; leaky abstractions; stringly-typed code (raw strings where a constant/enum exists); AI-generated slop patterns (extra comments restating obvious code, unnecessary defensive null-checks, as any casts). For each, give the concrete refactor.

Lens 3 — Efficiency

Review this diff for efficiency problems. Look for: unnecessary work (redundant computation, repeated file reads, N+1 access); missed concurrency; hot-path bloat; TOCTOU anti-patterns; memory issues (unbounded growth, missing cleanup); overly broad reads; silent failures (empty catch blocks, except: pass). For each, give the concrete fix and why it's faster/safer.