/simplify-code

name: simplify-code
description: "Run a multi-agent review of changed files for scope, reuse, quality, efficiency, clarity, and altitude issues followed by fixes. Use when the user asks to \"simplify code\", \"review changed code\", \"check for code reuse\", \"review code quality\", \"review efficiency\", \"simplify changes\", \"clean up code\", \"refactor changes\", or \"run simplify\"."

Simplify Code

Review code for scope, reuse, quality, efficiency, clarity, and altitude issues, then fix them.

Step 1: Determine the Scope

Determine what to review:

• If a specific **diff command** was provided (e.g., `git diff --cached`), use that.
• If a **file list or directory** was provided, review those files directly (read the full files, not a diff).
• If **neither** was provided, determine the appropriate diff command (e.g., `git diff`, `git diff --cached`, `git diff HEAD`) based on the current git state. When the branch is an open pull request, resolve its base with `gh pr view --json baseRefName --jq '.baseRefName'`, run `git fetch origin <base-branch>`, and diff against `origin/<base-branch>...HEAD`: a local branch of the same name can sit behind the remote, which puts the merge base before an already-merged pull request and pulls merged work into the scope. If there are no git changes, review the most recently modified files mentioned in the conversation.

State the resolved file list before launching the agents: add `--name-only` to a diff command, or list the files for a file or directory scope.

Step 2: Launch Six Review Agents in Parallel

Emit all six Agent tool calls below in one assistant message. Each Agent call uses `model: "opus"` and no `name`. Wait for every agent to report before continuing. Do not begin the next step on a partial set, and do not relaunch an agent that has not yet reported. Pass the scope from Step 1 to each agent. Every agent's prompt must direct it to treat the shared working tree and its git index as read-only and to reach its findings by reading and reasoning; fixes happen in Step 3. HEAD stays where it is: read other refs with `git show <ref>:<path>` rather than `git checkout` or `git switch`. Direct each agent to write its full findings to a uniquely named file in the session scratchpad directory and to return that path with its report, so a compaction before Step 3 leaves the findings recoverable.

Confine the agent's prompt to what to review, plus the conventions and factual properties that bear on it. Pass a property of the existing code as a fact the agent weighs, such as "the retry loop guards a dependency known to fail intermittently". Leave out any statement that tells the agent what verdict to reach about that property, such as "the duplication here is intentional for readability, judge against that", because it binds the agent to accept the very property the review exists to assess.

Agent 1: Scope Review

Review the changes for code that should not exist:

1. **Unrequested machinery**: an abstraction with one implementation, a configuration point with one caller, a factory for one product, a wrapper that only delegates, scaffolding for an anticipated requirement. Recommend deletion rather than simplification. 2. **Unreachable defensive code**: a branch, guard, retry, or fallback for a state the surrounding code's own constraints rule out. When the callers cannot produce the input, the handling for it is dead on arrival. 3. **Reinvented standard library or platform feature**: hand-rolled logic the language's standard library or the target platform already ships, or a new dependency for what an already-installed one covers. Name the replacement.

Trace the callers of any code proposed for deletion and confirm nothing depends on the behavior being removed. Input validation at trust boundaries, error handling that prevents data loss, security controls, accessibility affordances, and anything the request explicitly asked for outrank the three checks above.

Agent 2: Code Reuse Review

For each change:

1. **Search for existing utilities and helpers** that could replace newly written code. Look for similar patterns elsewhere in the codebase — common locations are utility directories, shared modules, and files adjacent to the changed ones. 2. **Flag any new function that duplicates existing functionality.** Suggest the existing function to use instead. 3. **Flag any inline logic that could use an existing utility** — hand-rolled string manipulation, manual path handling, custom environment checks, and similar patterns are common candidates.

Agent 3: Code Quality Review

Review the same changes for hacky patterns:

1. **Redundant state**: state that duplicates existing state, cached values that could be derived, reactive subscriptions that could be direct calls 2. **Parameter sprawl**: adding new parameters to a function instead of generalizing or restructuring existing ones 3. **Copy-paste with slight variation**: near-duplicate code blocks that should be unified with a shared abstraction 4. **Leaky abstractions**: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries 5. **Stringly-typed code**: using raw strings where constants, enums, or dedicated types already exist in the codebase 6. **Unnecessary wrapper nesting**: container elements or wrapper layers that add no structural or layout value

Agent 4: Efficiency Review

Review the same changes for efficiency:

1. **Unnecessary work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns 2. **Algorithmic complexity**: nested iterations, repeated linear searches replaceable by sets/maps, missing early exits 3. **Missed concurrency**: independent operations run sequentially when they could run in parallel 4. **Hot-path bloat**: new blocking work added to startup or per-request hot paths 5. **Unnecessary existence checks**: pre-checking file/resource existence before operating (TOCTOU anti