/simplify-docs

name: simplify-docs
description: "Review code comments and markdown docs for noise, misdescriptions, and stale content, then fix them. Use when the user asks to \"simplify docs\", \"clean up comments\", or \"fix stale comments\"."

Simplify Docs

Review code comments and markdown documentation for unnecessary content, then fix the issues.

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, default to a full-tree sweep of source files plus top-level markdown.

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 Two Review Agents in Parallel

Emit both 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 prose as a fact the agent weighs, such as "the file documents non-obvious third-party behavior". Leave out any statement that tells the agent what verdict to reach about that property, such as "the file is deliberately comment-dense, judge against that established bar", because it binds the agent to accept the very property the review exists to assess.

Both agent prompts must also carry the readability criteria below and the constraint that follows them, applied to the prose that survives that agent's own list:

1. **Clause stacking** — a sentence carrying more than one idea. Split it when the clauses make independently useful points. Count ideas rather than propositions. 2. **Punctuation chains** — a second em dash, colon, or semicolon continuing the thought. Split the sentence. A `- **Term** — description` label separator is not a chain. 3. **Dense paragraphs** — facts running together past the point a reader can hold them apart. Break into shorter sentences, keeping the passage as prose rather than converting it to a bullet list.

Every split above keeps its connectives. Leave clauses joined when their relationship is the point (cause and effect, condition and consequence, contrast, qualification, scope) and separating them would make the reader rebuild the connection.

Agent 1: Code Comments Review

Review code files in scope. Beyond the auto-loaded instruction files, walk each directory that is an ancestor of a reviewed file, from the project root down, and read its `CLAUDE.md` and any file those instructions import — a directory's file governs only the files at or below it. Flag a comment when it misdescribes the code, or when it adds no information beyond what the code already says:

1. **Asserts a contract the code does not enforce** — states what is handled, excluded, guaranteed, or left untouched, where the code beneath it does something else. Verify each such claim against the code rather than reading it as intent. Propose correcting the comment, or flag the missing enforcement when the stated contract is the desired one. Check this before the redundancy criteria in this list. 2. **Positional reference that no longer resolves** — carries an ordering or directional word such as "first", "above", or "below" whose target the code has since moved. Verify the word still picks out what it names. Propose correcting it to name what it refers to