review

Review

Perform a two-axis review of the diff between HEAD and the fixed point provided by the user:

Two-axis review of the diff between HEAD and a fixed point the user supplies:

• Standards — does the code follow the coding conventions documented in this repository?

  Standards — does the code conform to this repo's documented coding standards?

• Spec — does the code faithfully implement the original issue / PRD / spec?

  Spec — does the code faithfully implement the originating issue / PRD / spec?

The two axes run asparallel sub-agents , so they do not pollute each other's context, and then this skill aggregates their findings.

Both axes run as parallel sub-agents so they don't pollute each other's context, then this skill aggregates their findings.

The issue tracker should already have been provided to you — if docs/agents/issue-tracker.md is missing, run /setup-matt-pocock-skills。

The issue tracker should have been provided to you — run /setup-matt-pocock-skills if docs/agents/issue-tracker.md is missing.

Process

1. Pin down the fixed point

Whatever the user says as the fixed point — commit SHA, branch name, tag,main、HEAD~5 , etc. Do not have opinions; just pass it through. If the user did not specify, ask: "Review against what baseline — a branch, a commit, or main?" Do not continue until you get it.

Whatever the user said is the fixed point — a commit SHA, branch name, tag, main, HEAD~5, etc. Don't be opinionated; pass it through. If they didn't specify one, ask: "Review against what — a branch, a commit, or main?" Don't proceed until you have it.

Capture the diff command once:git diff <fixed-point>...HEAD(three dots, so the comparison is against the merge-base). Also record the commit list via git log <fixed-point>..HEAD --oneline .

Capture the diff command once: git diff <fixed-point>...HEAD (three-dot, so the comparison is against the merge-base). Also note the list of commits via git log <fixed-point>..HEAD --oneline.

2. Determine the spec source

Look for the original spec in the following order:

Look for the originating spec, in this order:

1. Issue references in commit messages (#123、Closes #45、GitLab !67 , etc.) — fetch via the workflow in docs/agents/issue-tracker.md .

   Issue references in the commit messages (#123, Closes #45, GitLab !67, etc.) — fetch via the workflow in docs/agents/issue-tracker.md.

2. A path passed by the user as an argument.

   A path the user passed as an argument.

3. docs/、specs/ or .scratch/ under a PRD/spec file matching the branch name or feature.

   A PRD/spec file under docs/, specs/, or .scratch/ matching the branch name or feature.

4. If nothing is found, ask the user where the spec is. If the user says there is none, thespecsub-agent will skip and report "no spec available".

   If nothing is found, ask the user where the spec is. If they say there isn't one, the Spec sub-agent will skip and report "no spec available".

3. Determine the standards source

Anything in the repository that documents how code is written. Common locations:

Anything in the repo that documents how code should be written. Common locations:

• CLAUDE.md、AGENTS.md
• CONTRIBUTING.md
• CONTEXT.md、CONTEXT-MAP.md, the CONTEXT.md file for each context
• docs/adr/(architecture decisions are also standards)

  docs/adr/ (architectural decisions are standards)

• .editorconfig、eslint.config.*、biome.json、prettier.config.*、tsconfig.json(machine-enforced standards — record them but do not re-check what the tools already check)

  .editorconfig, eslint.config.*, biome.json, prettier.config.*, tsconfig.json (machine-enforced standards — note them but don't re-check what tooling already checks)

• Any docs/ at the repository root or under STYLE.md、STANDARDS.md、STYLEGUIDE.md or similar files

  Any STYLE.md, STANDARDS.md, STYLEGUIDE.md, or similar at the repo root or under docs/

Collect the file list.StandardsThe sub-agent will read them.

Collect the list of files. The Standards sub-agent will read them.

4. Launch two sub-agents in parallel

Send one message containing two Agent tool calls. Use the general-purpose sub-agent for both.

Send a single message with two Agent tool calls. Use the general-purpose subagent for both.

Standards sub-agent prompt — include:

Standards sub-agent prompt — include:

• The full diff command and commit list.

  The full diff command and commit list.

• The list of standards source files found in step 3.

  The list of standards-source files you found in step 3.

• Instruction: "Read the standards documents. Then read the diff. Report — organized by file/hunk — every place where the diff violates the documented standards. Cite the standard (file + rule). Distinguish hard violations from judgment-call skips. Skip what the tools enforce. Within 400 words."

  The brief: "Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Under 400 words."

Spec sub-agent prompt — include:

Spec sub-agent prompt — include:

• diff command and commit list.

  The diff command and commit list.

• The path of the specification or the retrieved content.

  The path or fetched contents of the spec.

• Instruction: "Read the specification. Then read the diff. Report: (a) requirements required by the specification but missing or partially implemented; (b) behavior in the diff that was not required (scope creep); (c) requirements that appear to be implemented but whose implementation appears problematic. For each finding, cite the specification line. Within 400 words."

  The brief: "Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."

If the specification is missing, skip the specification sub-agent and note this in the final report.

If the spec is missing, skip the Spec sub-agent and note this in the final report.

5. Aggregation

Under the ## Standards and ## Spec headings, present the two reports verbatim or lightly cleaned up.Do notmerge or reorder the findings — the two axes are deliberately kept separate so that the user can view them independently.

Present the two reports under ## Standards and ## Spec headings, verbatim or lightly cleaned. Do not merge or rerank findings — the two axes are deliberately separate so the user can see them independently.

End with a one-line summary: the total number of findings for each axis, and the most severe single issue flagged (if any).

End with a one-line summary: total findings per axis, and the worst single issue (if any) flagged.

Why two axes

A change may pass one axis but not the other:

A change can pass one axis and fail the other:

• The code follows every standard but implements the wrong thing → standards pass, specification fails.

  Code that follows every standard but implements the wrong thing → Standards pass, Spec fail.

• The code implements exactly what the issue requires but violates the project conventions → specification passes, standards fail.

  Code that does exactly what the issue asked but breaks the project's conventions → Spec pass, Standards fail.

Reporting them separately prevents one axis from masking the other.

Reporting them separately stops one axis from masking the other.