Simplify Docs

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

Launch both agents below with spawn_agent / wait_agent using inherited model defaults, issuing every call in one batch. Do not issue one and await its result before issuing the rest. Pass the scope from Step 1 to each agent. Every sub-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.

Confine the sub-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 sub-agent weighs, such as "the file documents non-obvious third-party behavior". Leave out any statement that tells the sub-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 sub-agent to accept the very property the review exists to assess.

Both sub-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 AGENTS.override.md when one is present, otherwise its AGENTS.md — a directory's file governs only the files at or below it, and an override replaces that directory's AGENTS.md rather than adding to 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 directly, or deleting it when nothing else in the comment survives.
3. Restates code, signature, or name — paraphrases the immediately-following statement, a multi-statement block, a declaration's name, or the parameter/return shape. Includes doc blocks above a declaration whose prose elaborates the name and signature without adding rationale, and Parameters/Returns/Throws enumerations that only echo names and types. Flag only the redundant entries; non-obvious constraints (size, units, ranges, preconditions) stay. Drop the wrapping enumeration when no entries survive trimming. Where an instruction file or the documentation tooling's configuration requires that declaration to carry documentation, keep what the requirement covers and flag only entries that describe the code wrongly.
4. Narrates history or change — references PRs, tickets, prior behavior, recent changes, "fixed by"/"previously did X"/"no longer Y" framing, or session-narrative voice ("turns out", "discovered", "we found that"). State the current invariant; past behavior belongs in git history, and session-derived lessons about tooling belong in memories or AGENTS.md. Change narration also appears in invariant form: a sentence that reads as a rule but only carries meaning as a contrast with the code's prior behavior, and that you would not write if the code had been greenfield from day one.
5. Cross-references that decay — names the caller ("used by X", "called from Y"), or task/flow/feature-flag context the code was added for ("added for the Y flow", "for the rollout"). Delete: caller relationships belong in the call graph, feature context in the PR description.
6. Explains language or framework constructs — describes what a stdlib feature, language keyword, or well-known framework call does. Assume a competent reader.
7. Low-value section banners — banners that don't section anything, or that restate what an access modifier or naming convention already conveys. Idiomatic structural markers around a real section stay.
8. Overgrown rationale — a comment that captures real WHY but in more lines or concerns than the rationale requires. Tighten to one sentence per concern, split bundled concerns to their decision points, or lift shared rationale to a design doc or commit message.