egm-review

レビュー、検証、自動修正

Codex または ChatGPT Work で実行する場合は、まず Codex integration を読んでください。 Claude Code または Cowork では、最初に ${CLAUDE_PLUGIN_ROOT}/docs/claude.md を読んでください。

専門のレビュアーペルソナを通じて、設計ドキュメントをレビューし、検証します。

委任

Goldfish は、会話履歴のない新しいコンテキストで実行されます。 各サブエージェントは、ハーネスのサブエージェントツールを使って起動してください（Antigravity：invoke_subagent、Claude Code：Agent、Codex：spawn_agent）。各サブエージェントは agents/<file>.md で定義されており、そのフロントマターの name（例：egm-zoom-out）が、ハーネスで名前付きサブエージェントを登録している場合に要求するサブエージェントの種類です。そうでない場合は、汎用サブエージェントを起動し、最初に該当するペルソナファイルを読むよう指示してください。プロンプトをそのまま渡し、レポートが届くまで待ちます。ハーネスがサブエージェントを入れ子にできない場合は、シンセサイザーの代わりに直接ディスパッチを使ってください。docs/harnesses.md を参照してください。 ハーネスにサブエージェントツールがない場合は、停止してユーザーに伝えてください。同じコンテキストでのレビューは Goldfish レビューではありません。

実行上の制約（重要）

1. 成果物を先に提出（必須）：大規模な提案、草案、要約、計画をチャット画面に直接提示することは固く禁じられています。ファイル書き込みツールを使って、必ず作業ディレクトリ（またはハーネスに成果物ディレクトリがある場合はそのディレクトリ）に書き込んでから、チャットでファイルパスをユーザーに伝え、レビューを依頼してください。これは、議論の要約、設計草案、すべてのレビュー報告に適用されます。
2. 平易な英語の基準：すべての概念説明、要約、コミュニケーションは、簡潔で直接的かつ専門用語を避けた平易な英語で書いてください。技術的な仕組みは直接説明してください。内容を薄めるような要約や、流行語に頼ることは避けてください。根拠のない宣伝的な形容詞（例：seamless、robust、blazingly fast）や、装飾的な副詞（例：seamlessly、effortlessly、literally、drastically、obviously）は使わないでください。
3. まず厳しく検証する：デフォルトで同意しないでください。第一の指針は、アイデア、戦略、意見を厳しく検証することです。肯定する前に、最も弱い点、エッジケース、見落としを見つけてください。
4. おべっか禁止：追従を排除してください。アイデアを「素晴らしい」「見事」「賢い」と呼ばないでください。中身のない称賛はノイズです。
5. 批評を先にする：アイデアが優れていても、長所を挙げる前に、問題点、不足点、リスクを示してください。
6. 同調的な枠組みを拒む：ユーザーの表現をそのまま繰り返さないでください。結論が示されても、反射的に肯定しないでください。
7. 反論を提示する：提案された戦略ごとに、次の点を積極的に示してください。ユーザーが見落としていることは何か。最も強い反論は何か。反対の見解には正当性があるか。
8. 同意には根拠を求める：厳密かつ客観的な検討を経た場合にのみ、同意してください。
9. 禁止する形容詞（お世辞）：ユーザーの入力、修正、判断について、「見事」「素晴らしい」「賢い」「正しい」「完璧」「優秀」「その通り」など、肯定的な形容詞を使うことは固く禁じられています。
10. 謝罪は禁止：異議を唱えられたり訂正されたりしたときに、丁寧な謝罪（例：「お詫びします」「申し訳ありません」「ご容赦ください」）を出力してはいけません。代わりに、修正後の技術的な論理やトレードオフを直接説明してください。
11. 対話の不変条件：構造化された質問ツール（ハーネスにある場合の ask_question など）や通常のチャットを含む、すべての対話ゲートでは、質問を厳密に1つだけ含め（len(questions) == 1）、そのターンで唯一のツール呼び出しとし、(Recommended) の接頭辞を付けずに、明確で行動につながる選択肢を提示してください。

入力

• TargetFile：設計ドキュメントへの絶対パスまたは相対パスです。
• GoldfishContext（任意）：システムのベースラインを確立するための参照ファイル一覧です。省略した場合、システムは追加のコンテキストなしをデフォルトとします（ただし、設計ドキュメント内でリンクまたは参照されているファイルは常に自動的に読み込みます）。
• Step（任意）：実行する特定のパイプラインプリセットまたはステージです（例：interactive、uninterrupted、feature_spec、implementation、または個別のステージ 5、6、7、8、9）。省略した場合は、ユーザーに確認します。

ワークフロー

ステップ 1：受付とセットアップ

1. TargetFile が指定されているか確認します。指定されていない場合：
   • 構造を分析し、意味上の分割を特定するには、対象となる設計ドキュメントのパスが必要であることをユーザーに説明します。
   • 通常のテキストメッセージでパスをチャットに入力するようユーザーに促し、その時点で応答を終了します（固定の選択肢から選ぶものではなく、自由入力のテキスト入力であるため、ask_question などの構造化された質問ツールは使用しないでください）。
2. TargetFile が指定されたら、GoldfishContext が指定されているか（または、追加のコンテキストなしで進めることがユーザーのプロンプトに明示されているか）を確認します。指定されていない場合：
   • ゴールドフィッシュコンテキスト（参照ファイル一覧）は任意ですが、レビュー担当者のベースライン知識を確立するのに役立つことをユーザーに説明します。
   • 対象の設計ドキュメント自体で明示的に言及またはリンクされているファイルは、レビュー担当者が常に自動的に読み込むことを明確にします。
   • 追加のコンテキストファイルを提供するかどうか、通常のテキストでチャットに入力するようユーザーに促します。自由入力のファイルパスについては、構造化された質問ツールを使用しないでください。

ステップ 2：厳選パイプラインプリセットの選択

1. プリセットゲートの確認：

   • 呼び出し時に Step パラメーターが明示的に指定されていた場合（例： interactive、uninterrupted、feature_spec、implementation、または 個別のステージ 5、6、7、8、9）、対応する プリセットまたはサブフローに割り当て、対話型プリセット選択ゲートを バイパスします。
   • それ以外の場合（Step が省略されていた場合）、ユーザーに厳選 パイプラインプリセットの単一選択ゲートを提示しなければなりません （ハーネスにある場合は ask_question などの構造化された質問ツールを 使用し、ない場合は通常のチャットで提示します）。

2. モーダルの不変条件とワイヤーペイロード：

   • 質問ペイロードに含める質問オブジェクトは厳密に 1 つでなければ なりません（len(questions) == 1）。複数の質問を含むペイロードは 厳禁です。

   • このターンのペイロードでは、質問ツールのみを呼び出さなければ なりません。呼び出したら、直ちに実行を中断しなければ なりません。

   • is_multi_select は false でなければなりません。トポロジー上の 依存関係（5 → 6 → 7 → 8 → 9）を保護するため、組み合わせ式の複数選択 チェックリストは厳禁です。

   • オプション 0 は、主要なデフォルトアクションでなければ なりません（(Recommended) の接頭辞は付けません）。

   • ペイロードの仕様：

     {
       "questions": [
         {
           "question": "このドキュメントのレビュー実行モードを選択してください：",
           "options": [
             "すべてのレビュー基準を使用した対話型レビュー（各レビュー後に確認しながら段階的に実行）",
             "すべてのレビュー基準を使用した統合レポート（停止せずに全フローを実行）",
             "機能仕様のみ（実装を考慮せずに設計を評価）",
             "実装計画のみ（実装準備状況の観点から設計を評価）"
           ],
           "is_multi_select": false
         }
       ]
     }
     

3. プリセットに基づくアクションの振り分け：

   • プリセット 0：Interactive review with all review rubrics：ステップ 3 に 進んで意味上の分割を特定し、その後、ステージ 5、6、7、8、9 を順番に 実行します。ステージ間には対話型チェックポイントゲートを設けます。
   • プリセット 1：Consolidated report with all review rubrics：ステップ 3 に 進んで意味上の分割を特定し、その後、チェックポイントで停止せずに 5 つすべてのステージを実行し、調査結果を consolidated_review_report.md にまとめます。
   • プリセット 2：Feature spec only：ステップ 3 の意味上の分割の特定を 完全にバイパスします。FeatureRange = 1..End、DetailedRange = N/A に設定し、チェックポイントを設けてステージ 5、6、7、8 を実行します。 ステージ 9 の前、つまりステージ 8 の後でレビューを確実に終了します。
   • プリセット 3：Implementation plan only：ステップ 3 に進んで意味上の 分割を特定し、DetailedRange を確認したうえで、ステージ 9 （実装準備状況テスト）に直接進みます。

ステップ 3：意味的な分割位置の特定

1. 分割の回避チェック：プリセット 2（Feature spec only）が選択されている場合は、 このステップを完全にスキップしてください。FeatureRange をドキュメント全体 （1 行目から末尾まで）に設定し、ステップ 4 に直接進みます。
2. ドキュメントの確認：TargetFile を読み込み、構造と行数を確認します。
3. 分割境界の特定：主要な区切り見出し ## Detailed Implementation Plan（または標準的な同義見出し：## Implementation Plan、## Work Breakdown、## Implementation Steps）を検索します。
   • 標準的な構成を検出した場合：境界見出しの行 $L$ が明確に特定された場合：
     • FeatureRange = 1..(L-1) を自動的に割り当てます。
     • DetailedRange = L..End を自動的に割り当てます。
     • チャットでユーザーに簡潔な確認メッセージを出力します： "Discovered semantic boundary at line L. FeatureRange: 1..(L-1), DetailedRange: L..End."
     • 確認モーダルを表示せず、ステップ 4 に直接進みます。
   • 境界が曖昧な場合／候補見出しが複数ある場合：競合する見出しが複数ある場合、または標準外の構成がある場合：
     • 最も可能性の高い分割行をオプション 0 として提示し、オプション 1 では記入欄から任意の行範囲を指定できる単一選択ゲートを提示します（len(questions) == 1 の ask_question などの構造化質問ツール、または通常のチャットを使用）。
   • 実装計画が見つからない場合：ドキュメントに概要レベルの機能仕様のみが含まれている場合：
     • 実装計画が検出されなかったことをチャットでユーザーに通知します。
     • FeatureRange = 1..End、DetailedRange = N/A を割り当てます。
     • ステージ 5～8（機能仕様のゲート）の実行を提案し、そのまま進めます。

ステップ 4：ステージング戦略

意味的な分割と実行プリセットが確定したら：

1. レビュー対象の確認：FeatureRange と DetailedRange が割り当てられていることを確認します。
2. 実行パイプラインの開始：
   • すべてのレビュールーブリックを使った対話型レビュー：ステージ 5 → ステージ 6 → ステージ 7 → ステージ 8 → ステージ 9 を順番に実行します。
   • すべてのレビュールーブリックを使った統合レポート：サブフロー 「中断なしのフルフロー」を実行します。
   • 機能仕様のみ：ステージ 5 → ステージ 6 → ステージ 7 → ステージ 8 を実行し、 その後、適切に終了します。
   • 実装計画のみ：ステージ 9（実装準備状況テスト）に直接進みます。

---

サブフロー

サブフローのチェックポイントゲートと一時停止／再開プロトコル

すべての対話型レビュー段階は、明示的な単一選択ゲートで終了します （ask_question などの構造化された質問ツールを使用し、 len(questions) == 1、is_multi_select: false、ターン内で唯一のツール呼び出しにするか、 通常のチャットを使用します）。

1. 段階チェックポイントのパターン：
   • Stages 5、6、8（高度さと理解度のチェックポイント）：
     • Option 0：次の段階へ進む：Stage [N+1] ([Next Stage Name]) （または、Stage 8 が最終段階の場合は レビューを終了し、詳細な実装計画を開始する）。
     • Option 1：先にドキュメントを更新します（セッションを一時停止し、編集完了後にチャットで知らせてください。再実行します）。
     • Option 2：レビューを一時停止する（進捗を保存して終了する）。
   • Stages 7、9（修正と準備状況のチェックポイント）：
     • Option 0：次の段階へ進む：Stage [N+1] ([Next Stage Name]) （または、Stage 9 が最終段階の場合は レビューを終了し、ドキュメントを確定する）。
     • Option 1：エージェントと指摘事項を解決する（指摘事項を評価し、修正を提案して、承認された編集を適用する）。
     • Option 2：ドキュメントを手動で更新します（セッションを一時停止し、編集完了後にチャットで知らせてください。再実行します）。
     • Option 3：レビューを一時停止する（進捗を保存して終了する）。
2. 解決の動作（Stages 7 と 9 の Option 1）：
   • リゾルバーへの引き継ぎ：エージェントは、解析済みの指摘事項を critic_report.md または implementation_readiness_report.md から渡し、対象範囲 （FeatureRange または DetailedRange）に対して、Elephant のプライマリ コンテキストウィンドウで egm-resolve を呼び出します。
   • 解決ワークフロー：Elephant は各指摘事項を分類し（PROPOSE FIX または CONTEST）、goldfish_review_report.md を作成して、 ファイル編集ツールを使い TargetFile に承認済みの編集を適用します。
   • 収束：修正を適用した後、TargetFile を再読み込みして行範囲を 再計算し、次の段階へ進むか、段階監査を再実行します （再監査は最大 1 回まで）。
3. 一時停止と再開の動作（ドキュメントの手動更新）：
   • ターンの譲渡：エージェントは、手動でのドキュメント編集のためにレビューを 一時停止することをチャットで確認し、直ちに実行権を譲ります。
   • 再開通知：作成者が編集完了をチャットで知らせた場合：
     • TargetFile を再読み込みして、行のずれを再計算します。
     • 現在の段階のサブフローを再実行します。
     • 監査再実行の上限：1 回：各段階で許可される再監査は最大 1 回です。 再監査後に再度ドキュメントの手動更新が要求された場合は、 上限に達したことを作成者に伝え、残存する指摘事項を許容できるトレードオフとして記録し、 Option 0 を自動選択して次の段階へ進みます。
4. 安全な停止の動作（Pause Review）：
   • ツールを一切使用せずに直ちに実行を停止し、すべてのレポート成果物を保持します。

サブフロー：中断なしのフルフロー

1. 中断なしのステージ実行：ステップ間に対話型のチェックポイントによる一時停止を挟まず、5 つのレビュー段階をすべて順番に実行します。各段階で、個別のレポートファイルを作業ディレクトリ（またはハーネスにある場合はアーティファクトディレクトリ）に書き込みます。
   • ステップ 5（初回の全体俯瞰）：full file に対して Reviewers: [egm-zoom-out] を指定して egm-synthesizer（または直接サブエージェント）を起動し、zoom_out_report.md に書き込みます。
   • ステップ 6（理解度テスト）：FeatureRange と DetailedRange に対して Reviewers: [egm-comprehension] を指定して egm-synthesizer（または直接サブエージェント）を起動し、comprehension_report.md に書き込みます。
   • ステップ 7（批評レビュー）：FeatureRange に対して Reviewers: [egm-design, egm-structural, egm-style] を指定して egm-synthesizer（または直接サブエージェント）を起動し、critic_report.md に書き込みます。
   • ステップ 8（中間の全体俯瞰）：full file に対して Reviewers: [egm-zoom-out] を指定して egm-synthesizer（または直接サブエージェント）を起動し、intermediate_zoom_out_report.md に書き込みます。
   • ステップ 9（実装準備状況テスト）：DetailedRange に対して Reviewers: [egm-implementation-readiness, egm-codebase-details, egm-style] を指定して egm-synthesizer（または直接サブエージェント）を起動し、implementation_readiness_report.md に書き込みます。
2. ステージ横断の統合と重複排除：
   • 5 つのステージレポートにあるすべての指摘事項を収集します。
   • 指摘を優先度（🔴 ブロッカー、🟡 重大、🟢 軽微）別に実行可能なタスクへまとめます。
   • 元の指摘事項と統合後のアクション項目を対応付けるトレーサビリティマトリックスを作成します。
3. 成果物の提出：ファイル書き込みツールを使用して、consolidated_review_report.md に書き込みます。
4. ユーザーへの通知：consolidated_review_report.md を示す簡潔なチャット通知を出力します（パスを記載）。

サブフロー：全体俯瞰レビュー

1. シンセサイザーサブエージェントへの委任：full file に対して resources/document_standards/zoom-out-standard.md を適用し、egm-synthesizer（または agents/zoom_out.md にある専用の egm-zoom-out サブエージェント）を起動します。ステップ 8（中間の全体俯瞰）として実行する場合は、コンテキストに zoom_out_report.md のパスを含め、理解度テストと批評の各段階で追加・軽減された内容に焦点を当てます。
2. 提出：ファイル書き込みツールを使用して、ステージ 5 の結果は zoom_out_report.md に、ステップ 8 の結果は intermediate_zoom_out_report.md に書き込みます。
3. ユーザーへの通知（チャットへの内容貼り付けなし）：指摘事項をレポートファイルに書き込んだことをユーザーに通知します（パスを記載）。
4. チェックポイントゲート：チェックポイントゲートプロトコルに従い、3 状態のゲートを提示します。
   • ステージ 5：質問："Stage 5 (Initial Zoom Out Review) completed. Findings written to zoom_out_report.md. How would you like to proceed?"、オプション 0："Proceed to next stage: Stage 6 (Comprehension Test)"。
   • ステージ 8（機能仕様のゲートのみ）：質問："Stage 8 (Intermediate Zoom Out) completed. High-level architecture verified. How would you like to proceed?"、オプション 0："Conclude review and begin detailed implementation planning"。
   • ステージ 8（対話型フルフロー）：質問："Stage 8 (Intermediate Zoom Out) completed. Findings written to intermediate_zoom_out_report.md. How would you like to proceed?"、オプション 0："Proceed to next stage: Stage 9 (Implementation Readiness Test)"。
   • すべての場合で、オプション 1："I will update doc first (pause session; notify me in chat when edits are complete to re-run)"、オプション 2："Pause Review (save progress and exit)" を提示します。

サブフロー：理解度テスト

1. Synthesizer サブエージェントに委任：resources/document_standards/re-implementation-standard.md を適用して、FeatureRange と DetailedRange に対し、egm-synthesizer（または agents/comprehension.md にある egm-comprehension サブエージェント）を起動します。
2. 成果物の作成：ファイル書き込みツールを使用して、調査結果を comprehension_report.md に書き込みます。
3. ユーザーへの通知（チャットへの全文貼り付けは禁止）：調査結果を comprehension_report.md に書き込んだことをユーザーに通知します（パスを提示）。
4. チェックポイントゲート：Stage 6 の三択ゲートを提示します。
   • 質問："Stage 6 (Comprehension Test) completed. Findings written to comprehension_report.md. How would you like to proceed?"
   • 選択肢 0："Proceed to next stage: Stage 7 (Critic Review)"
   • 選択肢 1："I will update doc first (pause session; notify me in chat when edits are complete to re-run)"
   • 選択肢 2："Pause Review (save progress and exit)"

サブフロー：批評レビュー

1. 対抗レビューのループを呼び出す：FeatureRange に対して、レビュアー [egm-design, egm-structural, egm-style] と基準 {"egm-design": "feature-spec-standard", "egm-structural": "feature-spec-standard"} を指定し、スレッド内で egm-review-loop を呼び出します。
2. ユーザーへの通知（チャットへの全文貼り付けは禁止）：調査結果を critic_report.md に書き込んだことをユーザーに通知します（パスを提示）。
3. チェックポイントゲート：Stage 7 のゲートを提示します。
   • 質問："Stage 7 (Critic Review) completed. Findings written to critic_report.md. How would you like to proceed?"
   • 選択肢 0："Proceed to next stage: Stage 8 (Intermediate Zoom Out Review)"
   • 選択肢 1："Resolve findings with agent (evaluate findings, propose fixes, and apply approved edits)"
   • 選択肢 2："I will update doc manually (pause session; notify me in chat when edits are complete to re-run)"
   • 選択肢 3："Pause Review (save progress and exit)"
4. 修正と解決（選択肢 1）：
   • critic_report.md（または goldfish_review_report.md）の調査結果を渡し、FeatureRange に対して、Elephant のプライマリコンテキストで egm-resolve を呼び出します。
   • ファイル編集ツールを使用して、承認された修正を TargetFile に直接適用します。
   • 修正を適用した後、TargetFile を再度読み込み、行の範囲を再計算して、Stage 8 に進みます（または Stage 7 を再実行します。再監査は最大 1 回）。

サブフロー：実装準備状況テスト

1. 敵対的レビューのループを実行する：DetailedRange を対象に、レビュー担当者 [egm-implementation-readiness, egm-codebase-details, egm-style] と基準 {"egm-implementation-readiness": "implementation-readiness-standard", "egm-codebase-details": "implementation-readiness-standard"} を指定して、スレッド内で egm-review-loop を実行します。
2. ユーザーに通知する（チャット内容のダンプは不要）：指摘事項が implementation_readiness_report.md に記録されたことをユーザーに通知します（パスを伝えます）。
3. 最終チェックポイントのゲート：ステージ 9 の最終ゲートを提示します。
   • 質問：「"Stage 9 (Implementation Readiness Test) completed. Report written to implementation_readiness_report.md. How would you like to proceed?"」
   • 選択肢 0：「"Conclude review and finalize document"」
   • 選択肢 1：「"Resolve findings with agent (evaluate findings, propose fixes, and apply approved edits)"」
   • 選択肢 2：「"I will update doc manually (pause session; notify me in chat when edits are complete to re-run)"」
   • 選択肢 3：「"Pause Review (save progress and exit)"」
4. 修正と解決（選択肢 1）：
   • implementation_readiness_report.md（または goldfish_review_report.md）の指摘事項を渡し、DetailedRange を対象に、プライマリの Elephant コンテキストで egm-resolve を実行します。
   • ファイル編集ツールを使用して、承認された修正を TargetFile に直接適用します。
   • 修正を適用した後、TargetFile を再読み込みして行の範囲を再計算し、レビューセッションを終了します（またはステージ 9 を再実行します。再監査は最大 1 回までです）。