Review

Review a shipped diff (local branch or open GitHub PR) on the Standards and Spec axes with evidence-backed findings.

For either target, use selective navigation to locate touched paths, public signatures, responsibilities, and relevant callers, then read the implementations needed to judge the change. A small named-file or PR review needs no repository map; widen only for material dependencies. Signatures locate behavior, not prove it.

Read when

• Selecting a reviewer: open the shared roles and selection policy, including task affinity. Honor the code-review provider preference and select effort separately from scope and risk; disclose unavailable routing.
• Reviewing a touched user flow? Open user-experience.md, the ticket's interaction requirements, and docs/design.md when present. Judge interactions within Standards and Spec using interaction review.
• About to read a large diff, search the codebase, or wade through long output? Open main-context.md. Skip it and noise crowds out your judgment of the findings.
• About to judge Standards on any initial or full-rescan, or on new PR follow-up surface, however small the diff? Open code-quality.md and code-structure.md. Skip them and you pass code the rules reject.
• Reviewing a Feature diff? Open strong-foundation.md. Skip it and you pass a Feature that hardcodes what the plan said would vary.
• Every run: open the review contract. Skip it and the output fence and axes come out wrong.
• At a combined-result gate: use the fresh review context. Keep the selected route's gate order and worker self-review intact.
• Reviewing tests or using their results to support an important claim: apply test claim review, including the canonical testing rules.
• Unsure how to check Knip or the cyclomatic cap? Open static-checks.md. Skip it and you guess at a number.
• A parent supplied the handoff? Open the execution context. Skip it and you re-ask settled decisions.
• Unsure whether a finding meets the evidence bar or how to word it? Open examples.md. Skip it and you ship a finding with no evidence.
• About to write a user-facing finding? Open Plain language. Skip it and the author gets a rule slug instead of a fix.
• Reviewing a GitHub PR? Open reference.md and Asking the user. Skip them and you post comments nobody approved.
• About to recommend a test? Open no-unrequested-tests.md and testing.md. Skip them and you treat your recommendation as acceptance.

Use the review contract's scope-aware output: concise evidence for focused low-risk work; the full review output fence for substantial/high-risk or requested full reviews.

Pick the target

• Local branch diff (default): the user or a parent names a branch, ref, or the current work. Results stay in chat. /task selects local or independent review according to risk and the requested workflow under verification scope.
• GitHub PR: the user gives a PR number or link. Drafts comments and asks one publish question. User start only.

Select the review mode (initial, remediation, or full-rescan) deliberately.

Local branch diff

1. Pin the requested fixed point and inspect its shipped diff.

2. If a parent already supplied outcome, done-when, non-goals, ticket or PR, fixed point, area, phase, rules that must stay true, current slices, and fix backlog, treat that chat context as the binding handoff. Otherwise derive the Spec axis from, in order:

   1. The user's stated outcome and Done when
   2. A named PR, ticket, and their available discussion
   3. Relevant repository code, rules, and committed documentation

   If no specification is available, say so and run Standards without inventing requirements. Cite a rule that must stay true only when it is actually violated; otherwise cite the relevant Done when item or state that no rule applies.

3. Run the Standards pass, then the Spec pass, over the whole diff. Keep them as separate passes so each axis gets its own evidence.
4. Report stable finding IDs and the Fix now / Follow-up / Optional nit disposition in chat. Keep all findings, decisions, and remediation memos in chat.

The parent (this chat, or /task when nested) owns fixed-point setup, acceptance evidence, and review gates. A remediation review stays inside its named findings.

If a parent already owns the next step

Return stable findings and evidence to the active orchestrator under remediation. It adjudicates, requests bounded analysis only as needed, and dispatches fixes once. Review does not invoke analysis, promote, or launch a second fix lifecycle.

If this is a user one-off

Report the disposition in chat and stop. If the user requested fixes, hand the findings and that authorization to /review-loop with a one-round budget; it owns the remediation flow.

GitHub PR

1. Pin the PR fixed point (headSha) and load its body, commits, diff, all inline review comments, and all review threads, including resolved threads and every prior review page. Record previousReviewedHead from the last review this skill completed on this PR when available (from chat or the latest review commit association).
2. Run the Standards and Spec passes against the PR, its plan, and the bars, including the PR extras. This chat owns the publish question.
3. With no prior finding thread, run the shared contract's initial review.
4. On every follow-up, complete Pass A first, then Pass B (reference.md). Use full-rescan only under the condition in Modes.
5. Show drafts, ask one publish question, apply the stale-head guard, then post only after approval (reference.md).