Review a committed Git diff separately against repository standards and the feature specification.
Install and prepare
Run the following in your project terminal, then use the prompt below in Claude Code. This installs editable, project-scoped skill files.
npx skills@latest add mattpocock/skills --skill code-review --skill setup-matt-pocock-skills --agent claude-code
For Codex, replace claude-code with codex in the command and /code-review with $code-review in the prompt. With the complete Claude Code plugin, select /mattpocock-skills:code-review instead; avoid installing the same skills twice.
Prepare a valid base ref, a specification and any repository standards. Run setup-matt-pocock-skills once to configure the engineering workflow; local files are an available tracker option.
Your first task
Adapt the scenario and paths to your project, then enter this in the agent conversation:
/code-review main
The specification is specs/export.md. Review standards and requirements separately, especially empty exports, column order and error messages. Ask both reviewers to work directly without further delegation.
Work through the task
Pin the comparison
Start by checking that the ref resolves and inspecting the changes since its merge-base with HEAD. The skill uses a three-dot diff. If your export work is still uncommitted, organize the intended changes into a commit first. An empty diff does not mean the implementation passed review.
Read both reports
Standards checks local conventions and distinguishes explicit rules from design judgments. Spec checks missing requirements, extra scope and incorrect behavior. Correct CSV columns can still violate an interface convention; an omitted empty-state requirement belongs in the specification report.
Verify before editing
Open each cited code location and requirement before accepting the finding. Prioritize behavior defects, then justified convention fixes. Leave subjective preferences to the team. Repeated review can generate different suggestions, so use a defined review scope rather than chasing an endlessly empty report.
Check the result
Look for separate Standards and Spec sections and a traceable basis for each recommendation. Run relevant checks for accepted fixes. If no specification exists, its absence should remain explicit; standards compliance alone cannot establish feature completeness.
Common questions
My latest edit is missing. The default <base>...HEAD comparison excludes working-tree and staged edits.
A different review command ran. Check the selected owner. The full plugin offers a namespaced invocation.
Is the report a merge verdict? Treat it as findings to verify alongside tests and human review.
When a different kind of review fits better
This Skill checks whether a diff follows repository standards and implements the decisions in a spec. If you want a hunt for null paths, races, or off-by-one defects, arrange a defect-focused review separately; if there is no diff yet, finish the implementation first. Supply a fixed base commit or branch and confirm there is a nonempty diff from that base to HEAD. Correct a mistyped ref or empty range before treating any report as a pass.
Claude Code also ships a built-in command named code-review, with a different purpose. A plugin install lets you select the mattpocock-skills namespaced command; a plain file install may shadow the built-in one. When the two review blocks return, open the cited standards, spec lines, and changed code. Without a findable spec, only the standards axis can be completed; reviewers should not invent requirements. After accepting a finding, run the relevant checks and reread the remaining diff against the original scope.
Another task: review a shipping-threshold branch
Suppose a membership order should qualify for free shipping only after discounts. Record that decision in specs/shipping.md and commit the implementation. Then ask: “Use code-review against main and current HEAD. The spec is specs/shipping.md. Check whether free-shipping eligibility uses the pre-discount or post-discount total, and report repository standards separately from spec compliance.” Inspect whether each report cites the actual rule, spec line, and diff hunk before changing code.
If the Spec section is absent, check the spec path and tracker setup; a clean Standards section does not establish the behavior. If the shipping code is missing from the review, see whether it is still uncommitted, because this skill's three-dot diff reads committed changes. For a tentative style finding, open the cited location rather than treating speculation as a binding convention.
Treat review findings as leads to verify
In a comparison of five setups on one large Angular PR, this skill produced three findings the others did not mention but also some generic code-smell noise. The author had not checked every finding against the actual diff. Ask for the code location and the violated standard or requirement for each comment, then inspect the diff and run relevant tests. On a large PR, re-review critical modules rather than equating more comments with better review.