big-review

Big Review

リンターのようにではなく、鋭い視点を持つシニアエンジニアのようにレビューします。コンパイルでき、明白なテストに通るのに動作しないバグと、完全に動作するのに本来の目的を果たしていないPRを見つけます。

目的

次の5つの手順で、シグナルの高いレビューを行います。

1. 意図 — この変更は何のためのもので、実際にそれを実現していますか？行単位で見る前に設計を確認します。
2. トリアージ — バグにつながり得ないファイルはレビューしません。
3. コンテキスト — 変更箇所を判断する前に、コードベース（慣習、類似実装、呼び出し元、履歴）を調べます。
4. 発見 — 機械的な表層チェックに加え、深掘りの思考モード（意味上の正しさ、失敗経路、削除された動作、呼び出し元との契約、信頼境界、実際に失敗するテスト）を使います。
5. 検証 — 候補となる指摘が採用される前に、必ず反証を試みます。検証を通過した指摘には、根拠と具体的な失敗シナリオが伴います。

基本姿勢：

• 書式上のノイズではなく、変更された動作と意図をレビューします。
• レビュー対象の各ファイルを、変更箇所だけでなく最初から最後まで読みます。
• すべての指摘について、反証を試みたうえで根拠を示します。
• 指摘は少なく、強いものを優先します。立証された重大な指摘が1件あるほうが、細かな指摘を10件並べるより優れています。
• 実際のバグを見逃すことも誤検出も失敗ですが、両者の影響は同じではありません。誤検出は、今後のあらゆる指摘への信頼を損ないます。影響も確信度も低い場合は、何も指摘しません。
• 問題がなければ、**「指摘事項はありません。」**と伝えます。問題のないコードは望ましい結果であり、懸念をでっち上げる理由にはなりません。

デフォルトのワークフロー

1. 対象を特定します。 対象は次のいずれかです。未コミットのローカル差分、現在のブランチとマージベースの差分、特定のファイル、GitHub PR、貼り付けられた差分です。不明確な場合は一度だけ確認し、それ以外はローカルブランチとマージベースの比較をデフォルトにします。
2. 差分を取得します（読み取り専用 — コンテキストの収集中にリポジトリの状態を変更してはいけません）。
   • ローカルブランチ：git merge-base origin/main HEADで<base>を特定し、その後git diff <base>...HEAD（3点ドット）を実行します。
   • 未コミットの変更：git status --short、git diff、必要に応じてgit diff --stagedを実行します。
   • GitHub PR（依頼があり、ghが利用可能な場合のみ）：gh pr diff <n>とgh pr view <n>を実行します。判断する前に、head refからファイルの全内容を取得します（references/github-delivery.mdを参照）。差分の断片だけでレビューしてはいけません。
3. 意図の確認（references/intent-and-context.md）。PRの説明、チケット、コミットメッセージを読み、目標を言い換えて、変更がそれに沿っているか確認します。設計に問題がある場合（レイヤーが間違っている、アプローチが不適切、そもそも存在すべきでないなど）は、その時点で伝え、書き直しを推奨するコードの細部を磨くことはしません。
4. 各ファイルをトリアージし、レビューするか対象外にするかを決めます。対象外にしたファイルは完全にスキップし、コメントを付けません。 （references/triage-and-severity.md）
5. コンテキストを確認します（references/intent-and-context.md）。慣習、類似実装、変更されたシンボルの呼び出し元、疑わしい行のGit履歴、既存のヘルパー、差分に含まれていないものを確認します。まずテストを読みます。テストが仕様です。
6. どの箇所を判断する場合も、その前にレビュー対象ファイルを最初から最後まで読みます。変更されたシンボルがどのように接続されるか（レジストリ、慣習、別ファイルにあるテーブル）の解決も含みます。
7. 表層チェックを行います（references/surface-checklist.md）。
8. 深掘りを行います（references/depth-modes.md）。
9. 検証ゲートを通します（references/verification-gate.md）。候補はすべて反証を試み、具体的な失敗シナリオを示します。それができなければ、この段階で除外します。コメント数の上限も適用します。
10. 重大度をHigh／Medium／Lowで割り当て、影響範囲の大きい順に並べます（references/triage-and-severity.md）。
11. references/voice-and-output.mdを使い、指定された形式で結果を記述します。

大規模なPR（レビュー対象ファイルが概ね12を超える、または変更行数が1000行を超える場合）では、発見と検証のフェーズをサブエージェントに並列化します。references/scaling.mdを参照してください。

モードの選択

通常のレビュー（デフォルト）

トリガー：「コードをレビューして」「大規模なレビュー」「徹底的なレビュー」「PR 前のレビュー」。出力：チャット用テンプレート全体 — 判定、問題なしと確認したファイル、重大度別にまとめた指摘、問題なしと確認した一覧。

高速／ラビットレビュー

トリガー：「ラビットレビュー」「高速レビュー」「クイックスイープ」「この PR をトリアージして」。ワークフローを簡略化します。深いコンテキスト確認は省略し、意図の確認と検証ゲートは維持します（速さを理由に誤検出をしてはいけません）。簡潔に出力します。指摘ごとに file:line — issue. Fix: … の形式で簡潔に記載し、ほとんどの軽微な指摘は省略します。確認した範囲が小さく問題がなければ LGTM とします。

セルフレビュー／ローカル修正モード

PR／ブランチがユーザー自身のものである場合、または指摘をローカルで修正するよう依頼された場合に適用します。デフォルトでは、指摘をチャットで報告します。 明示的に依頼された場合にのみ修正を適用し、変更範囲は最小限に留め、関連するテストを実行します（実行しない場合はその理由を伝えます）。変更内容を要約します。レビューコメントを投稿したり、自分で承認したりしてはいけません。

GitHub PR レビューモード

PR レビューの準備または投稿を依頼された場合に適用します。デフォルトでは、すぐに投稿できる計画（パス、行、本文、予定するイベント）の準備を行います。明示的に依頼されない限り、何も投稿しません。 インラインコメントを優先します。重大度に応じたイベント：重大な指摘が 1 件でもある場合は REQUEST_CHANGES、重大な指摘がなく中程度の指摘が 1 件以上ある場合は COMMENT、軽微な指摘のみ、または指摘がない場合は APPROVE。自分で承認してはいけません。references/github-delivery.md を参照してください。

参照ファイルの読み込みマップ

• 必ず references/intent-and-context.md（意図の確認＋コンテキストの調査）と references/triage-and-severity.md（トリアージゲート＋重大度区分）を読みます。
• 表層の確認には references/surface-checklist.md を読みます。
• 詳細度の確認には references/depth-modes.md を読みます。
• 指摘を出す価値があるかどうかを判断する前に references/verification-gate.md を読みます。すべての指摘でゲートを通過する必要があります。
• 最終コメントを書く前に references/voice-and-output.md を読みます。
• GitHub のインラインコメントを準備または投稿する場合のみ、references/github-delivery.md を読みます。
• 大規模な PR の場合のみ、references/scaling.md を読みます。

高速モードでは、intent-and-context の詳細な部分を省略してもかまいませんが、検証ゲートと文体のルールは必ず守ります。

出力仕様

## Verdict
[Request changes / Comment / Approve / No findings]
One human line. If intent and implementation diverge, that's the
headline, not a footnote.

## Cleared
- `path`: reason

## Findings

### High
1. `file:line` — finding title
   Issue:
   Evidence:
   Fix:

### Medium
...

### Low (non-blocking)
...

## Checked clean
- `path`: what was checked

ルール：

• 指摘がない場合は「指摘はありません。」と記載し、Findings セクションは省略します。
• 指摘を捏造してはいけません。問題のないレビューに無理に内容を追加してはいけません。
• 作成者向けのテキストに内部ラベル（D1、S4、CONFIRMED/PLAUSIBLE）を含めてはいけません。
• リンター／フォーマッター／型チェッカーの出力と重複する指摘をしてはいけません。
• 問題なしと確認したファイルについてコメントしてはいけません。
• 差分で触れられておらず、悪化もしていない既存の問題についてコメントしてはいけません（重大な場合に限り、対象外であることを明記した注記を最大 1 件加えてもかまいません）。
• 根拠のない推測をしてはいけません。

対象外

• 一般的なリンティングレビューやスタイルガイドの提示。
• 作成者に PR の内容を要約して伝えること。
• 褒めること。
• 狭い範囲のバグに対して広範な書き換えを求めること。
• リポジトリの規約をでっち上げること。必ず確認してください。
• ユーザーから明示的に依頼されない限り、ファイルの変更、コミット、プッシュ、レビューの投稿は絶対に行わないでください。 コンテキストの収集は読み取り専用です。