What it does
Takes a fixed point you name (a commit, branch, tag, main, HEAD~5), checks that it resolves and that the diff is not empty, then finds the spec (issue references in commit messages, a path you give, or a spec file under docs or specs). It also finds the repo's standards documents. It runs two sub-agents in parallel so they do not pollute each other: a Standards reviewer that cites the rule for every documented violation and also applies a baseline of twelve Fowler code smells as judgement calls, and a Spec reviewer that reports missing or partial requirements, scope creep and requirements that look implemented but wrong, quoting the spec line. The two reports stay separate on purpose, with no merged ranking.
Output
A Standards section, a Spec section and a one-line summary per axis with the worst issue in each.
Good for
Reviewing a branch or pull request against both the team's conventions and the originating issue.
Medium risk: instructions only, no scripts, but it runs git commands, may fetch the originating issue through the tracker workflow in the repo's docs, and spawns sub-agents that read your code. It is read-only on files. It expects docs/agents/issue-tracker.md from the author's setup Skill; without it, it asks you for the spec. Not test-run: it needs a real git repository, a tracker and sub-agents, so there is no demo and the front end marks it as unverified. By Matt Pocock, MIT.