review

name	review
author	mattpocock
upstream	mattpocock/skills
upstreamPath	skills/engineering/code-review
upstreamSha	b38badf7091afc614dedffc03ea8c8ad2b643cb4
lastUpdated	2026-06-25T17:00:00.000Z
tags	["Coding","Analysis","Matt Pocock"]
description	Two-axis code review — Standards (does code follow documented standards?) and Spec (does code match the originating issue/PRD?). Runs both reviews in parallel and reports side by side. Use when reviewing a branch, a PR, work-in-progress changes, or asking to 'review since X'.

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

• Standards — does the code conform to this repo's documented coding standards?
• Spec — does the code faithfully implement the originating issue / PRD / spec?

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

If the project uses an issue tracker, fetch the originating issue/PRD for spec review.

Process

1. Pin the fixed point

Whatever the user said is the fixed point — a commit SHA, branch name, tag, main, HEAD~5, etc. If they didn't specify one, ask for it.

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.

Before going further, confirm the fixed point resolves (git rev-parse <fixed-point>) and the diff is non-empty. A bad ref or empty diff should fail here — not inside two parallel sub-agents.

2. Identify the spec source

Look for the originating spec, in this order:

1. Issue references in the commit messages (#123, Closes #45, GitLab !67, etc.) — if the project uses an issue tracker, fetch the originating issue/PRD for spec review.
2. A path the user passed as an argument.
3. 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 they say there isn't one, the Spec sub-agent will skip and report "no spec available".

3. Identify the standards sources

<<<<<<< /tmp/tmp.hrXuvFQkkB Anything in the repo that documents how code should be written. Common locations:

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

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

Anything in the repo that documents how code should be written, such as CODING_STANDARDS.md or CONTRIBUTING.md.

/tmp/tmp.8ZJnUwnMqR/skills/in-progress/review/SKILL.md

4. Spawn both sub-agents in parallel

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

Standards sub-agent prompt — include:

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

• The diff command and commit list.
• The path or fetched contents of the spec.
• The brief: "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 note this in the final report.

5. Aggregate

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 (see Why two axes).

End with a one-line summary: total findings per axis, and the worst issue within each axis (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.

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 fail.
• Code that does exactly what the issue asked but breaks the project's conventions → Spec pass, Standards fail.

Reporting them separately stops one axis from masking the other.