Two-Axis Code Review
Review a diff against both coding standards and the original spec in parallel sub-agents, reporting results side by side.
The skill defines clear operations limited to local git commands and file reads, with no network exfiltration or sensitive data handling. However, there is no user confirmation mechanism before invocation, and the skill depends on an external issue-tracker doc setup, introducing some lack of control. Therefore, 16 points awarded.
The process steps are clear with error handling, such as checking fixed point resolution and empty diff. However, static review prevents execution, and reliability relies on the availability of external issue-tracker docs; no tests or verification means provided. 6 points awarded.
The purpose and scope are clear, distinguishing standards vs spec review, with handling for missing specs. But no explicit non-fit scenarios, and no consideration for China network environment (depends on GitHub etc.). 10 points awarded.
Clear documentation structure with process, sub-agent prompts, aggregation steps. However, missing installation/dependency instructions, version history/changelog, and unclear maintenance responsibility. 12 points awarded.
Core task of diff review has clear steps, output structured as parallel reports. But static review cannot verify actual output quality, and dependence on external docs (issue-tracker.md) adds uncertainty. 6 points awarded.
The skill has no tests or verifiable examples. README provides repository context, but no concrete review cases. Static review prevents independent verification. 3 points awarded.
- The skill depends on external issue tracker docs (e.g., GitHub, Linear), which may be inaccessible from mainland China networks, affecting practical use.
- The skill does not provide a user confirmation mechanism; sub-agents may run automatically in parallel, recommend adding confirmation before execution.
- Static review cannot verify actual output quality; recommend testing in real environment before evaluation.
What does this skill do, and when should you use it?
This skill reviews changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow the repo's coding standards and a Fowler smell baseline?) and Spec (does it faithfully implement the originating issue/spec?). Running both as parallel sub-agents avoids context pollution, then aggregates findings into separate reports. It includes a built-in baseline of 12 Fowler code smells, with repo-documented standards taking precedence. Suitable for branches, PRs, or work-in-progress.
It pins the user-provided fixed point and runs git diff <fixed-point>...HEAD and git log. It locates the spec source (issue refs in commits, user-passed path, or spec files) and identifies standards sources. It then prompts two parallel sub-agents: one checks standards violations and smells, another compares the diff against the spec for missing, extra, or incorrect behavior. Finally, it aggregates both reports and gives a one-line summary per axis.
- A developer wants to review a PR before merging; they run the skill and specify the base branch as the fixed point.
- A developer asks to 'review since X' where X is a commit SHA, a tag, or `HEAD~5`.
- A team has multiple open PRs and needs quick, parallel assessment of standards and spec compliance.
- A product manager pairs with an engineer to verify an implementation against the PRD while also checking code quality. The skill produces both reports for discussion.
What are this skill's strengths and limitations?
- Parallel sub-agents prevent context pollution, improving review accuracy.
- Built-in Fowler smell baseline provides useful checks even in undocumented repos.
- Two-axis separation prevents standards compliance from masking spec deviations.
- Clear process: confirm fixed point, find spec source, and give sub-agents explicit briefs.
- Requires a user-specified fixed point; if not given, must ask, adding an interaction.
- If no spec is available, the Spec axis is skipped, potentially letting drift go unnoticed.
- Needs `docs/agents/issue-tracker.md` to fetch issues; requires setup first if missing.
- Smell checks are heuristic judgment calls and may yield false positives.
- This skill is distributed in a larger monorepo; installing it brings the whole collection, not just this one.
How do you install this skill?
Run npx skills@latest add mattpocock/skills and select this skill from the interactive picker (ensure /setup-matt-pocock-skills is also selected). Then run /setup-matt-pocock-skills to configure the issue tracker and other settings.
How do you use this skill?
In a configured repo, give a prompt like 'review the feature/login branch' or 'review changes since HEAD~3'. Specify a fixed point if needed (the skill will ask otherwise). The skill expects docs/agents/issue-tracker.md; if missing, it will instruct you to run the setup command.