HEADとユーザーが指定した固定点との差分を2軸でレビューします。
- 標準 — コードはこのリポジトリの文書化されたコーディング標準に準拠していますか？
- 仕様 — コードは元のIssue / PRD / 仕様を忠実に実装していますか？
両方の軸は並列サブエージェントとして実行されるため、互いのコンテキストを汚染せず、その後このスキルが結果を集約します。
Issueトラッカーが提供されているはずです — docs/agents/issue-tracker.mdがない場合は、/setup-matt-pocock-skillsを実行してください。
プロセス
1. 固定点を特定する
ユーザーが指定した固定点（コミットSHA、ブランチ名、タグ、main、HEAD~5など）を使用します。ユーザーが何も指定しなかった場合は、入力を求めます。
差分コマンドを一度記録します：git diff <固定点>...HEAD（三点ドット。マージベースとの比較になります）。また、git log <固定点>..HEAD --onelineでコミットの一覧も記録します。
先に進む前に、固定点が解決可能であること（git rev-parse <固定点>）と、差分が空でないことを確認します。無効な参照や空の差分の場合は、ここで失敗させます — 2つの並列サブエージェントの中では失敗させません。
2. 仕様ソースを特定する
元の仕様を次の優先順位で探します。
- コミットメッセージ内のIssue参照（
#123、Closes #45、GitLab!67など） —docs/agents/issue-tracker.mdのワークフローを使用して取得します。 - ユーザーが引数として渡したパス。
docs/、specs/、または.scratch/下にあるブランチ名や機能名に一致するPRD/仕様ファイル。- 何も見つからない場合は、ユーザーに仕様の場所を尋ねます。ユーザーが存在しないと言った場合、仕様サブエージェントはスキップされ、「利用可能な仕様がありません」と報告します。
3. 標準ソースを特定する
リポジトリ内でコードの書き方が文書化されているもの（CODING_STANDARDS.mdやCONTRIBUTING.mdなど）。
4. 両方のサブエージェントを並列で起動する
2つのAgentツール呼び出しを含む単一のメッセージを送信します。両方のサブエージェントにgeneral-purposeを使用します。
標準サブエージェントのプロンプト — 以下を含めます。
- 完全な差分コマンドとコミットリスト。
- 手順3で見つけた標準ソースファイルのリスト。
- 指示：「レポート — 該当するファイル/ハンクごとに — 差分が文書化された標準に違反しているすべての箇所を報告してください。標準（ファイルとルール）を引用してください。ハード違反と判断の余地がある違反を区別してください。ツールで強制されるものはスキップしてください。400ワード未満。」
仕様サブエージェントのプロンプト — 以下を含めます。
- 差分コマンドとコミットリスト。
- 仕様のパスまたは取得した内容。
- 指示：「レポート: (a) 仕様が要求したが欠落している、または部分的にしか実装されていない要件; (b) 要求されていないのに差分に含まれている動作（スコープクリープ）; (c) 実装されているように見えるが、実装が間違っているように見える要件。各発見に対して仕様の行を引用してください。400ワード未満。」
仕様が見つからない場合は、仕様サブエージェントをスキップし、最終レポートにその旨を記載します。
5. 集約する
2つのレポートを## 標準と## 仕様の見出しの下に、そのまま、または軽くクリーニングして表示します。発見を統合したり、再ランク付けしたりしないでください — 2つの軸は意図的に分離されています（_2軸の理由_参照）。
最後に1行の要約を付けます：軸ごとの総発見数と、各軸内での最悪の問題（ある場合）。軸をまたいで単一の勝者を選ばないでください — それが分離の目的です。
2軸の理由
1つの変更が一方の軸に合格しても、もう一方の軸に不合格になることがあります。
- すべての標準に従っているが、間違ったものを実装しているコード → 標準合格、仕様不合格。
- Issueが要求したことを正確に行っているが、プロジェクトの規約を破っているコード → 仕様合格、標準不合格。
これらを別々に報告することで、一方の軸がもう一方の軸を隠してしまうのを防ぎます。