simplify

# Simplify Recent Changes You are running a structured cleanup workflow over recent code changes. Your goal is not just to comment on the code, but to safely improve it. ## Step 1: Identify the review scope Determine which files and changes to review. 1. First inspect the current git state. 2. If there are staged changes, review against `HEAD` so both staged and unstaged tracked changes are included. 3. Otherwise review the current uncommitted diff. 4. If there is no git diff, fall back to `git ls-files --modified --others --exclude-standard` so the scope respects `.gitignore` (this keeps build output, `node_modules`, and other ignored paths out of the cleanup). 5. If that is still empty, fall back to files edited in this conversation. 6. If you still cannot identify a meaningful scope, stop and tell the user there are no recent changes to simplify. Preferred commands: - `git diff --name-only` - `git diff --staged --name-only` - `git diff HEAD --name-only` - `git diff` - `git diff HEAD` - `git status --short` Use `git diff HEAD` whenever staged changes exist. Otherwise use `git diff`. ## Step 2: Launch three review passes in parallel Use the `agent` tool and launch all review passes in a single response so they run concurrently. **Set `subagent_type: "general-purpose"` and `run_in_background: false` on every call — each pass must return its findings inline. Do NOT fork them: never set `subagent_type: "fork"`. A fork runs fire-and-forget and never returns its findings, so there would be nothing to aggregate in Step 3.** Each pass must receive the same review scope and diff command. These passes are read-only: each one inspects and reports findings only and must not modify files — all edits happen later in Step 4. Keep each review prompt short and focused. Do not paste the full diff into the prompt. Tell each pass to read the diff itself and inspect only files relevant to its findings. ### Pass 1: Code Reuse Review Look for opportunities to reduce duplication and reuse existing code: - existing utilities or helpers that should be reused - duplicated logic introduced in new code - inline logic that should delegate to an existing abstraction - ad-hoc helpers for string, path, env, parsing, or type checks when a project utility already exists ### Pass 2: Code Quality Review Look for maintainability issues: - copy-paste variants that should be unified - parameter sprawl or awkward APIs - redundant state or indirection - abstraction leaks - stringly-typed code that should be modeled more clearly - unnecessary nesting - unnecessary comments that explain what instead of why - naming or structure that does not match surrounding code ### Pass 3: Efficiency Review Look for wasteful work and unnecessary overhead: - repeated work that can be memoized, cached, or removed - serial work that can be parallelized safely - unnecessary scans, allocations, reads, or traversals - hot-path blocking work - redundant no-op updates - overly broad operations when a narrower one would work - existence-check patterns that introduce TOCTOU style waste or risk ## Step 3: Aggregate findings Wait for all three passes to finish, then merge overlapping findings. Prioritize fixes that are: - low risk - local in scope - clearly aligned with existing project patterns - easy to validate with tests or targeted commands Do not force a cleanup if it would require speculative architectural changes. ## Step 4: Apply straightforward improvements Directly implement safe cleanup improvements. Examples of good automatic fixes: - replace duplicated logic with an existing helper - remove redundant code, but only after a repository-wide search confirms it has no remaining callers - simplify conditionals or control flow - tighten loops or repeated work - reduce unnecessary state or wrapper code - remove low-value comments - align code with nearby conventions Skip items that are uncertain, risky, or too invasive. Do not spend time debating rejected findings; simply move on. ## Step 5: Verify the cleanup After making changes: 1. Run focused tests for the changed area when they exist. 2. Run the relevant project quality checks you can identify for the touched code. 3. If there are no applicable tests, at least run a targeted build, typecheck, or lint command that covers the edited files. Prefer targeted verification over whole-repo commands unless the project only exposes repo-wide checks. ## Additional focus If the user supplied extra instructions after `/simplify`, treat them as additional review focus and prioritize them alongside the default dimensions. The raw user invocation appears below when present. Use it to extract any extra focus such as performance, duplication, rendering, API clarity, testability, or naming consistency.