review

レビュー

ユーザーが指定した固定点と HEAD の間の diff を二軸でレビューします：

• 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、context ごとの CONTEXT.md ファイル
• 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

2 つの Agent tool calls を含む 1 つのメッセージを送信します。どちらも 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 の下に 2 つの reports を表示します。そのままでも、軽く整理してもかまいません。findings を統合したり並べ替えたりしないでください。この 2 つの軸は、ユーザーが独立して確認できるよう、意図的に分離されています。

最後に 1 行でまとめます：各軸の findings の総数、および指摘された最も重大な単一の問題（あれば）。

Why two axes

変更は一方の軸を通過しても、もう一方の軸で失敗することがあります：

• コードがすべての standard に準拠しているが、間違ったものを実装している → Standards pass, Spec fail.
• コードが issue の要件を完全に満たしているが、プロジェクトの規約を破っている → Spec pass, Standards fail.

分けて報告することで、一方の軸がもう一方の軸を覆い隠すのを防げます。