code-review

mattpocock/skills の skills/engineering/code-review/SKILL.md に含まれる workflow-axa から同梱されており、コミットは 4ae2317、ライセンスは MIT です（LICENSE）。以下の上流テキストに変更はありません。末尾の workflow-axa による適応 は、内容が矛盾する箇所で上書きされます。

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

• 標準：コードはこのリポジトリに文書化されたコーディング標準に準拠していますか？
• 仕様：コードは元となる課題／仕様を忠実に実装していますか？

両方の軸は、互いのコンテキストを汚染しないよう 並列のサブエージェント として実行し、その後、このスキルが指摘事項をまとめます。各サブエージェントは、必ず新しいコンテキストウィンドウで開始してください。

課題トラッカーは提供されているはずです。提供されていない場合は、ユーザーに /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. コミットメッセージ内の課題参照（#123、Closes #45、GitLab の !67 など）。トラッカードキュメントのワークフローを使って取得します。
2. ユーザーが引数で指定したパス。
3. ブランチ名または機能に一致する、docs/、specs/、.scratch/ 配下の仕様ファイル。
4. 見つからない場合は、仕様の場所をユーザーに尋ねます。仕様がないと言われた場合、仕様サブエージェントはレビューをスキップし、「利用可能な仕様はありません」と報告します。

3. 規約のソースを特定する

リポジトリ内を検索し、コードの書き方を定めているファイルをすべて確認します。CODING_STANDARDS.md または CONTRIBUTING.md がある場合は、必ず一覧に含めます。

リポジトリに記載されている内容に加え、「規約」の軸には、以下の コードスメルのベースライン を常に適用します。これは Fowler のコードスメル（Refactoring 第3章）を固定セットにしたもので、リポジトリに何も記載されていない場合にも適用されます。次の2つのルールに従います。

• リポジトリの規約を優先します。 文書化されたリポジトリの規約は常に優先されます。ベースラインでは指摘対象となるものをリポジトリが推奨している場合、そのコードスメルは指摘しません。
• あくまで判断の目安です。 各コードスメルは「Feature Envy の可能性」のようなラベル付きのヒューリスティックであり、確定的な違反ではありません。この規約におけるほかの項目と同様に、ツールで既にチェックされているものは対象外とします。

各コードスメルについて、内容 → 修正方法 の順に説明しています。差分と照らし合わせてください。

• 不明瞭な名前（Mysterious Name）：関数、変数、型の名前から、その役割や保持する値が分かりません。→ 名前を変更します。適切な名前を付けられない場合は、設計が不明瞭です。
• 重複コード（Duplicated Code）：変更内の複数の差分箇所またはファイルに、同じ形のロジックがあります。→ 共通する部分を抽出し、両方から呼び出します。
• Feature Envy：自身のデータよりも、別のオブジェクトのデータに頻繁にアクセスするメソッドです。→ そのメソッドを、アクセス対象のデータを持つオブジェクトに移動します。
• データの塊（Data Clumps）：同じ少数のフィールドやパラメーターが繰り返し一緒に使われています（型としてまとめるべき状態です）。→ 1つの型にまとめて、それを渡します。
• プリミティブへの執着（Primitive Obsession）：独自の型にする価値があるドメイン概念を、プリミティブ型や文字列で表しています。→ その概念を表す小さな型を作ります。
• 繰り返される switch 文（Repeated Switches）：同じ型を対象とする switch／if の連鎖が、変更内で繰り返されています。→ ポリモーフィズムに置き換えるか、両方の箇所で共有するマップを1つ用意します。
• ショットガン手術（Shotgun Surgery）：1つの論理的な変更により、差分内の多くのファイルに散在する編集が必要になります。→ 変更が必要なものを1つのモジュールにまとめます。
• 発散する変更（Divergent Change）：1つのファイルまたはモジュールが、関連のない複数の理由で編集されています。→ 各モジュールが1つの理由で変更されるように分割します。
• 推測に基づく汎用性（Speculative Generality）：仕様が求めていない抽象化、パラメーター、フックが追加されています。→ 削除します。実際に必要になるまではインライン化しておきます。
• メッセージチェーン（Message Chains）：呼び出し元が依存すべきでない、長い a.b().c().d() のような連鎖です。→ 最初のオブジェクトに、連鎖したアクセスを隠すメソッドを用意します。
• 仲介者（Middle Man）：主に別の処理へ委譲するだけのクラスまたは関数です。→ 仲介をなくし、実際の対象を直接呼び出します。
• 継承の拒否（Refused Bequest）：継承した機能の大半を無視またはオーバーライドするサブクラスや実装です。→ 継承をやめ、コンポジションを使います。

4. 両方のサブエージェントを並行して起動する

両方のサブエージェント呼び出しをフォアグラウンドで同時に実行し、返されたレポートをまとめます。

規約サブエージェントのプロンプトには、次の内容を含めます。

• 完全な差分コマンドとコミット一覧。
• ステップ3で見つけた規約ソースファイルの一覧に加え、ステップ3のコードスメルのベースライン全文（サブエージェントはほかの場所から参照できないため、全文を貼り付けます）。
• 次の指示：「該当する場合はファイルや差分箇所ごとに、(a) 差分内で文書化された規約に違反している箇所をすべて報告し、規約（ファイル名とルール）を引用してください。(b) 気づいたベースラインのコードスメルを報告し、該当する差分箇所を引用してください。確定的な違反と判断の目安を区別してください。文書化された規約への違反は確定的な場合がありますが、ベースラインのコードスメルは常に判断の目安であり、文書化されたリポジトリの規約はベースラインより優先されます。ツールでチェックされているものは対象外とします。400語未満でまとめてください。」

仕様サブエージェントのプロンプトには、次の内容を含めます。

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

仕様が見つからない場合は、仕様サブエージェントを起動せず、その旨を最終レポートに記載します。

5. 集約

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

最後に、各軸の指摘件数と、各軸に該当する場合はその軸内で最も深刻な問題を、1 行でまとめます。2 つの軸をまたいで単一の最優先項目を選ばないでください。それは、軸を分けている目的に反して順位を付け直すことになります。

2 つの軸を設ける理由

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

• すべての標準に従っているが、実装内容が間違っているコード → Standards 合格、Spec 不合格。
• チケットの要求どおりに実装されているが、プロジェクトの慣例に違反しているコード → Spec 合格、Standards 不合格。

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

---

workflow-axa への適応

以下では、競合する上流の固定点、トラッカー、サブエージェントに関する前提を置き換えます。

• 差分。 タスクの記録にある開始時点の git status／差分を基準に、タスクで加えた変更（ステージ済み、未ステージ、未追跡）をレビューします。git diff <base>...HEAD だけでは未コミットの作業が漏れます。タスク開始前からユーザーの編集があった場合は、ユーザーの編集と自分の変更を区別してください。差分を得るためだけに、ステージング、コミット、マージベースの作成、チケットの取得をしてはいけません。
• 仕様。 PLAN の ## Agreement と、承認済みのチケットを対象にします。チケットのレビューではそのチケットの受け入れ条件とファイルを使用し、機能全体のレビューでは合意内容全体とタスクの差分全体を使用します。トラッカーは必要ありません。
• 標準の参照元には、プロジェクトの AGENTS.md／CLAUDE.md、適用される workflow-axa の共有ルール（../workflow/RULES.md）と ../workflow/AUDIT.md のカテゴリ、および以下のコード臭の基準が含まれます。
• サブエージェント。 ホストが利用可能な場合は、新しいサブエージェントで 2 つの軸をレビューします。変更を作成していない新しいサブエージェントが、両方の軸を続けてレビューする場合も、独立レビュー、軸は順次と記載します。「自己レビュー」とは、変更を作成した担当者が自分の変更をレビューすることです。どちらの場合も、軸は分けてください。
• 修正後は、影響を受けるチェックを再実行し、影響を受ける軸を再レビューします。
• 識別。 このパッケージの code-review（プラグイン名 workflow-axa:code-review）が、このワークフローで指定されているレビュアーです。ホストに組み込まれたコマンドや、同じ名前の別のインストール済みスキルは、別のツールです。