review

Review

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

• Standards—does the code follow the coding standards documented in this repository?
• Specification—does the code faithfully implement the original issue/PRD/specification?

Both axes run asparallel subagentsso they do not contaminate each other's context, and then this skill aggregates their findings.

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

Process

1. Pin down the fixed point

Whatever the user says is the fixed point—a commit SHA, branch name, tag,main、HEAD~5 , etc. Do not be opinionated; just pass it through. If they do not specify one, ask: "Review against what—a branch, a commit, or main?" Do not proceed until you have it.

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

2. Identify the specification source

Look for the original specification in this order:

1. Issue references in commit messages (#123、Closes #45、GitLab !67 , etc.)—fetch them via the workflow in docs/agents/issue-tracker.md .
2. A path passed by the user as an argument.
3. docs/、specs/ or .scratch/ that matches the branch name or feature.
4. If nothing is found, ask the user where the specification is. If they say there is none, thespecificationsubagent will skip and report "no specification available".

3. Identify the standards source

Anything in the repository 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 standards)
• .editorconfig、eslint.config.*、biome.json、prettier.config.*、tsconfig.json(machine-enforced standards—note them but do not re-check what the tools already check)
• Any docs/ at the repository root or under STYLE.md、STANDARDS.md、STYLEGUIDE.md or similar

Collect the file list.StandardsThe subagent will read them.

4. Spawn two subagents in parallel

Send a single message with two Agent tool calls. Both use the general-purpose subagent.

Standards subagent prompt—include:

• The full diff command and commit list.
• The list of standards source files you found in step 3.
• Brief: "Read the standards documents. Then read the diff. Report—wherever relevant per file/hunk—every place the diff violates the documented standards. Cite the standard (file + rule). Distinguish hard violations from judgment calls. Skip anything tool-enforced. Under 400 words."

Specification subagent prompt—include:

• The diff command and commit list.
• The canonical path or the retrieved content.
• Brief: "Read the spec. Then read the diff. Report: (a) requirements the spec mandates that are missing or partial; (b) behavior in the diff that is not required (scope creep); (c) requirements that appear implemented but whose implementation looks wrong. Cite spec lines for each finding. Under 400 words."

If the spec is missing, skip the spec subagent and note this in the final report.

5. Aggregate

Present both reports under the ## Standards and ## Spec headings, verbatim or lightly cleaned up. Do notmerge or re-rank findings— the two axes are deliberately kept separate so the user can see them independently.

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

Why two axes

A change can pass one axis and fail the other:

• Code that follows every standard but implements the wrong thing → standards pass, spec fails.
• Code that does exactly what the issue asks but breaks project conventions → spec passes, standards fail.

Reporting them separately prevents one axis from masking the other.