review について
コード差分をリポジトリの規約と元の仕様の両面から確認するスキルです。2種類のレビューを並行して実行し、結果をまとめます。
主な機能
- 01規約と仕様を別々にレビュー
- 02指定された基準点との比較
- 03仕様と規約の参照元を特定
- 04並行レビュー結果の集約
活用シーン
- 01ブランチがコーディング規約に沿うか確認
- 02変更内容を Issue や PRD と照合
- 03比較基準を指定してコミットをレビュー
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/reviewを入力して読み込まれたか確認します。
詳細
レビュー
HEAD とユーザーが指定した固定点との差分を、次の2つの軸でレビューします。
- 標準 — コードはこのリポジトリに文書化されたコーディング標準に準拠していますか？
- 仕様 — コードは元となる issue／PRD／仕様を忠実に実装していますか？
互いのコンテキストを汚染しないよう、両方の軸を並列サブエージェントで実行し、その後このスキルが結果を集約します。
issue トラッカーは提供されているはずです。docs/agents/issue-tracker.md がない場合は、/setup-matt-pocock-skills を実行してください。
プロセス
1. 固定点を決める
ユーザーが指定したものが固定点です。コミット SHA、ブランチ名、タグ、main、HEAD~5 など、指定された値をそのまま使ってください。独自に判断しないでください。指定がない場合は、「何と比較してレビューしますか？ブランチ、コミット、または main ですか？」と尋ねてください。固定点が決まるまでは先に進まないでください。
差分コマンドを一度だけ取得します：git diff <fixed-point>...HEAD（3点リーダーを使い、マージベースとの比較にします）。コミット一覧も git log <fixed-point>..HEAD --oneline で記録します。
2. 仕様の出典を特定する
元となる仕様を、次の順に探します。
- コミットメッセージ内の issue 参照（
#123、Closes #45、GitLab の!67など） —docs/agents/issue-tracker.mdに記載されたワークフローを使って取得します。 - ユーザーが引数として指定したパス。
- ブランチ名または機能に一致する、
docs/、specs/、.scratch/配下の PRD／仕様ファイル。 - 何も見つからない場合は、仕様の場所をユーザーに尋ねます。仕様はないと言われた場合、仕様サブエージェントはスキップし、「利用可能な仕様なし」と報告します。
3. 標準の出典を特定する
コードの書き方を定めた、リポジトリ内のものをすべて対象にします。一般的な場所は次のとおりです。
CLAUDE.md、AGENTS.mdCONTRIBUTING.mdCONTEXT.md、CONTEXT-MAP.md、コンテキストごとのCONTEXT.mdファイルdocs/adr/（アーキテクチャ上の決定も標準に含まれます）.editorconfig、eslint.config.*、biome.json、prettier.config.*、tsconfig.json（ツールで強制される標準です。記録しますが、ツールがすでに確認している内容を再チェックしないでください）- リポジトリのルートまたは
docs/配下のSTYLE.md、STANDARDS.md、STYLEGUIDE.mdなど
ファイル一覧を集めます。標準サブエージェントがそれらを読みます。
4. 2つのサブエージェントを並列で起動する
Agent ツールを2回呼び出すメッセージを一度に送信します。どちらにも general-purpose サブエージェントを使用します。
標準サブエージェントへのプロンプト — 以下を含めます。
- 完全な差分コマンドとコミット一覧。
- 手順3で見つかった標準の出典ファイル一覧。
- 依頼内容：「標準ドキュメントを読み、その後差分を読んでください。差分のうち、文書化された標準に違反する箇所を、該当するファイル／ハンクごとに報告してください。標準（ファイルとルール）を明記してください。明確な違反と判断が分かれる点を区別してください。ツールで強制される内容は除外してください。400語未満でまとめてください。」
仕様サブエージェントへのプロンプト — 以下を含めます。
- 差分コマンドとコミット一覧。
- 仕様のパスまたは取得した内容。
- 依頼内容：「仕様を読み、その後差分を読んでください。次の点を報告してください：(a) 仕様が求めているのに欠落または部分的な要件、(b) 求められていない差分内の動作（スコープクリープ）、(c) 実装済みに見えるものの、実装が誤っていると思われる要件。それぞれの指摘について仕様の該当行を引用してください。400語未満でまとめてください。」
仕様が見つからない場合は、仕様サブエージェントをスキップし、最終レポートにその旨を記載します。
5. 集約する
2つのレポートを ## 標準 と ## 仕様 の見出しの下に提示します。原文のまま、または軽く整える程度にしてください。指摘を統合したり、順位付けし直したりしないでください。2つの軸を分けているのは、ユーザーがそれぞれを独立して確認できるようにするためです。
最後に、各軸の指摘件数と、最も重大な問題（あれば）を1行でまとめます。
2つの軸を使う理由
変更は、一方の軸を通過しても、もう一方で問題になることがあります。
- すべての標準に従っているコードでも、誤った機能を実装している → 標準は合格、仕様は不合格。
- issue の要求どおりに実装されていても、プロジェクトの規約に違反している → 仕様は合格、標準は不合格。
別々に報告することで、一方の軸がもう一方の問題を覆い隠すのを防ぎます。