For HEAD Perform a dual-axis review of the diff between the fixed point specified by the user:
- Convention—does the code comply with this repository's documented coding conventions?
- Specification—does the code faithfully implement the original issue / PRD / specification?
The two axes run asparallel sub-agents , without polluting each other's context, and then this skill summarizes the findings from both sides.
The issue tracker should already have been provided to you—if docs/agents/issue-tracker.md is missing, run /setup-matt-pocock-skills。
Process
1. Determine the fixed point
Anything the user says can serve as the fixed point—commit SHA, branch name, tag,main、HEAD~5 etc. Do not improvise; just pass it in directly. If the user did not specify, ask: "What should the review be based on—a branch, a commit, or main?" Do not continue until you get an answer.
Capture the diff command:git diff <fixed-point>...HEAD(three dots, so that the comparison is against the merge-base). Also use git log <fixed-point>..HEAD --oneline to record the commit list.
2. Determine the specification source
Look for the original specification in the following order:
- Issue references in commit messages (
#123、Closes #45、GitLab!67etc.)—fetch them according to the workflow indocs/agents/issue-tracker.md. - A path passed in by the user as an argument.
docs/、specs/or.scratch/A PRD/specification file under that matches the branch name or feature name.- If nothing is found, ask the user where the specification is. If the user says there is none,Specificationthe sub-agent will skip and report "no available specification".
3. Determine the convention source
Any documentation in the repository that records how code should be written. Common locations:
CLAUDE.md、AGENTS.mdCONTRIBUTING.mdCONTEXT.md、CONTEXT-MAP.md, theCONTEXT.mdfiles for each contextdocs/adr/(architecture decisions are conventions).editorconfig、eslint.config.*、biome.json、prettier.config.*、tsconfig.json(conventions enforced by tools—just record them; do not re-check what the tools already check)- Any
docs/or similar file in the repository root or underSTYLE.md、STANDARDS.md、STYLEGUIDE.md.
Collect the file list.ConventionThe sub-agent will read these files.
4. Launch two sub-agents in parallel
Send one message containing two Agent tool calls. Both use the general-purpose sub-agent.
Convention sub-agent prompt—include:
- The complete diff command and commit list.
- The list of convention source files you found in step 3.
- Brief task: "Read the convention documents. Then read the diff. Report every place in the diff that violates a documented convention, by file/hunk. Cite the convention (file + rule). Distinguish hard violations from judgment-call differences. Skip what tools already enforce. Within 400 words."
Specification sub-agent prompt——includes:
- diff command and commit list.
- Path to the spec file or the retrieved content.
- Task brief: "Read the spec. Then read the diff. Report: (a) requirements the spec requires but that are missing or incomplete; (b) behavior present in the diff but not required by the spec (scope creep); (c) requirements that appear to be implemented but whose implementation may be wrong. Cite the spec text for each item. Within 400 words."
If the spec is missing, skip the spec sub-agent and note this in the final report.
5. Summarize
Under the ## 规范 and ## 规格 headings, present the two reports, either verbatim or lightly cleaned up.Do notmerge or reorder the findings—the two axes are deliberately kept separate so the user can review them independently.
End with a one-line summary: the total number of findings on each axis, and the most severe single issue flagged (if any).
Why two axes
A change may pass review on one axis but fail on the other:
- The code follows all conventions but implements the wrong feature → conventions pass, spec fails.
- The code implements exactly what the issue asks for but violates project conventions → spec passes, conventions fail.
Reporting them separately prevents one axis from masking the other.