honest-review

誠実なレビュー

調査に基づくコードレビューです。すべての指摘は証拠によって検証されます。 4段階のパイプライン：トリアージ → 分析 → 調査 → 判定。

対象範囲： まずコードレビューと監査を行います。機能開発、一般的な説明、ベンチマークは対象外です。レビュー後の修正計画や実行は、選択した指摘に対する承認ゲートを通過した後にのみ可能です。

標準用語

両方のモードで、以下の用語を正確に使用してください。

用語	定義
トリアージ	Wave 0：分析前にファイルをリスク別（HIGH/MEDIUM/LOW）に分類し、専門家を起用する条件を判断します
ウェーブ	パイプラインの段階：Wave 0（トリアージ）、Wave 1（分析）、Wave 2（調査）、Wave 3（判定）
指摘事項	重大度、信頼度スコア、証拠、引用を含む、個別のコード上の問題
信頼度	指摘事項ごとのスコア（0.0～1.0）：>=0.7 は報告、0.3～0.7 は未確認、<0.3 は破棄（P0/S0 を除く）
重大度	指摘事項の影響を優先度（P0～P3）と範囲（S0～S3）で分類
判定	Wave 3 での調整：指摘事項の正規化、クラスタリング、重複排除、フィルタリング、競合の解決、順位付け
レビューの視点	創造的なレビューの視点：逆転、削除、新規参入者、インシデント、進化、敵対者、コンプライアンス、依存関係、コスト、持続可能性
影響範囲	指摘事項の不具合が影響する可能性のあるファイル、ユーザー、システムの数
スロップスクワッティング	依存関係に含まれる、AI が幻覚で生成したパッケージ名。セキュリティ上重要なため、Wave 2 で最初に確認します
調査による検証	中核となる差別化要素：重要な指摘事項はすべて外部証拠（Context7、WebSearch、DeepWiki、gh）で確認します。証拠は2段階あります。事実の証拠（Grep）は再利用／簡素化の指摘事項に使用し、仮定の証拠（外部調査）は正確性、セキュリティ、明白でない設計の指摘事項に使用します。
体系的な指摘事項	3つ以上のファイルに現れるパターン。判定時の調整で、個別の指摘事項から昇格されます
承認ゲート	指摘事項の提示後に必須となる一時停止。ユーザーの同意なしに修正を実装することはありません
パス	内部のチームメイト段階（パス A：スキャン、パス B：詳細調査、パス C：調査）。パイプラインのウェーブとは異なります
自己検証	Wave 3.5：誤検知を減らすため、上位の指摘事項に対して敵対的な観点から確認します（references/self-verification.md）
規約の認識	AGENTS.md/CLAUDE.md/.cursorrules があるか確認し、プロジェクト独自のエージェント向け指示に照らしてレビューします
コード再利用に関する指摘事項	既存の機能と重複する新規コード。既存の実装を file:line 形式で引用する必要があります。
事実の証拠	コードベースに X が存在する／しないことを確認する Grep の結果です。再利用／簡素化の指摘事項には十分で、外部調査は不要です。
仮定の証拠	あるパターンが有害であることを確認する外部調査（WebSearch、Context7）です。正確性、セキュリティ、明白でない設計に関する指摘事項に必要です。
縮退モード	調査ツールが利用できない場合の動作です。ツールごとに信頼度の上限を適用します
レビューの深さ	honest-review は常に最大の深さで実行されます。すべての視点、完全な調査による検証、チーム全体を使用します。チーム構成は内容に適応し、ファイルの種類に応じて専門家を選択します。
推論の連鎖	指摘事項を述べる前に、必ず WHY（理由）を説明します。誤検知を減らします。
引用アンカー	指摘事項を特定のソース行に結び付ける [file:start-end] 形式の参照です。機械的に検証されます。
コンベンショナルコメント	構造化された PR 出力ラベル：praise/nitpick/suggestion/issue/todo/question/thought。装飾として (blocking)/(non-blocking) が付きます。
依存関係グラフ	Wave 0 のトリアージ中に作成されるインポート／エクスポートのマップです。影響範囲とファイル間への影響の把握に役立ちます。
学習	類似する今後の指摘事項を抑制するために保存された誤検知の却下情報です。プロジェクトごとに適用されます。

ディスパッチ

$ARGUMENTS	モード
空 + セッション内に変更あり（git diff）	変更されたファイルのセッションレビュー
空 + 変更なし	モードメニューを表示。コードベース全体の監査には明示的な audit が必要
ファイルまたはディレクトリのパス	指定されたパスの範囲をレビュー
"audit"	コードベース全体の監査を強制実行
PR 番号／URL	PR の変更をレビュー（gh pr diff）
Git の範囲（HEAD~3..HEAD）	指定された範囲の変更をレビュー
"history" [project]	プロジェクトのレビュー履歴を表示
"diff" または "delta" [project]	現在のレビューと前回のレビューを比較
--format sarif（任意のモードと併用）	SARIF v2.1 形式で指摘を出力（references/sarif-output.md）
"learnings" [command]	偽陽性に関する学習内容を管理（追加／一覧／クリア）
--format conventional（任意のモードと併用）	Conventional Comments 形式で指摘を出力
"fix" / "apply" 承認済みの指摘	レビュー後の修正パスを実行（references/auto-fix-protocol.md）
認識されない入力	明確化を求める

自動検出のヒューリスティック

明示的なモードキーワードが指定されていない場合：

1. 引数が空で、git diff --name-only HEAD に変更ファイルがある → セッションレビュー
2. 引数が空で、変更ファイルがない → モードメニューを表示。明示的な audit がない限り、全体監査を開始しない
3. 既存のファイルまたはディレクトリのパス → 範囲指定レビュー
4. PR 番号／URL → PR レビュー、Git の範囲（HEAD~3..HEAD） → 範囲レビュー
5. --format sarif または --format conventional は選択されたレビューのモードを変更する。単独で範囲を選択することはない
6. 一般的な調査、戦略に関する議論、説明、ベンチマーク、または純粋な簡素化の依頼 → 適切なスキルに誘導するか、進める前に確認する
7. 対象が曖昧または指定されていない場合 → トリアージの前に明確化を求める

レビューの方針

プロジェクトの種類に応じた重大度の調整：

• プロトタイプ：P0/S0 のみ報告します。スタイル、構成、最適化に関する懸念は対象外です。
• 本番環境：すべてのレベルと重大度で完全なレビューを行います。
• ライブラリ：完全なレビューに加え、公開 API の後方互換性に重点を置きます。

信頼度に応じた報告： すべての指摘に信頼度スコア（0.0～1.0）を付与します。信頼度 ≥ 0.7：報告します。 信頼度 0.3～0.7：「未確認」として報告します。信頼度 < 0.3：破棄します（P0/S0 を除く）。 評価基準：references/research-playbook.md § 信頼度スコアリング基準。

長所への言及： 適切に設計されたパターン、明確な抽象化、熟慮された設計を取り上げます。 レビュー範囲ごとに、少なくとも 1 つの長所を挙げます。長所に関する記述は報告項目であり、欠陥の指摘ではないため、修正は必要ありません。

肯定的な内容と建設的な指摘の比率： 目標は 3:1 です。否定的な報告だけにならないようにします。 比率が否定的に偏る場合、重大度の低い指摘を報告する価値があるかを再検討します。 例外：P0/P1 の指摘が 3 件以上ある場合は、比率を保つために減らすことなく、すべての重大な指摘を報告します。重要な問題をバランス調整のために抑制することはありません。

規約を尊重する姿勢： 理想的な基準ではなく、コードベース独自の基準に照らしてレビューします。

健全なコードベースへの言及： P0/P1 または S0 の指摘がない場合は、そのことを明示します。短いレポートも良いレポートです。

スケーリングの契約

• スコープを絞ったレビューでも、内容に応じたレビュー担当者のセットをすべて使用します。軽くなるのはトリアージの深さだけです。
• セッションレビューとフル監査には、最大レビュー深度、内容に応じたレビュー担当者、インラインのみの近道を使わないという共通のスケーリングルールがあります。
• 大規模なフルコードベース監査では、ドメインやリスク層ごとに担当範囲を分割できます。ただし、エビデンスの検証や、推論を優先する出力の契約が弱まることはありません。
• 読み取り専用レビューの出力は、指摘事項、優れた点、次のステップに関する推奨事項までです。実装の概要を提示するのは、明示的な承認を得て、別途修正パスを実施した後に限ります。

レビューレベル（両モード共通）

3 つの抽象レベルで、それぞれ欠陥と不要な複雑さを調べます。

正確性（正しく動作するか）： エラー処理、境界条件、セキュリティ、API の誤用、並行処理、リソースリーク。 簡素化：見せかけのエラー処理、不可能な状態に対する防御的チェック、到達しないエラーパス。TOCTOU アンチパターン：操作前に存在確認を行うと競合状態が発生します。直接操作し、エラーを処理します。

設計（適切に構築されているか）： 抽象化の品質、結合度、凝集度、テストの品質、認知的複雑さ。 簡素化：デッドコード、1 対 1 のラッパー、1 回しか使わない抽象化、過剰設計。文字列依存の実装（定数や列挙型がすでにあるのに生の文字列を使う）。パラメーターの増殖（構成を見直す代わりに新しいパラメーターを追加する）。冗長な状態（既存の状態を重複させる、またはそこから導出できる状態）。コピー＆ペーストによる差異（統合すべき、ほぼ同一のブロック）。

効率性（経済的か）： アルゴリズムの計算量、N+1 問題、データ構造の選択、リソース使用量、キャッシュ。 簡素化：不要なシリアライズ、重複計算、時期尚早な最適化。ホットパスの肥大化（起動時やリクエストごとのパスでブロッキング処理を行う）。並行処理の見落とし（独立した処理を逐次実行する）。範囲が広すぎる操作（必要な一部だけでなくファイルやコレクション全体を読み込む）。上限のないデータ構造やイベントリスナーのリーク。

状況に応じたトリガー（該当する場合に適用）：

• セキュリティ：認証、支払い、ユーザーデータ、ファイル I/O、ネットワーク
• 可観測性：サービス、API、長時間実行プロセス
• AI コードの問題：LLM が生成したコード、なじみのない依存関係
• 設定とシークレット：環境設定、認証情報、.env ファイル
• レジリエンス：分散システム、外部依存関係、キュー
• i18n とアクセシビリティ：ユーザー向け UI、ローカライズされたコンテンツ
• データ移行：スキーマの変更、データ変換
• 下位互換性：公開 API、ライブラリ、共有コントラクト
• Infrastructure as Code：クラウドリソース、コンテナー、CI/CD、デプロイ設定
• 要件の検証：明示された意図、PR の説明、チケットに照らした変更内容 詳細なチェックリスト：references/checklists.md を参照してください

創造的な視点

レビュー対象のスコープごとに、少なくとも 2 つの視点を適用します。セキュリティ上重要なコードでは、「攻撃者」の視点が必須です。

• 逆転：コードが間違っていると仮定すると、最初に何が壊れるか？
• 削除：各単位を削除したとき、ほかの何かが気づくか？
• 新規参入者：初めて貢献する人として読むと、どこで迷うか？
• インシデント：午前 3 時にアラートが鳴る状況を想像すると、どの経路でそこに至ったか？
• 進化：6 か月間、機能が急速に増えたと想像すると、何が壊れやすくなるか？
• 攻撃者：攻撃者なら、このコードをどのように悪用するか？
• コンプライアンス：このコードは規制要件を満たしているか？
• 依存関係：依存関係グラフは健全か？
• コスト：実行コストはいくらか？
• 持続可能性：コストが線形に増加することなく、スケールできるか？

参考：references/review-lenses.md を参照してください

指摘事項の構成

各指摘事項は、必ず次の順序に従ってください。

1. 引用アンカー：[file:start-end] — 正確なソース位置
2. 推論の流れ：これが問題である理由を説明します（指摘事項より前に、2～3文で記述）
3. 指摘事項：問題点を述べます（1文）
4. 証拠：外部検証ソース（Context7、WebSearch など）
5. 修正方法：推奨する対応

推論を先に説明せずに、指摘事項を述べてはいけません。 引用アンカーは機械的に検証されます。参照先の行が存在し、説明されているコードが含まれている必要があります。検証に失敗した場合は、その指摘事項を破棄してください。

調査による検証

これが最も重要な差別化要因です。LLM の知識だけを根拠に指摘事項を報告してはいけません。重要度の高い指摘事項はすべて、調査によって検証してください。

対象範囲ごとの3段階レビュー：

1. フラグ付けフェーズ：コードを分析し、仮説を立てます。
2. 検証フェーズ：報告する前に、ツールを呼び出して前提を確認します。
   • 指摘事項で主張している実際の使用パターンを Grep で検索します。
   • 実際のファイルを読み、引用した行とその文脈を確認します。
   • 指摘対象のコードパスにテストファイルでの網羅性があるか確認します。
   • コードが仮説と一致しない場合は、直ちに破棄します。
3. 妥当性確認フェーズ：調査サブエージェントを起動し、証拠を確認します。
   • Context7：API の正確性に関するライブラリのドキュメント
   • WebSearch（Brave、DuckDuckGo、Exa）：ベストプラクティス、セキュリティ勧告
   • DeepWiki：不慣れなリポジトリのアーキテクチャと設計パターン
   • WebFetch：パッケージレジストリ（npm、PyPI、crates.io）
   • gh：未解決の Issue、セキュリティ勧告
4. 信頼度スコア基準に従って、各項目に信頼度スコア（0.0～1.0）を割り当てます。
5. 証拠がある指摘事項のみを報告します。情報源を引用してください。

証拠の2つの段階： 事実の証拠 — Grep によって、コードベースに X が存在する／しないことが確認されているもの。再利用や簡素化に関する指摘事項にはこれで十分です。前提の証拠 — あるパターンが有害であることを外部調査で確認したもの。正確性、セキュリティ、明白でない設計に関する指摘事項ではこれが必要です。判断に迷う場合は、コードベースを読むだけで指摘事項を完全に証明または反証できるなら、事実の証拠で十分です。

調査手順については、references/research-playbook.md を参照してください。

モード1：セッションレビュー

セッションステップ1：トリアージ（Wave 0）

git diff --name-only HEAD を実行して変更内容を収集します。コンテキストを把握するため、git diff HEAD も取得します。 セッション履歴からタスクの意図を特定します。 規約ファイル（AGENTS.md、CLAUDE.md、.cursorrules）を検出します。詳細は references/triage-protocol.md を参照してください。

6ファイル以上の場合は、references/triage-protocol.md に従ってトリアージを実行します。

• uv run python skills/honest-review/scripts/project-scanner.py [path] を実行してプロジェクトのプロファイルを作成
• Git 履歴を分析（変更頻度の高いファイル、最近の変更、関連する Issue）
• 変更したすべてのファイルをリスク別（HIGH/MEDIUM/LOW）に分類
• 専門家のレビューが必要となる条件（セキュリティ、可観測性、要件）を特定
• モノレポのワークスペースを検出し、パッケージごとにレビュー担当を割り当て

1～5ファイルの場合は、簡易トリアージを行います。リスクレベルを分類し、コンテンツタイプを検出してください。チーム構成全体の確認は省略しないでください。（注：チームの作業に常に最大限の深度を適用しますが、小規模なレビューのトリアージでは、時間を節約するために Git 履歴分析の手順を省略できます。）

セッション ステップ 2：規模の判断と開始（Wave 1）

スコープ	戦略
すべてのスコープ	内容に応じたチーム（以下を参照）。常に最大限の深さでレビューします。インラインのみのモードはありません。

内容に応じたチーム構成：

常に起動します：

• 正確性レビュアー → Pass A/B/C
• 設計レビュアー → Pass A/B/C
• 効率性レビュアー → Pass A/B/C
• コード再利用レビュアー → Pass A/B/C
• テスト品質レビュアー → Pass A/B/C（常に起動します。スコープは対象の内容によって異なります。テンプレートを参照してください）

トリアージで検出された内容に応じて起動します：

• セキュリティスペシャリスト → 認証／決済／暗号／ユーザーデータ／外部 I/O のコードがある場合
• 可観測性スペシャリスト → サービス／API／長時間実行プロセスのコードがある場合
• 要件バリデーター → 仕様が自動検出された場合（PR の説明、リンクされた issue、SPEC.md、docs/、コミットメッセージ）
• データ移行スペシャリスト → スキーマ変更ファイルがある場合
• フロントエンドスペシャリスト → UI／コンポーネントファイル（tsx、jsx、css、vue）がある場合

[Lead: triage (Wave 0), Judge reconciliation (Wave 3), final report]
  |-- Correctness Reviewer → Passes A/B/C
  |-- Design Reviewer → Passes A/B/C
  |-- Efficiency Reviewer → Passes A/B/C
  |-- Code Reuse Reviewer → Passes A/B/C
  |-- Test Quality Reviewer → Passes A/B/C
  |-- [Security Specialist if triage triggers]
  |-- [Observability Specialist if triage triggers]
  |-- [Requirements Validator if spec auto-detected]
  |-- [Data Migration Specialist if schema changes present]
  |-- [Frontend Specialist if UI/component files present]

各レビュアーは内部パスを 3 回実行します（references/team-templates.md § 内部パスの構成）：

• Pass A：すべてのファイルを簡易スキャンします（opus、サブエージェントごとに 3～5 ファイル）
• Pass B：HIGH リスクとしてフラグ付けされたファイルを詳細に調査します（opus、ファイルごとに 1 つ）
• Pass C：調査によって検出結果を検証します（research-playbook.md に従って一括処理）

プロンプトテンプレート：references/team-templates.md を読み込んでください

セッション ステップ 3：調査による検証（Wave 2）

小規模スコープのレビューの場合：リードがすべての検出結果を集め、検証ウェーブを割り当てます。 チームレビューの場合：各チームメンバーが検証を内部で処理します（Pass C）。

検証タイプごとに検出結果をまとめます。次の順序で割り当てます：

1. Slopsquatting の検出（セキュリティ上重要、opus）
2. HIGH リスクの検出結果（2 つ以上の情報源、sonnet）
3. MEDIUM リスクの検出結果（1 つの情報源、opus）
4. 影響の小さい明白な問題はスキップします

バッチサイズ：サブエージェントごとに 5～8 件（最適）。references/research-playbook.md § バッチ最適化を参照してください。

セッション ステップ 4：判定と調整（Wave 3）

8 段階の判定プロトコルを実行します（references/judge-protocol.md）：

1. 検出結果を正規化します（scripts/finding-formatter.py が HR-S-{seq} ID を割り当てます）
2. 根本原因ごとにグループ化します
3. グループ内で重複を排除します
4. 信頼度でフィルタリングします（≥0.7 は報告、0.3～0.7 は未確認、<0.3 は破棄）
5. 相反する検出結果の矛盾を解決します
6. 相互作用を確認します（A を修正すると B が悪化するか？ A を修正すると B も修正されるか？）
7. 3 つ以上のファイルに見られるパターンをシステム全体の検出結果に格上げします
8. スコア = 重大度の重み × 信頼度 × 影響範囲、で順位付けします

検出結果が 2 件以上残った場合は、自己検証を実行します（Wave 3.5）：references/self-verification.md

セッション ステップ 5：提示と実行

すべての検出結果を、根拠、信頼度スコア、引用とともに提示します。 検出結果を提示した後、次のように尋ねます：「どの検出結果について修正計画を作成しますか？［すべて／ID を指定して選択／スキップ］」 承認された場合：references/auto-fix-protocol.md を読み込み、選択された検出結果のみを対象に、レビュー後の独立した修正パスを開始します。Pattern E を使用して、オーケストレーション実装計画を生成します。独立した修正は並列で割り当て、同じファイルの編集は順番に実行します。すべてのタスク完了後に検証します（ビルド、テスト、動作）。 出力形式：references/output-formats.md を読み込んでください SARIF 出力の場合：references/sarif-output.md を読み込んでください

モード 2：コードベース全体の監査

監査ステップ 1：トリアージ（Wave 0）

references/triage-protocol.md に従って完全なトリアージを実施します：

• uv run python skills/honest-review/scripts/project-scanner.py [path] でプロジェクトのプロファイルを作成します
• Git 履歴を分析します（並列の opus サブエージェント 3 つ：注目度の高いファイル、最近の変更、関連する issue）
• すべてのファイルをリスク別に分類します（HIGH/MEDIUM/LOW）
• コンテキストを組み立てます（プロジェクトの種類、アーキテクチャ、テストカバレッジ、PR 履歴）
• チーム構成に必要なスペシャリストの起動条件を判断します

ファイルが 500 件以上の場合：HIGH リスク、最近変更されたファイル、エントリーポイント、公開 API を優先します。 レポートにはスコープの制限を記載します。

監査ステップ 2：チームの設計と立ち上げ（第 1 波）

トリアージ結果に基づいてチーム構成を選択します。セッションレビューと同じコンテンツ適応型チームを適用します。 リスク分類に基づいてファイルの担当を割り当てます。HIGH リスクのファイルには、ドメインレビュアーと専門家の両方を割り当てます。

スコープ	戦略
任意のスコープ	コンテンツ適応型チーム（以下を参照）。常に最大限の深度で実施します。インラインのみのモードはありません。

コンテンツ適応型チームの構成：

常に起動します：

• 正確性レビュアー → パス A/B/C
• 設計レビュアー → パス A/B/C
• 効率性レビュアー → パス A/B/C
• コード再利用レビュアー → パス A/B/C
• テスト品質レビュアー → パス A/B/C（常に起動します。スコープは存在する内容に応じて異なります。テンプレートを参照してください）

トリアージで検出された内容に応じて起動します：

• セキュリティ専門家 → 認証／決済／暗号／ユーザーデータ／外部 I/O のコードがある場合
• 可観測性専門家 → サービス／API／長時間実行プロセスのコードがある場合
• 要件バリデーター → 仕様が自動検出された場合（PR の説明、リンクされた issue、SPEC.md、docs/、コミットメッセージ）
• データ移行専門家 → スキーマ変更ファイルがある場合
• フロントエンド専門家 → UI／コンポーネントファイル（tsx、jsx、css、vue）がある場合

[Lead: triage (Wave 0), cross-domain analysis, Judge reconciliation (Wave 3), report]
  |-- Correctness Reviewer → Passes A/B/C
  |-- Design Reviewer → Passes A/B/C
  |-- Efficiency Reviewer → Passes A/B/C
  |-- Code Reuse Reviewer → Passes A/B/C
  |-- Test Quality Reviewer → Passes A/B/C
  |-- [Security Specialist if triage triggers]
  |-- [Observability Specialist if triage triggers]
  |-- [Requirements Validator if spec auto-detected]
  |-- [Data Migration Specialist if schema changes present]
  |-- [Frontend Specialist if UI/component files present]

大規模なコードベース（500 ファイル以上）の監査専用スコープ設定： コアレビュアー（正確性、設計、効率性）は、リスク階層ごとにファイルの担当を分割します。コード再利用レビュアーの対象は、変更されたファイル／HIGH リスクのファイルに加え、サンプリングした横断的なファイル群（ファンインと LOC の上位 50 ファイル）に限定し、コードベース全体は対象にしません。テスト品質レビュアーは、変更されたコード／HIGH リスクのコードをカバーするテストファイルに重点を置きます。リードは引き続き、並行してドメイン横断分析を実施します（監査ステップ 3 — 変更なし）。500 ファイル以上を対象とする分割ルールは、セッションレビューモードには適用されません（セッションレビューでは常に範囲が限定された diff を扱います）。

各チームメンバーは、内部で 3 つのパスを実行します（references/team-templates.md § 内部パス構成）。 スケーリング：references/team-templates.md § スケーリングマトリックス。

監査ステップ 3：ドメイン横断分析（リード、第 1 波と並行）

チームメンバーがレビューを行う間、リードは以下を担当するサブエージェントを並行して起動します。

• アーキテクチャ：モジュール境界、依存関係グラフ
• データフロー：主要な経路をエンドツーエンドで追跡
• エラー伝播：システム全体での一貫性
• 共有パターン：重複と必要な抽象化の見極め

監査ステップ 4：調査結果の検証（第 2 波）

各チームメンバーが調査結果の検証を内部で担当します（パス C）。 リードはドメイン横断の調査結果を別途検証します。 バッチ最適化：references/research-playbook.md § バッチ最適化。

監査ステップ 5：判定と調整（第 3 波）

すべてのチームメンバーとドメイン横断分析から、すべての調査結果を収集します。 8 ステップの判定プロトコルを実行します（references/judge-protocol.md）。 ドメイン横断の重複排除：複数のドメインにまたがる調査結果は、システム全体に関わるものとして格上げします。

監査ステップ 6：レポート

出力形式：references/output-formats.md を読みます。 必須セクション：重大、重要、ドメイン横断、健全性の概要、 上位 3 件の推奨事項、統計。すべての調査結果に証拠と引用を含めます。

監査ステップ 7：実行（承認された場合）

調査結果を提示した後、「どの調査結果の修正計画を作成しますか？［すべて／ID で選択／スキップ］」と尋ねます。 承認された場合：references/auto-fix-protocol.md を読み込み、選択された調査結果のみを対象とする、レビュー後の別個の修正パスを開始します。パターン E を使用してオーケストレーション実装計画を生成します。独立した修正は並行して実行し、同じファイルへの編集は順番に実行します。すべてのタスク完了後に検証します（ビルド、テスト、動作）。

状態管理

状態は任意で、レビュー履歴または誤検知に関する学習内容に限定されます。~/.{gemini|copilot|codex|claude}/honest-reviews/ に永続化してください。ユーザーから履歴の保存、実行結果の比較、または学習内容の管理を求められない限り、通常の読み取り専用レビュー中に状態を書き込まないでください。

必要な操作	コマンド
レビュー JSON を保存する	`cat findings.json
履歴を表示する	uv run python skills/honest-review/scripts/review-store.py list --project <slug>
レビューを比較する	uv run python skills/honest-review/scripts/review-store.py diff --project <slug> --old previous --new latest
学習内容を確認する	`cat findings.json
学習内容を管理する	`uv run python skills/honest-review/scripts/learnings-store.py <add

history または diff において以前のレビューが存在しない場合は、「保存されたベースラインがありません」と報告し、読み取り専用で続行してください。

参照ファイル

一度に読み込む参照ファイルは1つだけにしてください。すべての参照ファイルをコンテキストに事前読み込みしないでください。

ファイル	読み込むタイミング	約トークン数
references/triage-protocol.md	Wave 0 のトリアージ時（どちらのモードでも）	1500
references/checklists.md	分析時、またはチームメイト用プロンプトの作成時	2800
references/research-playbook.md	リサーチの検証を設定する際（Wave 2）	2200
references/judge-protocol.md	Judge による調整時（Wave 3）	1200
references/self-verification.md	Judge の後（Wave 3.5） — 誤検出を敵対的に削減	900
references/auto-fix-protocol.md	承認後に修正を実装する際	800
references/output-formats.md	最終出力を作成する際	1100
references/sarif-output.md	CI ツール用に SARIF 形式で出力する際	700
references/supply-chain-security.md	依存関係のセキュリティをレビューする際	1000
references/team-templates.md	チームを設計する際（モード2または大規模なモード1）	2200
references/review-lenses.md	創造的なレビューの視点を適用する際	1600
references/ci-integration.md	CI パイプラインで実行する際	700
references/conventional-comments.md	PR コメントまたは CI アノテーションを作成する際	400
references/dependency-context.md	Wave 0 のトリアージで、ファイル間の依存関係を分析する際	500

スクリプト	実行するタイミング
skills/honest-review/scripts/project-scanner.py	Wave 0 のトリアージ — 決定論的なプロジェクトのプロファイリング
skills/honest-review/scripts/finding-formatter.py	Wave 3 の Judge — 検出結果を構造化 JSON に正規化（--format sarif をサポート）
skills/honest-review/scripts/review-store.py	レビュー履歴の保存、読み込み、一覧表示、差分表示
skills/honest-review/scripts/sarif-uploader.py	SARIF の結果を GitHub Code Scanning にアップロード
skills/honest-review/scripts/learnings-store.py	誤検出に関する学習内容の管理（追加、確認、一覧表示、消去）

テンプレート	レンダリングするタイミング
templates/dashboard.html	Judge による調整後 — 検出結果の JSON を data タグに挿入

重要なルール

1. トリアージ（Wave 0）を省略しないでください。リスク分類は、その後のすべての判断に影響します。
2. 重要度のある指摘には、必ず調査による根拠を添えてください。根拠がなければ破棄します。
3. 信頼度が 0.3 未満の場合は破棄します（ただし、P0/S0 は例外として未確認であることを明記して報告します）。
4. スタイルの好みを取り締まらないでください。コードベースの慣例に従います。ただし、AGENTS.md/CLAUDE.md に記載されたエージェントの動作ルール（ツールチェーン、認証、シークレット、安全上重要な指示）への違反は、Convention Violations ティアの重大度で指摘します。純粋なスタイルルール（書式、命名）は決して取り締まりません。
5. 実現不可能な条件を必要とする、実在しないバグを報告しないでください。
6. 指摘が 12 件を超える場合は、優先順位を付け直してください。検証済みの 5 件は、推測に基づく 50 件に勝ります。
7. Judge の照合（Wave 3）を省略しないでください。
8. 実装前に必ず提示してください（承認ゲート）。
9. 実装後は必ず検証してください（ビルド、テスト、動作）。
10. ファイルの担当範囲を重複させないでください。
11. 肯定的な指摘と建設的な指摘の比率を 3:1 に保ってください。比率が否定的に偏った場合は、重要度の低い指摘を再検討します。ただし、P0/P1 の指摘が 3 件以上ある場合は、比率にこだわらず、重大な指摘をすべて報告します。
12. 健全なコードベースであることを認めてください。P0/P1 または S0 の指摘がない場合は、その旨を明記します。
13. レビュー範囲ごとに、少なくとも 2 つの独創的な視点を適用してください。セキュリティ上重要なコードでは、Adversary の視点が必須です。
14. 参照ファイルは一度に 1 つだけ読み込んでください。すべての参照ファイルをあらかじめコンテキストに読み込まないでください。
15. 理想的な基準ではなく、コードベース独自の慣例に照らしてレビューしてください。
16. Judge の後に 2 件以上の指摘が残る場合は、自己検証（Wave 3.5）を実施してください。指摘がそれより少ない場合、または完全な縮退モードの場合は省略します。
17. 修正を実施する際は自動修正プロトコルに従ってください。差分をプレビューし、ユーザーの確認を得る前に修正を適用してはいけません。
18. トリアージ中に慣例ファイル（AGENTS.md、CLAUDE.md、.cursorrules）を確認し、プロジェクトで宣言されているルールに照らしてコードを検証してください。
19. すべての指摘に、指摘内容（WHAT）より前に推論の連鎖（WHY）を含めてください。
20. すべての指摘に、ソースに対して機械的に検証された引用アンカー [file:start-end] を含めてください。
21. Judge の Wave 3、Step 4 で学習記録を確認し、保存済みの誤検知却下に該当する指摘は抑制してください。
22. すべてのレビュー範囲で Code Reuse Reviewer を実行し、既存の同等実装については必ず file:line を示してください。
23. 再利用および簡素化の指摘では、事実を示す証拠（Grep）で十分です。パターンが有害な理由を確認する場合を除き、WebSearch は不要です。
24. インラインのみのレビューを行わないでください。ファイル数にかかわらず、コンテンツに適応したチーム全体を必ず起動してください。
25. Test Quality Reviewer は必ず起動してください。テストファイルが範囲内にある場合は 4 つの観点すべてからレビューし、テストファイルが範囲内にない場合は、変更された関数を対象とするテストがあるか Grep で検索し、テストされていないコードを指摘として報告してください。
26. AGENTS.md/CLAUDE.md の エージェントの動作ルール（ツールチェーン、認証、シークレット、安全性）への違反は、findings のチェックリストにある Convention Violations ティアに応じた重大度で指摘として報告します。スタイルのみの好み（書式、命名）は、ルール 4 に従い引き続き取り締まりません。
27. 承認後の実行ではオーケストレーション計画（Pattern E）を作成してください。修正を順番に適用せず、独立した変更はすべて並列化してください。