Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →asymmetric-al/code-review
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/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side.
Passed 7 of 13 test cases with the skill, and 6 of 13 without it.
and 1 more in the full report
4 fixed7 passed either way8 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
When delegating the standards and spec analysis tasks to sub-agents during a code audit against `main`, which subagent type should be invoked?
| Checked | Without skill | With skill |
|---|---|---|
| Uses the general-purpose subagent type for both sub-agents | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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:
test cases passed, vs 6 / 13 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.