Review
Run a parallel Standards-and-Spec code review on everything changed since a commit, branch, or tag you pin against HEAD.
Overview
Review is an agent skill most often used in Ship (also Build, Operate) that dual-axis reviews a git range for coding standards and spec fidelity using parallel sub-agents.
Install
npx skills add https://github.com/vinvcn/mattpocock-skills-zh-cn --skill reviewWhat is this skill?
- Pins any fixed point (SHA, branch, tag, main) and diffs with git diff <point>...HEAD plus an oneline commit list
- Runs Standards and Spec reviews as parallel sub-agents so context does not cross-contaminate
- Resolves spec from issue refs, user path, or docs/specs/.scratch before Spec review; skips Spec when no spec exists
- Requires docs/agents/issue-tracker.md or /setup-matt-pocock-skills for tracker-backed issue fetch
- Aggregates both axes into one side-by-side report for branches, PRs, and WIP since X
- 2 review axes: Standards and Spec
- 3-dot merge-base diff: git diff <fixed-point>...HEAD
Adoption & trust: 1 installs on skills.sh; 499 GitHub stars.
What problem does it solve?
You have a pile of commits since a branch point but no structured way to separate “follows our standards” from “implements what the ticket promised.”
Who is it for?
Solo and indie devs on git-backed apps who link commits to issues or PRDs and want agent-driven review before merging.
Skip if: Repos with no standards docs and no spec source when you are unwilling to answer where the spec lives or accept a skipped Spec axis.
When should I use this skill?
User wants to review a branch, PR, work-in-progress changes, or asks to review since a commit, branch, tag, or merge-base.
What do I get? / Deliverables
You get a side-by-side Standards and Spec report for <fixed-point>...HEAD so you can fix gaps before merge or release.
- Parallel Standards sub-agent findings
- Parallel Spec sub-agent findings (or no-spec-available note)
- Aggregated side-by-side review report
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill is invoked on finished diffs before merge or release, matching PR and branch-review workflows. Review subphase fits the dual-axis checklist: repo coding standards versus issue/PRD fidelity on the merge-base diff.
Where it fits
Before merging a feature branch, pin main and compare Standards findings with Spec against the closing issue.
Mid-build, review HEAD since the spec branch point to see if implementation drifted from the PRD in docs/specs.
After a hotfix, review since the production tag to ensure the patch matches the incident ticket and repo conventions.
How it compares
Structured dual-axis git review workflow, not a single generic “please review my PR” chat prompt.
Common Questions / FAQ
Who is review for?
Solo builders and small teams using Claude Code, Cursor, or similar agents who already document coding standards and track work via issues or PRDs and want review on a defined git range.
When should I use review?
In Ship before merge or release when you say review since a branch or commit; in Build when validating a feature branch against a PRD mid-sprint; in Operate when reviewing hotfix diffs against a ticket after production incidents.
Is review safe to install?
It is procedural git-and-docs review logic; check the Security Audits panel on this Prism page before installing and restrict agent git access to repos you trust.
SKILL.md
READMESKILL.md - Review
# Review 对用户提供的固定点与 `HEAD` 之间的 diff 做双轴 review： - **Standards** — 代码是否符合这个 repo 记录下来的 coding standards？ - **Spec** — 代码是否忠实实现来源 issue / PRD / spec？ 两个轴线都作为**并行 sub-agents**运行，避免互相污染 context；然后这个 skill 聚合它们的 findings。 Issue tracker 应该已经提供给你；如果缺少 `docs/agents/issue-tracker.md`，运行 `/setup-matt-pocock-skills`。 ## Process ### 1. Pin the fixed point 用户说的任何内容都是 fixed point：commit SHA、branch name、tag、`main`、`HEAD~5` 等。不要自作主张；原样传入。如果用户没有指定，询问：“Review against what — a branch, a commit, or `main`?” 在拿到 fixed point 前不要继续。 先捕获一次 diff command：`git diff <fixed-point>...HEAD`（three-dot，因此比较对象是 merge-base）。同时用 `git log <fixed-point>..HEAD --oneline` 记录 commits 列表。 ### 2. Identify the spec source 按以下顺序寻找来源 spec： 1. Commit messages 中的 issue references（`#123`、`Closes #45`、GitLab `!67` 等）— 按 `docs/agents/issue-tracker.md` 中的 workflow 获取。 2. 用户作为 argument 传入的 path。 3. `docs/`、`specs/` 或 `.scratch/` 下与 branch name 或 feature 匹配的 PRD/spec 文件。 4. 如果什么都找不到，询问用户 spec 在哪里。如果用户说没有 spec，**Spec** sub-agent 跳过并报告 “no spec available”。 ### 3. Identify the standards sources Repo 中任何记录代码应该如何写的内容。常见位置： - `CLAUDE.md`、`AGENTS.md` - `CONTRIBUTING.md` - `CONTEXT.md`、`CONTEXT-MAP.md`、per-context `CONTEXT.md` files - `docs/adr/`（architectural decisions 也是 standards） - `.editorconfig`、`eslint.config.*`、`biome.json`、`prettier.config.*`、`tsconfig.json`（machine-enforced standards；记录它们，但不要重复检查 tooling 已经检查的内容） - Repo root 或 `docs/` 下任何 `STYLE.md`、`STANDARDS.md`、`STYLEGUIDE.md` 或类似文件 收集文件列表。**Standards** sub-agent 会读取它们。 ### 4. Spawn both sub-agents in parallel 发送一条包含两个 `Agent` tool calls 的消息。两个都使用 `general-purpose` subagent。 **Standards sub-agent prompt** — 包含： - 完整 diff command 和 commit list。 - Step 3 中找到的 standards-source files 列表。 - Brief："Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Under 400 words." **Spec sub-agent prompt** — 包含： - Diff command 和 commit list。 - Spec 的 path 或已获取内容。 - Brief："Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words." 如果缺少 spec，跳过 Spec sub-agent，并在最终报告中说明。 ### 5. Aggregate 在 `## Standards` 和 `## Spec` headings 下展示两个 reports，可原样或轻微清理。**不要**合并或重新排序 findings；这两个轴线刻意保持分离，方便用户独立查看。 最后用一行总结：每个轴线的 findings 总数，以及被标记的最严重单个问题（如果有）。 ## Why two axes 一个变更可能通过其中一个轴线，但失败在另一个轴线： - 代码符合所有 standard，但实现了错误的东西 → **Standards pass, Spec fail.** - 代码完全符合 issue 要求，但破坏了项目约定 → **Spec pass, Standards fail.** 分开报告能避免一个轴线掩盖另一个轴线。