review

Review

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

• Standards — Does the code conform to the coding standards documented in this repo?
• Spec — Does the code faithfully implement the source issue / PRD / spec?

Run both axes asparallel sub-agentsto avoid cross-contaminating context; then this skill aggregates their findings.

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

Process

1. Pin the fixed point

Whatever the user says is the fixed point: commit SHA, branch name, tag,main、HEAD~5 , etc. Do not second-guess; pass it through as-is. If the user did not specify, ask: “Review against what — a branch, a commit, or main?” Do not proceed until you have the fixed point.

First capture the diff command once:git diff <fixed-point>...HEAD(three-dot, so the comparison target is the merge-base). Also use git log <fixed-point>..HEAD --oneline to record the commit list.

2. Identify the spec source

Look for the source spec in the following order:

1. Issue references in commit messages (#123、Closes #45、GitLab !67 , etc.) — fetch them according to the workflow in docs/agents/issue-tracker.md .
2. A path passed in by the user as an argument.
3. docs/、specs/ or .scratch/ A PRD/spec file matching the branch name or feature.
4. If you cannot find anything, ask the user where the spec is. If the user says there is no spec,Spec the sub-agent skips it and reports “no spec available”.

3. Identify the standards sources

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

• CLAUDE.md、AGENTS.md
• CONTRIBUTING.md
• CONTEXT.md、CONTEXT-MAP.md、per-context CONTEXT.md files
• docs/adr/(architectural decisions are also standards)
• .editorconfig、eslint.config.*、biome.json、prettier.config.*、tsconfig.json(machine-enforced standards; record them, but do not re-check what the tooling already checks)
• Any docs/ at the repo root or under STYLE.md、STANDARDS.md、STYLEGUIDE.md or similar files

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

4. Spawn both sub-agents in parallel

Send one message containing two Agent tool calls. Both use general-purpose subagent。

Standards sub-agent prompt — include:

• The full diff command and commit list.
• The list of standards-source files found in Step 3.
• 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:

• Diff command and commit list.
• The spec's path or fetched content.
• 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 spec is missing, skip the Spec sub-agent and state so in the final report.

5. Aggregate

Under the ## Standards and ## Spec headings, present the two reports, either as-is or lightly cleaned up.Do notmerge or reorder findings; the two axes are deliberately kept separate so the user can view them independently.

Finally, summarize in one line: the total number of findings for each axis, and the single most severe issue flagged (if any).

Why two axes

A change may pass one axis but fail the other:

• The code conforms to all standards but implements the wrong thing → Standards pass, Spec fail.
• The code fully meets the issue requirements but breaks project conventions → Spec pass, Standards fail.

Reporting them separately prevents one axis from masking the other.