/review-code

name: review-code
description: "Review code for bugs, security, API misuse, consistency, simplicity, or test coverage, with peer review in parallel. Use when the user asks to \"review my code\", \"check for bugs\", or \"security audit\"."

Review Code

Review code against type-specific criteria. Runs internal reviews and `/peer-review` in parallel by default. Returns combined structured findings.

**Types:** `correctness`, `security`, `api-usage`, `consistency`, `simplicity`, `coverage`, `intent`

With a type argument, runs a single-concern internal review plus the peer review. With no type argument, runs every internal review except `intent` plus the peer review, and the `intent` review as well when a governing document resolves.

Step 1: Determine the Scope

Determine what to review:

• If a specific **diff command** was provided (e.g., `git diff --cached`, `git diff origin/main...HEAD`), 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, default to diffing against the repository's default branch (detect via `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`). If there are no changes against the default branch, stop and state that there is nothing to review.

State the resolved file list before continuing: add `--name-only` to a diff command, or list the files for a file or directory scope. When the scope is a staged diff, also state how many further files `git diff HEAD --name-only` reports, so a scope narrower than intended stays visible before fanning out.

In full review, or when `intent` is the type argument, determine the governing document, which states what the change was asked to do: a plan file, an approved change description, or an issue. Use the one provided, as a path, a URL, or text. When it is a URL, fetch its content and use that text. When none was provided, take a plan file or an approved change description that governs the reviewed work from conversation context. State the document that resolved, or that none did and the intent review is skipped. When `intent` was the type argument and no document resolved, stop and state that the intent review needs one.

Step 2: Run Reviews in Parallel

Each active type maps to a criteria reference file:

• **Correctness** — [references/correctness-review.md](references/correctness-review.md)
• **Security** — [references/security-review.md](references/security-review.md)
• **API usage** — [references/api-usage-review.md](references/api-usage-review.md)
• **Consistency** — [references/consistency-review.md](references/consistency-review.md)
• **Simplicity** — [references/simplicity-review.md](references/simplicity-review.md)
• **Coverage** — [references/coverage-review.md](references/coverage-review.md)
• **Intent** — [references/intent-review.md](references/intent-review.md)

Full review activates every type except intent, and intent as well when Step 1 resolved a governing document; a single-concern argument activates one. Skip peer review when instructed (e.g., "without peer review", "no peer", "internal only").

Before dispatching, read the project's test configuration and CI workflow to identify any test tier that resets a shared external resource between tests, such as a database, a fixed port, or a cache. Such tiers have no cross-process interlock, so agents running them concurrently wipe each other's state and return failures indistinguishable from defects in the change. Name any such tier to every agent as off-limits when the review does not depend on running it. When the change under review is what that tier exists to exercise, so that judging it at all requires running the tier, direct each agent instead to provision its own isolated instance of the resource, prepare it through the project's own setup path, run against it, and tear it down afterward. One shared instance carrying an instruction to run a single agent at a time is not sufficient, since nothing enforces that across agents. When an agent's own instance cannot be provisioned, the tier is left unrun and reported as such.

Direct every agent that runs a test suite to redirect the runner's output to a file in its own scratch directory and read the file. Piping a runner to `head`, `tail`, or another command that closes the stream early returns while the runner is still going, so an agent that believes its run finished leaves one live to overlap the next agent's.

When the scope contains a guard whose safety rests on an assumption stated in the conversation, in a plan file, or in a code comment, give every agent that assumption as the claim to refute rather than as background.

When the scope contains content that a build or render transform rewrites before it ships — markup compiled to components, template expansion, code generation, translation extraction — build the project before dispatching, in an isolated `git worktree` under `$TMPDIR` when the build writes to tracked files or reaches the shared install through a package-manager wrapper, and name the emitted files as part of the scope every agent receives, so each type judges the emitted artifact rather than the source. Refer to that worktree by absolute path in every command and join chained steps with `&&`, so a failed step cannot leave the rest running in the shared checkout. Once every agent has reported, remove that worktree as a command of its own and confirm that `git worktree list` no longer shows it and its path no longer exists. Name a worktree that could not be removed in the output.

Confine each agent's prompt to what to review, plus the conventions and factual properties that bear on it. A statement that tells an agent what verdict to reach about a property of the existing code binds it to accept the very property the review exists to assess.

When this session edited an instruction file or a file one imports, name it in every agent's prompt and direct the agent t