/simplify-code

name: simplify-code
description: "Review changed code for scope, reuse, quality, efficiency, clarity, and altitude issues, then fix them. Use when the user asks to \"simplify code\", \"clean up code\", 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 omit `name` on any Agent tool call it makes itself. Every agent's prompt must also 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. Every agent's prompt must also direct it to search the repository with a tool that skips gitignored files, such as `git grep --untracked` or the Grep tool, and to open or search a gitignored path only when its prompt or a file its prompt directs it to read names it, or when a dependency's installed source is needed to verify a claim, never one holding local configuration or credentials. For an empirical check that verifies a finding, the agent works in a copy of the checkout created at a uniquely named path of its own in the session scratchpad directory. Refer to that copy by absolute path in every command and join chained steps with `&&`, so a failed step cannot leave the rest running in the shared checkout. Give that copy its own dependency install rather than reaching the shared tree's install by any route. When its own install is not possible, the check is left unrun and reported as such. Before reporting, the agent deletes that copy, its dependency install included, as a command of its own, and confirms the path no longer exists. A copy it could not delete is named by path in its report. 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 file named for its review followed by a random tag, 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. 4. **Superseded implementation kept**: a new version added beside the one it replaces when every caller of the old version is inside this repository, often marked by a suffix such as `V2` or `New`. Recommend migrating the callers and deleting the old version. 5. **Tests in the wrong shape**: a production export, flag, or hook that exists only for a test to call, with no production caller and no public contract behind it. Recommend removing it and driving the test through a boundary production code already uses. For a test that repeats another test's contract, recommend folding its cases into that test. For an assertion on implementation (source text, import or export lists, private call shapes) that breaks under a behavior-preserving refactor, recommend rewriting it against observable behavior, unless it is the cheapest guard on a user-facing name, key, or path. Recommend these remedies rather than deleting a test outright.

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 checks above.

A