review-code

コードレビュー

対象をレビューし、指摘事項を報告します。各指摘事項は、深刻度（発生した場合の影響の大きさ）、可能性（問題のある経路が実際に実行される頻度）、および両方から導かれる「修正する価値があるか」の判定で評価します。修正する価値がある場合は、概要レベルの修正案も提示します。このスキルは報告のみを行い、ユーザーが後から明示的に依頼しない限り、コードを編集しません。

対象を解決する

引数から対象を選び、フラグは無視します。対象が指定されていない場合は、デフォルトで diff を選びます。

1. diff（デフォルト） — 現在のブランチのローカル作業：未コミットの編集、未プッシュのコミット、すでにプッシュされたコミットをまとめてレビューします。ブランチ自身のリモートではなく、ベースブランチとの分岐点を基準にします。そうしないと、コミットがプッシュされた時点で差分から抜け落ちてしまいます。通常の diff では含まれない未追跡ファイルも含めます。
2. pr <number>（または PR の URL。pr のみの場合は現在のブランチの PR）— GitHub PR をレビューします。差分に加え、意図を判断するのに十分な PR のコンテキスト（タイトル、説明、ベースブランチ）も確認します。GitHub CLI が利用できない場合は、その旨を伝えて diff に切り替えます。
3. <base>...<head> — 指定されたコミット範囲をレビューします。
4. all / codebase — リポジトリ全体をレビューします。現実的に確認できる範囲を明示し、エントリーポイント、コアロジック、最近変更されたファイルを優先します。確認を省略した箇所があれば、その旨を記します。
5. <path> — ファイルまたはディレクトリの引数で、レビュー対象をそのパスに限定します。

diff、PR、またはコミット範囲の場合は、変更行に加え、判断に必要な周辺のコンテキスト（呼び出し元、関連関数）も確認します。変更行がバグを表面化させただけであっても、そのバグはレビュー対象です。

レビューの実行方法

デフォルトではインラインでレビューします。--sub が指定された場合は、レビュー全体をサブエージェントで実行し、その報告をそのまま伝えます。ファイルを読むことでセッションが肥大化する all / codebase や大規模な差分で使用します。サブエージェントの返答を再レビューしたり、貼り戻したりしてはいけません。例外は、--second-opinion の最終判定だけです。ハーネスにサブエージェントがない場合は、その旨を伝えてインラインでレビューします。

セカンドオピニオン

--second-opinion が指定された場合は、別のエージェント（pi、または pi を使用している場合は Claude Code）にもレビューを依頼します。

• 最初に開始します。 同じ対象について second-opinion スキルをバックグラウンドで実行してから、待たずに通常のレビューを行います。サブエージェントが終了すると、サブエージェントによって開始されたバックグラウンドジョブが終了する可能性があるため、--sub が指定されていてもメインセッションが開始します。スキルが利用できない場合は、その旨を伝えて単独でレビューします。

• そのまま追加します。 報告の後に --- の区切り線を追加し、別のエージェントによるレビューを含む ## Second Opinion (<agent>) セクションを追加します。見出しは1段階下げて（## → ###）、ネストされた形にします。それ以外は何も変更しません。指摘事項を統合、重複排除、再評価してはいけません。失敗した場合は、そのセクションにエラーを記載し、レビュー結果はそのまま有効とし、最終判定は省略します。

• 最終判定を行います。 自分のサブエージェントも含め、どちらのレビューも誤っている可能性があります。報告の末尾にもう1つ --- の区切り線を追加し、どの指摘事項を実際に修正する価値があるかを決める ## Final Call セクションを追加します。

  • 両方のレビューにある同じ問題を説明する指摘事項は対応づけます。
  • いずれかのレビューで「Yes」または「判断が必要」と評価された指摘事項、および評価が異なるすべての指摘事項について、コードの引用箇所 file:line を確認します。どちらのレビューの判断も鵜呑みにせず、両者の意見が一致していることを根拠にしてはいけません。
  • それぞれを、理由を1節で示して Fix、Optional、または Skip と判定します。誤検知（コードの読み違い、場所の誤り、実行されない経路）は除外し、その理由を記載します。
  • このセクションで新たな指摘事項を追加してはいけません。

  | # | Finding | Source | Call | Reason |
  |---|---------|--------|------|--------|
  | 1 | <short title> | Main #2, Second #1 | Fix | <why> |
  | 2 | <short title> | Second #3 | Skip | <false positive: why> |
  

レビューの観点（優先順位順）

1. 正確性 — ロジックエラー、境界値のずれ、nil／null の参照外し、条件分岐の誤り、競合状態、未処理のエラー、API の誤用、エッジケースの不具合。
2. セキュリティ — インジェクション、認可／認証の欠如、コード内のシークレット、安全でないデシリアライズ、パストラバーサル、検証されていない入力。
3. データとリソース — リーク（fd／メモリ／ゴルーチン）、無制限の増加、トランザクション境界の欠如、N+1 クエリ。
4. パフォーマンス — 不要なメモリ割り当て、ホットパスでの O(n²)、ループ内のブロッキング呼び出し。
5. コードベースとの適合性 — リポジトリですでに解決済みの事柄に対する別パターン（HTTP クライアント、エラー処理、設定）、誤ったレイヤーにあるロジック、提供する価値に見合わないコード量。表面積を小さく保ってください。メソッドは少なく、パラメーターはシンプルにし、複雑さは内部に隠してください。新しい抽象化の削除テスト：それを削除すると複雑さがなくなるなら単なる受け渡しです。呼び出し元に複雑さが再び現れるなら、存在する価値があります。
   • 不要な Go の interface は使わないでください。 表面積が小さいとは、メソッドの少ない具象型を指し、interface キーワードを使うことではありません。実際の実装が2つある場合、または実際の依存先をテストで実行できない場合（サードパーティ API、リモートサービス）に限り宣言してください。単一実装のインターフェースは間接化として指摘してください。
6. 保守性 — 重複、不要なコード、不明瞭な命名、必要なテストの欠如。重大な悪影響がある場合に限って報告してください。スタイルの細かな指摘で報告を水増ししないでください。
7. テスト — 単体テストは多すぎると負担になり、利点にはなりません。実際の振る舞いではなく、主にモック／フェイクを検証するテスト、リファクタリングのたびに壊れる実装詳細を固定するテスト、新たなバグを見つけないのに保守コストを増やす重複したケースを指摘してください。多数のモック中心のテストより、実際のコンポーネントを対象にした少数のテスト（インテグレーション形式、インメモリ DB、実際の HTTP ハンドラーなど）を優先してください。デフォルトで単体テストの追加を求めないでください。実際のバグ経路が明らかになった場合にのみ求めてください。リファクタリング後、内部実装になった箇所のテストは、新しいテストと並べて残すのではなく削除してください。リポジトリですでに testify を使っている場合は、手書きの if got != want { t.Fatal(...) } ブロックを指摘してください。

問題をでっち上げないでください。コードに問題がなければ、そのように伝えてください。推測に基づく指摘を多数挙げるより、確度の高い指摘を少数挙げることを優先してください。

各指摘の評価

重大度 — 問題のある経路が実行された場合の影響：

• Critical — データの損失／破損、セキュリティ侵害、一般的な経路でのクラッシュ、ユーザーや金銭に影響する誤った結果。
• High — 現実的な条件下での誤った結果やクラッシュ、何らかの前提条件を必要とするセキュリティ問題。
• Medium — 動作の劣化、パフォーマンスの低下、またはまれな経路での正確性の問題。
• Low — 機能への影響がないスタイル、可読性、軽微な非効率性。

テストに関する指摘は、テスト自体の影響ではなく、検証されていない実際の経路がもたらすリスクで評価してください。

発生可能性 — 問題を引き起こす条件が実際に満たされる頻度：

• High — 通常の使用や一般的な入力で発生する。
• Medium — まれだが現実的な入力、タイミング、設定で発生する。
• Low — まれな条件、敵対的な条件、またはほぼ起こり得ない条件が必要。

修正する価値 — 重大度 × 発生可能性を基準に、修正コストを考慮して判断：

                    Likelihood
Severity     High           Medium         Low
Critical     Yes            Yes            Yes
High         Yes            Yes            Judgment call
Medium       Yes            Judgment call  No (note only)
Low          Judgment call  No             No

• Yes — 修正を推奨します。修正方法も含めてください。
• Judgment call — トレードオフ（修正にかかる労力と見返り）を説明し、推奨事項を示してください。修正方法も含めてください。
• No — 認識しておくべき点として記載してください。修正方法は省略するか、1行にとどめてください。

修正工数 — 修正方法を含める場合は評価してください：

• Trivial — 数行の変更、1ファイル、設計変更なし。
• Small — 1時間未満で完了する、局所的な変更。
• Medium — 複数ファイルにまたがる変更、または新しいテストが必要。
• Large — リファクタリング、設計変更、またはリスクの高い移行。

修正工数が Trivial の場合は、Judgment call を Yes に引き上げてください。修正工数が Large の場合、または見返りと比べてリスクが高い場合は、No 寄りにしてください。評価マトリクスから外れる場合は、その理由を述べてください。

レポート形式

最初に ## Summary セクションを置きます。ヘッダーの箇条書きに続けて、すべての指摘事項を修正する価値の高い順（Yes を先）に並べた表を置き、その後に重大度を記載します。次に ## Findings セクションを置き、指摘事項ごとにブロックを1つ記載します。各箇所は、実際に読んだ file:line で示してください。報告する価値のある指摘がない場合は、表と ## Findings を省略してください。

diff、pr、または範囲を扱う場合は、Net effect の箇条書きを追加してください。判断の対象はコードベースの構造的な健全性だけとし、機能の価値は判断に含めません。新機能や新しい機能は、それだけでは改善とはみなしません。変更によって削除または簡素化されたものと、追加されたものを比較してください。呼び出し側が把握すべきことが減り、変更が1か所で完結するなら改善です。浅いレイヤーを追加したり、1つの関心事を呼び出し側全体に分散させたりするなら悪化です。どちらとも判断できる具体的な根拠がない場合は、デフォルトで Neutral とします。

## Summary
- **Reviewed:** <target> — <N files, what was covered>
- **Verdict:** <one line: overall health + count of worth-fixing findings>
- **Net effect:** Improves | Neutral | Degrades — <one-line reason> (diff/pr/range only)

| # | Finding | Severity | Likelihood | Worth fixing | Fix effort |
|---|---------|----------|------------|--------------|------------|
| 1 | <short title> | High | High | Yes | Small |
| 2 | <short title> | Low | Medium | No | — |

次に：

## Findings

### 1. <short title>
- **Location:** `path/to/file.ext:42`
- **Category:** correctness | security | resources | performance | codebase-fit | maintainability | tests
- **Severity:** High — <why this impact>
- **Likelihood:** High — <what triggers it>
- **Worth fixing:** Yes
- **Issue:** <what is wrong and what goes wrong as a result>
- **Fix:** <high-level approach, not a full patch>
- **Fix effort:** Trivial | Small | Medium | Large — <one clause on what the fix touches>

よくある注意点

• テスト数を品質とみなすこと。 モックベースの単体テストが多数ある PR でも、重要な箇所がテストされていない場合があります。テストが実際のどのような振る舞いを保証しているかを基準に評価し、モックやフェイクに過度に依存したテストは保守性のコストとして指摘してください。