code-review

HEAD と、ユーザーが指定した固定点との diff を 2 軸でレビューする：

• Standards（規約） — コードはこのリポジトリで文書化されたコーディング規約に沿っているか？
• Spec（仕様） — コードは元となった Issue / PRD / 仕様を忠実に実装しているか？

両軸は並列のサブエージェントとして実行し、互いのコンテキストを汚染しないようにする。その後、このスキルが結果を集約する。

手順

1. 固定点を確定する

ユーザーが指定したものが固定点になる — コミット SHA、ブランチ名、タグ、main、HEAD~5 など。指定がなければ尋ねること。

diff コマンドを一度だけ確定する：git diff <固定点>...HEAD（3 ドット形式。マージベースとの比較になる）。あわせて git log <固定点>..HEAD --oneline でコミット一覧も控える。

先へ進む前に、固定点が解決できること（git rev-parse <固定点>）と diff が空でないことを確認する。不正な ref や空 diff は、並列サブエージェントの中ではなく、この時点で失敗させること。

2. 仕様（spec）の出どころを特定する

元となった仕様を、次の順で探す：

1. コミットメッセージ内の Issue 参照（#123、Closes #45 など）— GitHub CLI（gh issue view など）で取得する。
2. ユーザーが引数として渡したパス。
3. docs/、specs/、.scratch/ 配下にある、ブランチ名や機能名に一致する PRD / 仕様ファイル。
4. 何も見つからなければ、仕様の場所をユーザーに尋ねる。「仕様はない」と言われたら、Spec サブエージェントはスキップし、「仕様なし」と報告する。

3. 規約（standards）の出どころを特定する

コードの書き方を文書化しているものすべて。例：CODING_STANDARDS.md、CONTRIBUTING.md、CLAUDE.md のコーディング指針など。

リポジトリが文書化しているものに加えて、Standards 軸は常に下記のスメル・ベースラインを持つ — Fowler のコードスメル（『リファクタリング』第 3 章）の固定セットで、リポジトリに規約文書がなくても適用される。2 つのルールが縛る：

• リポジトリが優先。 文書化されたリポジトリの規約が常に勝つ。ベースラインが指摘する書き方をリポジトリが是としているなら、そのスメルは抑制する。
• 常に判断事項。 各スメルはラベル付きのヒューリスティック（「Feature Envy の可能性」）であって、確定違反ではない。また、他の規約と同様、ツール（リンター等）がすでに強制しているものはスキップする。

各スメルは「それは何か → どう直すか」の形式。diff と突き合わせること：

• 不可解な名前（Mysterious Name） — 何をする / 何を保持するのか名前から分からない関数・変数・型。→ リネームする。正直な名前が思いつかないなら、設計が濁っている。
• 重複コード（Duplicated Code） — 同じロジックの形が、変更内の複数のハンクやファイルに現れる。→ 共通の形を抽出し、両方から呼ぶ。
• 不適切な関心（Feature Envy） — 自分のデータより他のオブジェクトのデータにばかり手を伸ばすメソッド。→ そのメソッドを、羨んでいるデータの側へ移す。
• データの群れ（Data Clumps） — 同じ数個のフィールドや引数がいつも連れ立って移動する（型として生まれたがっている）。→ 1 つの型に束ねて、それを渡す。
• プリミティブへの執着（Primitive Obsession） — 固有の型を持つべきドメイン概念を、プリミティブや文字列で代用している。→ その概念に小さな専用の型を与える。
• 繰り返される switch（Repeated Switches） — 同じ型に対する同じ switch / if の連鎖が、変更のあちこちに再登場する。→ ポリモーフィズムか、両方の箇所が共有する 1 つのマップに置き換える。
• 散弾銃手術（Shotgun Surgery） — 1 つの論理的な変更のために、diff 内の多数のファイルに散らばった編集が必要になる。→ 一緒に変わるものを 1 つのモジュールに集める。
• 変更の発散（Divergent Change） — 1 つのファイルやモジュールが、無関係な複数の理由で編集されている。→ 各モジュールが 1 つの理由でだけ変わるよう分割する。
• 投機的な一般化（Speculative Generality） — 仕様にない将来の必要性のために追加された抽象化・引数・フック。→ 削除する。実際の必要が現れるまでインラインに戻す。
• メッセージの連鎖（Message Chains） — 呼び出し側が依存すべきでない長い a.b().c().d() のナビゲーション。→ 最初のオブジェクトのメソッド 1 つの背後にその探索を隠す。
• 仲介人（Middle Man） — ほとんど委譲するだけのクラスや関数。→ 取り除き、本当の対象を直接呼ぶ。
• 相続拒否（Refused Bequest） — 継承したもののほとんどを無視・上書きするサブクラスや実装。→ 継承をやめてコンポジションにする。

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

1 つのメッセージで 2 つの Agent ツール呼び出しを送る。どちらも general-purpose サブエージェントを使う。

Standards サブエージェントのプロンプト — 以下を含める：

• diff コマンドの全文とコミット一覧。
• 手順 3 で見つけた規約ソースのファイル一覧、および手順 3 のスメル・ベースラインの全文貼り付け — サブエージェントは他の方法でベースラインにアクセスできない。
• 指示文：「ファイル / ハンク単位で（必要に応じて）報告すること — (a) diff が文書化された規約に違反しているすべての箇所：規約を引用する（ファイル＋ルール）。(b) 見つけたベースライン・スメル：名前を挙げ、該当ハンクを引用する。確定違反と判断事項を区別すること — 文書化された規約への違反は確定になり得るが、ベースライン・スメルは常に判断事項であり、文書化されたリポジトリ規約はベースラインに優先する。ツールが強制しているものはスキップ。400 語以内。」

Spec サブエージェントのプロンプト — 以下を含める：

• diff コマンドとコミット一覧。
• 仕様のパス、または取得済みの仕様の内容。
• 指示文：「報告すること：(a) 仕様が求めたのに欠落・不完全な要件、(b) 求められていないのに diff に入っている振る舞い（スコープクリープ）、(c) 実装済みに見えるが実装が間違っていそうな要件。各指摘について仕様の該当行を引用すること。400 語以内。」

仕様が存在しない場合は Spec サブエージェントをスキップし、最終レポートにその旨を記す。

5. 集約する

2 つのレポートを ## Standards と ## Spec の見出しの下に、原文のまま（または軽く整えて）提示する。指摘のマージや再ランク付けはしてはいけない — 2 軸は意図的に分離されている（後述の「なぜ 2 軸か」参照）。

最後に 1 行のまとめ：軸ごとの指摘総数と、_各軸の中で_最も重大な問題（あれば）。軸をまたいで単一の「最重要」を選ばないこと — その再ランク付けこそ、分離が防ごうとしているものだ。

なぜ 2 軸か

変更は、片方の軸に合格してもう片方に落ちることがある：

• すべての規約に従っているが、実装しているものが間違っている → Standards 合格、Spec 不合格。
• Issue が求めたことを正確にやっているが、プロジェクトの慣習を破っている → Spec 合格、Standards 不合格。

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