review

HEAD と、ユーザーが指定する固定地点との差分を、次の2つの軸でレビューします。

• 規約 — コードは、このリポジトリで文書化されているコーディング規約に準拠していますか？
• 仕様 — コードは、元となる issue／PRD／仕様を忠実に実装していますか？

2つの軸は、それぞれのコンテキストが互いに影響しないよう、並列サブエージェントで実行します。その後、このスキルが調査結果をまとめます。

issue トラッカーはすでに提供されているはずです。docs/agents/issue-tracker.md が見つからない場合は、/setup-matt-pocock-skills を実行してください。

プロセス

1. 固定地点を確定する

ユーザーが指定したものが固定地点です。コミット SHA、ブランチ名、タグ、main、HEAD~5 などが該当します。指定がない場合は、ユーザーに確認してください。

差分コマンドを一度だけ取得します：git diff <fixed-point>...HEAD（3点表記なので、マージベースとの比較になります）。コミット一覧も git log <fixed-point>..HEAD --oneline で記録します。

先に進む前に、固定地点が解決できること（git rev-parse <fixed-point>）と、差分が空ではないことを確認してください。不正な参照や空の差分は、2つの並列サブエージェント内ではなく、この段階で失敗させます。

2. 仕様の参照元を特定する

元となる仕様を、次の順で探します。

1. コミットメッセージ内の issue 参照（#123、Closes #45、GitLab の !67 など）。docs/agents/issue-tracker.md の手順で取得します。
2. ユーザーが引数として指定したパス。
3. ブランチ名または機能に一致する、docs/、specs/、.scratch/ 以下の PRD／仕様ファイル。
4. 何も見つからない場合は、仕様の場所をユーザーに確認します。仕様がないと回答された場合、仕様サブエージェントは処理をスキップし、「仕様を利用できません」と報告します。

3. 標準の情報源を特定する

CODING_STANDARDS.md や CONTRIBUTING.md など、コードの書き方を定めているリポジトリ内のファイルを確認します。

リポジトリに記載された内容に加えて、標準の軸には常に以下のコードスメルのベースラインが含まれます。これは Fowler のコードスメル（Refactoring 第3章）から選んだ固定の一覧で、リポジトリに何も記載されていなくても適用されます。守るべきルールは2つです。

• リポジトリの規則が優先されます。 文書化されたリポジトリの標準が常に優先されます。ベースラインで指摘される内容をリポジトリの標準が認めている場合は、そのスメルを指摘対象から除外します。
• 常に判断を伴います。 各スメルは「Feature Envy の可能性」のようなラベル付きのヒューリスティックであり、決して確定的な違反ではありません。また、ここで扱う他の標準と同様、ツールで既にチェックされているものは対象から除外します。

各スメルの説明は、問題の内容 → 修正方法 の順です。差分と照らし合わせてください。

• わかりにくい名前 — 何をするか、何を保持するかが名前からわからない関数、変数、型です。→ 名前を変更します。適切な名前が見つからないなら、設計が不明瞭です。
• コードの重複 — 同じロジックの形が、変更内の複数のハンクまたはファイルに現れます。→ 共通する形を抽出し、両方から呼び出します。
• Feature Envy — 自分自身のデータよりも、別のオブジェクトのデータに頻繁にアクセスするメソッドです。→ そのメソッドを、依存しているデータを持つオブジェクトに移します。
• データの塊 — 同じいくつかのフィールドやパラメーターが常に一緒に使われます（専用の型にまとめるべき状態です）。→ 1つの型にまとめ、その型を渡します。
• プリミティブ型への執着 — 独自の型に値するドメイン概念を、プリミティブ型や文字列で表しています。→ その概念を表す小さな型を作ります。
• 同じ switch の繰り返し — 同じ型に対する同じ switch／if の連鎖が、変更内で繰り返し現れます。→ ポリモーフィズム、または両方の箇所で共有する1つのマップに置き換えます。
• ショットガン手術 — 1つの論理的な変更のために、差分内の多くのファイルに分散した編集が必要です。→ 変更されるものを1つのモジュールにまとめます。
• 変更理由の分散 — 1つのファイルまたはモジュールが、互いに無関係な複数の理由で編集されています。→ 各モジュールが1つの理由で変更されるように分割します。
• 将来への備えすぎ — 仕様が求めていない抽象化、パラメーター、フックが追加されています。→ 削除し、実際の必要性が明らかになるまではインラインに戻します。
• メッセージチェーン — 呼び出し元が依存すべきではない、長い a.b().c().d() のようなナビゲーションです。→ 最初のオブジェクトにメソッドを用意し、一連の操作を隠します。
• 仲介人 — 主に別の処理へ委譲するだけのクラスまたは関数です。→ 取り除き、本来の呼び出し先を直接呼び出します。
• 継承拒否 — 継承した機能の大半を無視またはオーバーライドするサブクラスまたは実装です。→ 継承をやめ、コンポジションを使います。

4. 両方のサブエージェントを並列で起動する

2つの Agent ツール呼び出しを含むメッセージを1つ送信します。どちらにも general-purpose サブエージェントを使用してください。

標準確認サブエージェントへのプロンプト — 以下を含めます。

• diff コマンド全体とコミットの一覧。
• 手順3で見つけた標準の情報源となるファイルの一覧、および手順3のコードスメルのベースラインを全文貼り付けたもの — サブエージェントはそれ以外の方法でこの情報を参照できません。
• 次の依頼：「報告 — 関連する場合はファイル／ハンクごとに — (a) 差分が文書化された標準に違反しているすべての箇所（標準のファイルとルールを明記）、および (b) 見つけたベースラインのスメル（名前と該当ハンクを引用）。確定的な違反と判断を伴う指摘を区別してください。文書化された標準への違反は確定的な場合がありますが、ベースラインのスメルは常に判断を伴う指摘です。また、文書化されたリポジトリの標準はベースラインより優先されます。ツールでチェックされているものは対象から除外してください。400語未満でお願いします。」

仕様確認サブエージェントへのプロンプト — 以下を含めます。

• diff コマンドとコミットの一覧。
• 仕様のパスまたは取得した内容。
• 次の依頼：「報告：(a) 仕様が求めている要件のうち、未実装または一部のみ実装されているもの、(b) 差分に含まれる、求められていない動作（スコープクリープ）、(c) 実装されているように見えるが、実装内容が誤っているもの。指摘ごとに仕様の該当行を引用してください。400語未満でお願いします。」

仕様が見つからない場合は、仕様確認サブエージェントを起動せず、最終報告でその旨を記載してください。

5. 集約

2つのレポートを、## Standards と ## Spec の見出しの下に、原文のまま、または軽く整えて記載します。調査結果を統合したり、順位を付け直したりしないでください。2つの軸は意図的に分けられています（_2つの軸を設ける理由_を参照）。

最後に、各軸の調査結果の合計数と、各軸で最も重大な問題（あれば）を1行でまとめます。軸をまたいで総合的な勝者を1つ選ばないでください。それこそ、軸を分けている理由である順位の付け直しにあたります。

2つの軸を設ける理由

変更は、一方の軸では合格し、もう一方の軸では不合格となることがあります。

• すべての規約に従っているが、誤ったものを実装しているコード → Standards は合格、Spec は不合格。
• イシューで求められたことを正確に実装しているが、プロジェクトの規約に反しているコード → Spec は合格、Standards は不合格。

別々に報告することで、一方の軸がもう一方の結果を覆い隠すのを防げます。