code-review

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

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

2つの軸は互いのコンテキストを汚染しないよう、並列のサブエージェントとして実行されます。その後、このスキルが指摘事項を集約します。

issue トラッカーは提供されている必要があります。docs/agents/issue-tracker.md がない場合は、/setup-leandrocfe-skills を実行してください。

プロセス

1. 基準点を固定する

固定点はユーザーの指定によります。コミット SHA、ブランチ名、タグ、main、HEAD~5 などです。指定がない場合は、ユーザーに尋ねてください。

差分コマンドを一度だけ取得します：git diff <ponto-fixo>...HEAD（three-dot 形式。比較対象は merge-base です）。コミット一覧も git log <ponto-fixo>..HEAD --oneline で記録してください。

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

2. spec の出所を特定する

以下の順に、元の spec を探してください。

1. コミットメッセージ内の issue への参照（#123、Closes #45、GitLab の !67 など）— docs/agents/issue-tracker.md のワークフローを使って検索してください。
2. ユーザーが引数として指定したパス。
3. ブランチ名または機能名に一致する、docs/、specs/、.scratch/ 配下の spec ファイル。
4. 見つからない場合は、spec の場所をユーザーに尋ねてください。存在しないとの回答があった場合は、Spec サブエージェントをスキップし、「利用可能な spec なし」と報告してください。

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

コードの書き方を定めたリポジトリ内のファイルを探します。たとえば、CODING_STANDARDS.md や CONTRIBUTING.md などです。

リポジトリに記載された内容に加え、Standards の軸では常に、以下の smell baseline が適用されます。これは Fowler の Refactoring 第 3 章にあるコードスメルの固定リストで、リポジトリに何も記載されていなくても適用されます。これを支配するルールは 2 つです。

• リポジトリのルールが優先されます。 リポジトリに記載された規約は常に優先されます。ベースラインが指摘する内容をリポジトリの規約が支持している場合は、そのスメルを指摘しないでください。
• 常に判断が必要です。 各スメルは「Feature Envy の可能性」のようなヒューリスティックであり、決定的な違反ではありません。また、ここに挙げた規約と同様に、ツールで保証される内容は対象外としてください。

各スメルは、内容 → 修正方法 の順に記載されています。diff と照らし合わせてください。

• Mysterious Name — 関数、変数、型の名前から、それが何をするのか、何を保持するのかが分かりません。→ 名前を変更してください。誠実な名前を付けられない場合は、設計が曖昧です。
• Duplicated Code — 同じロジックの形式が、変更箇所の複数の hunk またはファイルに現れます。→ 共通の形式を抽出し、両方の箇所から呼び出してください。
• Feature Envy — メソッドが、自分自身のオブジェクトよりも別のオブジェクトのデータに多くアクセスしています。→ そのメソッドを、対象のデータの近くに移してください。
• Data Clumps — 同じ少数のフィールドやパラメーターがいつも一緒に扱われています（専用の型が必要な可能性があります）。→ それらを 1 つの型にまとめ、その型を渡してください。
• Primitive Obsession — 独自の型に値するドメイン概念を、プリミティブ型や文字列で表しています。→ その概念を表す小さな型を作成してください。
• Repeated Switches — 同じ型に対する同じ switch／if の連鎖が、変更箇所で繰り返されています。→ ポリモーフィズム、または両方の箇所で共有する単一のマップに置き換えてください。
• Shotgun Surgery — 1 つの論理的な変更によって、diff 内の多くのファイルに編集が必要になります。→ 一緒に変更されるものを 1 つのモジュールにまとめてください。
• Divergent Change — 1 つのファイルやモジュールが、互いに関連しない複数の理由で編集されています。→ 各モジュールが 1 つの理由だけで変更されるように分割してください。
• Speculative Generality — spec にないニーズのために、抽象化、パラメーター、フックが追加されています。→ 実際のニーズが生じるまでは削除し、インライン化してください。
• Message Chains — 呼び出し元が依存すべきでない、長い a.b().c().d() のようなナビゲーションがあります。→ 最初のオブジェクトのメソッドの中に、その経路を隠してください。
• Middle Man — クラスや関数が、基本的に処理を別の場所へ委譲するだけです。→ それを削除し、実際の対象を直接呼び出してください。
• Refused Bequest — サブクラスや実装クラスが、継承した内容のほとんどを無視するか、オーバーライドしています。→ 継承をやめ、コンポジションを使用してください。

4. 2 つの sub-agent を並行して起動する

Standards sub-agent のプロンプト — 以下を含めます。

• diff の完全なコマンドとコミットの一覧。
• 手順 3 で見つけた standards のソースファイルの一覧に、手順 3 の smell baseline 全体を追加して貼り付けます。sub-agent は baseline に別の方法でアクセスできません。
• 次のブリーフィング：「報告内容 — 必要に応じてファイル／hunk ごとに — (a) diff が文書化された規約に違反しているすべての箇所：規約（ファイル名＋ルール）を引用してください。(b) 該当する baseline のスメル：名前を挙げ、hunk を引用してください。決定的な違反と判断が必要な指摘を区別してください。文書化された規約への違反は決定的な場合がありますが、baseline のスメルは常に判断が必要な指摘であり、リポジトリの文書化された規約は baseline より優先されます。ツールで保証される内容は対象外としてください。400 語未満でお願いします。」

Spec sub-agent のプロンプト — 以下を含めます。

• diff のコマンドとコミットの一覧。
• spec のパス、または取得済みの内容。
• 次のブリーフィング：「以下を報告してください。(a) spec で要求されているが、欠落している要件または一部しか実装されていない要件。(b) diff にある、要求されていない動作（スコープクリープ）。(c) 実装されているように見えるものの、実装が誤っているように見える要件。各指摘について spec の該当行を引用してください。400 語未満でお願いします。」

spec が見つからない場合は、Spec sub-agent を起動せず、その旨を最終レポートに記載してください。

5. まとめる

2 つのレポートを、それぞれ ## Standards と ## Spec の見出しの下に、全文または軽く整えた形で提示してください。指摘事項をまとめたり並べ替えたりしないでください。2 つの軸は意図的に分けられています（2 つの軸を設ける理由 を参照）。

最後に 1 行の要約を記載してください。各軸の指摘件数と、各軸における最も重大な問題（ある場合）を記します。2 つの軸の間で一方を総合的な勝者に選ばないでください。それこそ、分離によって防ごうとしている並べ替えです。

2 つの軸を設ける理由

変更は、一方の軸を通過しても、もう一方で失敗することがあります。

• すべての standard に従っているものの、誤った機能を実装するコード → Standards は合格、Spec は不合格。
• Issue の要求どおりに動作するものの、プロジェクトの規約に反するコード → Spec は合格、Standards は不合格。

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