review について
review は、リポジトリの規約と変更元の仕様に照らして差分を確認するコードレビュー用スキルです。2つの観点を並行して調べ、結果を分けてまとめます。
主な機能
- 01規約と仕様の並行レビュー
- 02指定した基準点との比較
- 03仕様の参照元の特定
- 04観点別の結果集約
活用シーン
- 01変更がコーディング規約に沿うか確認
- 02実装が課題や仕様を満たすか確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/reviewを入力して読み込まれたか確認します。
詳細
HEAD とユーザーが指定した固定点との差分を、2 つの軸でレビューします。
- Standards — コードは、このリポジトリで文書化されているコーディング標準に準拠していますか？
- Spec — コードは、元となる Issue／PRD／仕様を忠実に実装していますか？
2 つの軸は、互いのコンテキストを汚染しないよう並列のサブエージェントで実行し、その後、このスキルが調査結果を集約します。
Issue トラッカーの情報は提供されているはずです。docs/agents/issue-tracker.md が見つからない場合は、/setup-utarn-skills を実行してください。
Process
1. 固定点を決める
ユーザーが指定したものが固定点です。コミット SHA、ブランチ名、タグ、main、HEAD~5 などが該当します。指定がない場合は、ユーザーに確認してください。
差分コマンドを一度だけ取得します：git diff <fixed-point>...HEAD（3 点リーダーを使用し、マージベースとの比較にします）。また、コミットの一覧も記録します：git log <fixed-point>..HEAD --oneline。
先に進む前に、固定点が解決できること（git rev-parse <fixed-point>）と、差分が空でないことを確認してください。不正な参照や空の差分の場合は、2 つのサブエージェントに並列で処理させる前に失敗として扱います。
2. 仕様の参照元を特定する
次の順に、元となる仕様を探します。
- コミットメッセージ内の Issue 参照（
#123、Closes #45、GitLab の!67など）を確認し、docs/agents/issue-tracker.mdのワークフローを使って取得します。 - ユーザーが引数で指定したパス。
- ブランチ名または機能に一致する、
docs/、specs/、.scratch/配下の PRD／仕様ファイル。 - 見つからない場合は、仕様の場所をユーザーに確認します。仕様がないと回答された場合は、Spec サブエージェントをスキップし、「仕様はありません」と報告します。
3. 標準の参照元を特定する
コードの書き方を定めたリポジトリ内のドキュメントをすべて確認します。例：CODING_STANDARDS.md、CONTRIBUTING.md。
4. 2 つのサブエージェントを並列で起動する
Agent ツールの呼び出しを 2 つ含むメッセージを 1 つ送信します。両方とも general-purpose サブエージェントを使用してください。
Standards サブエージェントへのプロンプト — 次の内容を含めます。
- 完全な差分コマンドとコミット一覧。
- 手順 3 で見つけた標準の参照元ファイル一覧。
- 次の依頼：「報告では、該当する場合はファイル／ハンクごとに、差分が文書化された標準に違反するすべての箇所を示してください。標準（ファイル名とルール）を引用してください。明確な違反と判断が分かれるものを区別してください。ツールによって強制される事項は対象外とします。400 語未満でまとめてください。」
Spec サブエージェントへのプロンプト — 次の内容を含めます。
- 差分コマンドとコミット一覧。
- 仕様のパスまたは取得した内容。
- 次の依頼：「以下を報告してください：（a）仕様で求められているが、未実装または一部しか実装されていない要件、（b）差分に含まれるが、仕様で求められていない動作（スコープの逸脱）、（c）実装済みに見えるものの、実装が誤っているように見える要件。各指摘について仕様の該当行を引用してください。400 語未満でまとめてください。」
仕様が見つからない場合は、Spec サブエージェントをスキップし、最終レポートにその旨を記載します。
5. 集約する
2 つのレポートを、それぞれ ## Standards と ## Spec の見出しの下に、原文のまま、または軽く整えて提示します。調査結果を統合したり、順位付けし直したりしないでください。この 2 軸は意図的に分離されています（「Why two axes」を参照）。
最後に、各軸の指摘件数と、各軸で最も重大な問題（該当する場合）を 1 行でまとめます。2 つの軸をまたいで単一の勝者を選ばないでください。軸を分離している意図に反する再順位付けになるためです。
Why two axes
変更は一方の軸では合格し、もう一方では不合格になることがあります。
- すべての標準に準拠しているが、誤った機能を実装しているコード → Standards は合格、Spec は不合格。
- Issue の要求を正確に実装しているが、プロジェクトの規約に違反しているコード → Spec は合格、Standards は不合格。
別々に報告することで、一方の軸がもう一方の問題を覆い隠すのを防ぎます。