skill by
@mattpocockReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".
Permissions
Files
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".
Two-axis review of the diff between HEAD and a fixed point the user supplies:
Both axes run as parallel sub-agents so they don't pollute each other's context, then this skill aggregates their findings.
The issue tracker should have been provided to you. If docs/agents/issue-tracker.md is missing, tell the user to run /setup-matt-pocock-skills.
Install
It’s free, and every skill you add syncs into every AI tool on your computer, instantly.
Version history
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.
Look for the originating spec, in this order:
#123, Closes #45, GitLab !67, etc.), fetched via the workflow in docs/agents/issue-tracker.md.docs/, specs/, or .scratch/ matching the branch name or feature.Anything in the repo that documents how code should be written, such as CODING_STANDARDS.md or CONTRIBUTING.md.
On top of whatever the repo documents, the Standards axis always carries the smell baseline below: a fixed set of Fowler code smells (Refactoring, ch.3) that applies even when a repo documents nothing. Two rules bind it:
Each smell reads what it is → how to fix; match it against the diff:
switch/if-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.a.b().c().d() navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.Standards sub-agent prompt should include:
Spec sub-agent prompt should include:
If the spec is missing, skip the Spec sub-agent and note this in the final report.
Present the two reports under ## Standards and ## Spec headings, verbatim or lightly cleaned. Do not merge or rerank findings, because 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.
A change can pass one axis and fail the other:
Reporting them separately stops one axis from masking the other.
In these kits
More from @mattpocock
Works with
Claude, Codex, Cursor & more