omc-plan

Plan は、インテリジェントな対話を通じて、包括的で実行可能な作業計画を作成します。ユーザーへの聞き取り（幅広い依頼の場合）と直接の計画策定（詳細な依頼の場合）を自動判別し、コンセンサスモード（RALPLAN-DR による構造化された検討を含む Planner／Architect／Critic の反復ループ）とレビューモード（既存の計画に対する Critic の評価）をサポートします。

<Use_When>

• ユーザーが実装前に計画を立てたい場合：「これを計画して」「〜の計画を立てて」「計画を立てましょう」
• 曖昧なアイデアについて、体系的な要件の整理を求めている場合
• 既存の計画をレビューしてほしい場合：「この計画をレビューして」、--review
• 計画について複数の視点からコンセンサスを求めている場合：--consensus、「ralplan」
• タスクの範囲が広い、または曖昧で、コードを書く前に範囲を明確にする必要がある場合 </Use_When>

<Do_Not_Use_When>

• ユーザーがエンドツーエンドの自律実行を求めている場合：代わりに autopilot を使用してください
• ユーザーが明確なタスクについて、すぐにコーディングを始めたい場合：ralph を使用するか、executor に委任してください
• ユーザーが直接回答できる簡単な質問をしている場合：そのまま回答してください
• タスクが範囲の明確な単一の修正である場合：この計画モジュールを実行するのではなく、実行用スキルを使用してください </Do_Not_Use_When>

<Why_This_Exists> 要件を理解せずにコードに着手すると、手戻りやスコープクリープ、エッジケースの見落としにつながります。Plan は、体系的な要件整理、専門家による分析、品質ゲートを満たす計画を提供し、確かな基盤に基づいて実行を開始できるようにします。コンセンサスモードは、重要度の高いプロジェクトに複数の視点からの検証を追加します。 </Why_This_Exists>

<Execution_Policy>

• 依頼の具体性に基づいて、聞き取りモードと直接モードを自動判別します
• 聞き取りでは、一度に質問を一つだけ行います。複数の質問をまとめて尋ねてはいけません
• ユーザーに確認する前に、explore エージェントを使ってコードベースの情報を収集します
• 計画は品質基準を満たす必要があります：主張の 80％ 以上にファイル／行の引用があり、基準の 90％ 以上がテスト可能であること
• コンセンサスモードは、デフォルトでは完全に自動で実行されます。ドラフトレビューと最終承認の段階でユーザーに確認するには、--interactive を追加します
• コンセンサスモードでは、デフォルトで RALPLAN-DR のショートモードを使用します。--deliberate を指定するか、依頼で高リスクが明示されている場合（認証／セキュリティ、データ移行、破壊的／不可逆な変更、本番環境のインシデント、コンプライアンス／PII、公開 API の破壊的変更）は、熟慮モードに切り替えます
• **計画／実行の境界：**計画モードではコンテキストを調査し、計画／仕様／提案のみを作成します。ユーザーが現在のターン内、または構造化された承認 UI を通じて実行を明示的に許可していない限り、成果物には必ず pending approval と記載します。実行について明示的な承認を得る前に、計画モードで変更を伴うシェルコマンドの実行、ソースファイルの編集、コミット、プッシュ、PR の作成、実行用スキルの呼び出し、実装タスクの委任を行ってはいけません
• **Goal ワークフローの境界：**計画で Claude Code /goal、Ralph、Team、または成果物のみの Ultragoal を比較する場合、主要なループの制御元を正確に一つ特定し、非決定的な警告処理ではなく、決定論的な競合ポリシー refuse、adopt_existing、artifact_only を使用します。/goal に関する事実は Claude Code／Anthropic の情報源のみを引用する必要があります（Claude Code /goal のドキュメント：https://code.claude.com/docs/en/goal、Anthropic Claude Code の変更履歴：https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md）。また、計画で /goal の評価器が独自にコマンドを実行したりファイルを読み取ったりすると主張してはいけません。完了を主張する前に、提示された証拠を必須とします
• **Goal ワークフローのドキュメント参照先：**ユーザー向けの比較では、例を docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection および docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal に準拠させます </Execution_Policy>

### モードの選択

モード	トリガー	動作
インタビュー	幅広いリクエストの場合はデフォルト	対話形式で要件を収集します
ダイレクト	--direct、または詳細なリクエスト	インタビューを省略し、計画を直接生成します
コンセンサス	--consensus、"ralplan"	RALPLAN-DR の構造化された議論により合意に至るまで、プランナー -> アーキテクト -> 批評者のループを実行します（デフォルトでは簡潔に行い、リスクが高い場合は --deliberate を指定します）。草案と承認の各段階でユーザーに質問するには、--interactive を追加します
レビュー	--review、"review this plan"	既存の計画を批評者が評価します

インタビューモード（幅広い／曖昧なリクエスト）

1. リクエストを分類する：幅広いリクエスト（曖昧な動詞、特定のファイルの指定がない、3 つ以上の領域に関わる）では、インタビューモードを開始します
2. 焦点を絞った質問を 1 つする：AskUserQuestion を使って、希望、対象範囲、制約を確認します
3. まずコードベースの事実を集める：「コードではどのようなパターンを使っていますか？」と尋ねる前に、explore エージェントを起動して調査し、その結果を踏まえた追加質問をします
4. 回答を踏まえて進める：各質問は前の回答を踏まえて行います
5. アナリスト（Opus）に相談する：隠れた要件、エッジケース、リスクを確認します
6. 計画を作成する：ユーザーが準備できたことを示したら作成します：「計画を作成して」「準備ができました」「作業計画を作って」

ダイレクトモード（詳細なリクエスト）

1. 簡易分析：必要に応じて、アナリストへの簡単な相談を行います
2. 計画を作成する：包括的な作業計画をただちに生成します
3. レビュー（任意）：依頼があれば、批評者によるレビューを行います

コンセンサスモード（--consensus / "ralplan"）

RALPLAN-DR のモード：簡潔（デフォルト。構造を限定）と熟慮（--deliberate を指定した場合、または明示的に高リスクのリクエストがあった場合）があります。どちらのモードでも、プランナー -> アーキテクト -> 批評者の順序と、同じ AskUserQuestion の確認ポイントを維持します。

プロバイダーの上書き（プロバイダーの CLI がインストールされている場合にサポート）：

• --architect codex — Claude のアーキテクト工程を omc ask codex --agent-prompt architect "..." に置き換え、実装中心のアーキテクチャレビューを行います
• --critic codex — Claude の批評者工程を omc ask codex --agent-prompt critic "..." に置き換え、実行前に外部レビューを行います
• 指定されたプロバイダーを利用できない場合は、そのことを簡潔に伝え、その工程ではデフォルトの Claude アーキテクト／批評者の手順を続行します

状態のライフサイクル：永続モードの停止フックは ralplan-state.json を使い、コンセンサスループ中の続行を強制します。このスキルはこの状態を管理しなければなりません。

• 開始時：ステップ 1 の前に、state_write(mode="ralplan", active=true, session_id=<current_session_id>) を呼び出します
• 実行への引き継ぎ時（承認 → ralph/team）：state_write(mode="ralplan", active=false, session_id=<current_session_id>) を呼び出します。この場面では state_clear を使用しないでください。state_clear は 30 秒間のキャンセル信号を書き込み、すべてのモードで停止フックの適用を無効にするため、新たに開始した実行モードが保護されなくなります。
• 実際に処理を終了する場合（却下、対話なしでの計画出力、エラー／中断）：state_clear(mode="ralplan", session_id=<current_session_id>) を呼び出します。後続の実行モードはないため、キャンセル信号の有効期間は問題ありません。
• Critic の承認や最大反復回数に達した際の提示など、中間ステップではクリアしないでください。ユーザーが「変更を依頼」を選択する可能性があります。

クリーンアップを行わないと、コンセンサスワークフローの終了後も、停止フックが [RALPLAN - CONSENSUS PLANNING] の強化メッセージを表示して、その後の停止をすべてブロックします。他の並行セッションの状態をクリアしないよう、必ず session_id を渡してください。

1. プランナーは、アーキテクトによるレビューの前に初期計画と簡潔な RALPLAN-DR の要約を作成します。この要約には、次の項目を必ず含めます。
   • 原則（3〜5 項目）
   • 意思決定の判断基準（上位 3 項目）
   • 実行可能な選択肢（2 つ以上）。各選択肢について、範囲を明確にした長所と短所を記載
   • 実行可能な選択肢が 1 つしかない場合は、却下した代替案が無効である理由を明示
   • 慎重モードでは、事前検死（失敗シナリオ 3 件）と、ユニット／統合／E2E／可観測性を網羅する拡張テスト計画
2. ユーザーからのフィードバック（--interactive の場合のみ）：--interactive で実行する場合は、初期段階で方針をすり合わせるため、計画の草案と RALPLAN-DR の「原則／意思決定の判断基準／選択肢」の要約を提示する際に、必ず AskUserQuestion を使用し、次の選択肢を提示します。
   • レビューに進む — アーキテクトと Critic に送って評価を受ける
   • 変更を依頼 — ユーザーからのフィードバックを反映し、ステップ 1 に戻る
   • レビューをスキップ — 最終承認（ステップ 7）に直接進む --interactive で実行していない場合は、自動的にレビュー（ステップ 3）へ進みます。
3. アーキテクトは、Task(subagent_type="oh-my-claudecode:architect", ...) を使用して、アーキテクチャの妥当性をレビューします。アーキテクトのレビューには、支持されている選択肢に対する最も強力な反論（反対命題）、少なくとも 1 つの重要なトレードオフ、および（可能であれば）統合案を必ず含めます。慎重モードでは、原則に反する点を明示してください。アーキテクトはステップ 1 でプランナーが作成した、変更されていない同一の計画スナップショットを評価しなければなりません。アーキテクトによる評価結果を Critic に渡してはいけません。
4. Criticは、Task(subagent_type="oh-my-claudecode:critic", ...) を使用して、品質基準に照らして評価します。Critic は、原則と選択肢の整合性、代替案の公平な検討、リスク緩和策の明確さ、テスト可能な受け入れ基準、具体的な検証手順を必ず確認します。浅薄な代替案、判断基準の矛盾、曖昧なリスク、または不十分な検証は、Critic が明示的に却下しなければなりません。慎重モードでは、不足または不十分な事前検死や拡張テスト計画があれば、Critic は必ず却下しなければなりません。Critic は、アーキテクトのレビューから独立して、同一の固定された計画スナップショットを評価しなければなりません。そのため、個別に Task を呼び出して、完了を待つ必要があります。Critic は、アーキテクトのレビューを参照したり受け取ったりしてはいけません。

   同じ固定プランスナップショットに対する、状況に応じた独立した並列または逐次レビュー。 Architect と Critic は、それぞれステップ 1 で Planner が作成した同じ固定プランスナップショットをレビューします。どちらのレビューもスナップショットを変更しません。Architect の出力を Critic に渡してはなりません。Architect と Critic がどちらも Claude エージェントを使用する場合（デフォルト）、バックグラウンドサブエージェントとして並列実行してもかまいません。 Architect または Critic のいずれかが外部プロバイダー（例：--architect codex、--critic codex）を使用する場合は、レート制限エラーによる兄弟タスクの連鎖障害を防ぐため、個別に待機する別々の Task 呼び出しとして、必ず逐次実行してください。並列実行は禁止です。 Critic は Architect のレビューを参照したり、受け取ったりしてはなりません。Architect と Critic の結果は、両方のレビューが完了した後に限り、改訂または改善点の統合時に Planner のみが組み合わせます。

5. 再レビューのループ（最大 5 回）：Critic が却下した場合、次の閉ループを実行します。 a. Architect と Critic からの却下フィードバックをすべて収集します（Planner のみが統合：Architect と Critic の結果は、両方のレビューが完了した後に限り、Planner のみが組み合わせます）。 b. フィードバックを Planner に渡し、改訂プランを作成します c. ステップ 3 に戻る — Architect が改訂プランをレビューします d. ステップ 4 に戻る — Critic が改訂プランを評価します e. Critic が承認するか、最大 5 回に達するまで繰り返します f. 承認されないまま最大回数に達した場合は、専門家間の合意に至らなかった旨を添えて、AskUserQuestion で最善のプランをユーザーに提示します
6. 改善点の適用：レビュアーが改善提案付きで承認した場合、次に進む前に、受け入れた改善点をすべてプランファイルに反映します。最終的な合意結果には、Decision、Drivers、Alternatives considered、Why chosen、Consequences、Follow-upsを含む ADR セクションを必ず含めます。具体的には、次のとおりです。 a. Architect と Critic の回答から、改善提案をすべて収集します b. 提案の重複を取り除き、分類します c. .omc/plans/ のプランファイルを更新し、受け入れた改善点を反映します（不足している詳細の追加、手順の改善、受け入れ基準の強化、ADR の更新など） d. 適用した改善点を、プラン末尾の簡潔な変更履歴セクションに記録します
7. Critic の承認後（改善点の適用後）：明示的な実行承認がすでに得られていない限り、プランのステータスを pending approval に設定します。（--interactive の場合のみ） --interactive で実行している場合は、AskUserQuestion を使って次の選択肢とともにプランを提示します。
   • Approve execution via team（推奨）— 調整された並列チームエージェント（/team）を通じて進める明示的なオプトインです。v4.1.7 以降、Team は標準のオーケストレーション手段です。
   • Approve execution via ralph — 検証を伴う Ralph の永続実行を通じて進める明示的なオプトインです
   • Compact then return for execution approval — まずコンテキストウィンドウを圧縮する明示的なオプトインです（プランニング後にコンテキストが大きい場合に推奨）。その後、保存済みの承認待ちプランで停止し、実行を開始する前に再度確認を求めます
   • Request changes — ユーザーのフィードバックを受けてステップ 1 に戻ります
   • Reject — プランを完全に破棄します --interactive で実行していない場合は、pending approval としてマークした最終プランを出力し、state_clear(mode="ralplan", session_id=<current_session_id>) を呼び出して停止します。自動実行してはなりません。
8. （--interactive の場合のみ） ユーザーは構造化された AskUserQuestion UI から選択します（プレーンテキストで承認を求めてはなりません）。ユーザーが Reject を選択した場合は、state_clear(mode="ralplan", session_id=<current_session_id>) を呼び出して停止します。
9. ユーザーの承認後（--interactive の場合のみ）：実行スキル（ralph/team）を呼び出す前に、state_write(mode="ralplan", active=false, session_id=<current_session_id>) を呼び出します。これにより、ストップフックが実行モード独自の制御を妨げないようにします。ここで state_clear を使用してはなりません。これは、起動した新しいモードの制御を無効化するキャンセルシグナルを書き込みます。
   • Approve execution via team：承認済みプランの .omc/plans/ 内のパスをコンテキストとして、必ず Skill("oh-my-claudecode:team") を呼び出してください。直接実装してはなりません。Team スキルは、ステージ分けされたパイプライン全体で並列エージェントを調整し、大規模なタスクをより速く実行します。これは推奨されるデフォルトの実行経路です。
   • Approve execution via ralph：承認済みプランの .omc/plans/ 内のパスをコンテキストとして、必ず Skill("oh-my-claudecode:ralph") を呼び出してください。直接実装してはなりません。プランニングエージェント内でソースコードファイルを編集してはなりません。永続的な実行と検証は Ralph スキルが担います。
   • Compact then return for execution approval：まず Skill("compact") を呼び出してコンテキストウィンドウを圧縮します（プランニング中に蓄積したトークン使用量を減らします）。その後、保存済みの承認待ちプランのパスを提示して戻り、ralph/team を起動する前に、新たな明示的な実行承認を必ず得てください。プランニングセッション後にコンテキストウィンドウが 50% 以上埋まっている場合は、この方法を推奨します。

レビューモード（--review）

1. .omc/plans/ から計画ファイルを読み込みます
2. Task(subagent_type="oh-my-claudecode:critic", ...) を使用して Critic による評価を行います
3. 判定を返します：APPROVED、REVISE（具体的なフィードバックを添える）、または REJECT（計画の再作成が必要）

計画の出力形式

すべての計画には、以下を含めます。

• 要件の概要
• 受け入れ基準（テスト可能なもの）
• 実装手順（ファイル参照を含む）
• リスクと軽減策
• 検証手順
• consensus/ralplan の場合：RALPLAN-DR の概要（原則、意思決定の要因、選択肢）
• consensus/ralplan の最終出力の場合：ADR（決定、要因、検討した代替案、選択理由、影響、フォローアップ）
• deliberate consensus モードの場合：プレモーテム（3つのシナリオ）と拡張テスト計画（ユニット／統合／E2E／オブザーバビリティ）

計画は .omc/plans/ に保存します。ドラフトは .omc/drafts/ に保存します。

<Tool_Usage>

• 希望に関する質問（範囲、優先度、スケジュール、リスク許容度）には AskUserQuestion を使用します。クリック可能な UI が表示されます
• 特定の値（ポート番号、名前、追加の確認事項）が必要な質問には、プレーンテキストを使用します
• ユーザーに質問する前にコードベースの事実を収集するには、explore エージェント（Haiku、タイムアウト 30 秒）を使用します
• 大規模な計画の検証には Task(subagent_type="oh-my-claudecode:planner", ...) を使用します
• consensus モードと review モードでの計画レビューには Task(subagent_type="oh-my-claudecode:critic", ...) を使用します
• consensus モードでのエージェント呼び出しは状況に応じて行います： Architect と Critic の両方が Claude エージェント（デフォルト）の場合、バックグラウンドサブエージェントとして並行実行してもかまいません。いずれかが外部プロバイダー（codex など）を使用する場合は、レート制限による兄弟エージェントの連鎖的な失敗を避けるため、必ず順次実行します。両方のレビューでは同じ固定の計画スナップショットを使用します。Architect の出力が Critic に渡されることはありません。結果は、両方のレビュー完了後に Planner が統合する際にのみ組み合わせます。
• consensus モードでは、デフォルトで RALPLAN-DR の短縮モードを使用します。--deliberate が指定された場合、または明示的に高リスクを示す要素（認証／セキュリティ、移行、破壊的変更、本番環境のインシデント、コンプライアンス／PII、公開 API の互換性破壊）がある場合は、deliberate モードを有効にします
• consensus モードで --interactive を指定した場合、ユーザーのフィードバック手順（手順 2）と最終承認手順（手順 7）には AskUserQuestion を使用します。プレーンテキストで承認を求めてはいけません。--interactive を指定しない場合は、両方のプロンプトを省略し、計画に pending approval と記載して最終計画を出力し、終了します。
• consensus モードで --interactive を指定し、ユーザーが明示的に承認した場合、実行（手順 9）には必ず Skill("oh-my-claudecode:ralph") または Skill("oh-my-claudecode:team") を呼び出します。計画エージェントが直接実装してはいけません。
• 実行が明示的に承認される前に、計画モードで変更を伴うシェルコマンドを実行したり、ファイルを編集したり、コミット、プッシュ、PR の作成、実行スキルの呼び出し、実装タスクの委任を行ってはいけません。コンテキストの確認と、計画／仕様／提案のアーティファクトの作成・更新のみ可能です。
• --interactive で手順 7 の「Compact then return for execution approval」が選択された場合：計画に pending approval と記載したままにし、state_write(mode="ralplan", active=false, current_phase="pending_approval", session_id=<current_session_id>) を呼び出してから、蓄積された計画コンテキストを圧縮するために Skill("compact") を呼び出します。compact の後、ralph/team を起動する前に、新たに明示的な実行承認を得る必要があります。compact からの続行で実装を自動開始してはいけません。
• 重要 — consensus モードの状態ライフサイクル： 停止または実行に引き継ぐ前に、必ず ralplan 状態を無効化します。実行への引き継ぎ（承認 → ralph/team）には state_write(active=false) を使用し、最終終了（却下、エラー）には state_clear を使用します。実行モードを起動する前に state_clear を使用してはいけません。停止フックによる適用が 30 秒間無効になるためです。 </Tool_Usage>

適応型インタビュー（質問する前に情報を収集）： ``` Planner: [spawns explore agent: "find authentication implementation"] Planner: [receives: "Auth is in src/auth/ using JWT with passport.js"] Planner: "I see you're using JWT authentication with passport.js in src/auth/. For this new feature, should we extend the existing auth or add a separate auth flow?" ``` 良い理由：まずコードベースに関する質問の答えを自ら調べ、そのうえで十分な情報に基づく希望確認の質問をしています。 一度に質問は1つ： ``` Q1: "What's the main goal?" A1: "Improve performance" Q2: "For performance, what matters more -- latency or throughput?" A2: "Latency" Q3: "For latency, are we optimizing for p50 or p99?" ``` 良い理由：それぞれの質問が前の回答を踏まえています。焦点が絞られており、段階的に進みます。 調べればわかることを質問する： ``` Planner: "Where is authentication implemented in your codebase?" User: "Uh, somewhere in src/auth I think?" ``` 悪い理由：プランナーはユーザーに尋ねるのではなく、調査エージェントを起動して調べるべきです。 複数の質問をまとめてする： ``` "What's the scope? And the timeline? And who's the audience?" ``` 悪い理由：一度に3つの質問をすると、回答が浅くなります。一度に1つずつ質問してください。 すべての設計案を一度に提示する： ``` "Here are 4 approaches: Option A... Option B... Option C... Option D... Which do you prefer?" ``` 悪い理由：意思決定疲れにつながります。まずトレードオフを添えて1つの案を提示し、反応を得てから次の案を提示してください。

<Escalation_And_Stop_Conditions>

• 要件が計画を立てられる程度に明確になったら、インタビューを終了してください。質問しすぎないでください。
• コンセンサスモードでは、Planner／Architect／Criticの反復を5回行ったら終了し、最善の案を提示してください。この段階ではralplanの状態をクリアしないでください。後続のステップでユーザーが「変更を依頼」を選択する可能性があります。状態をクリアするのは、ユーザーの最終選択（承認／却下）時、または非対話モードで計画を出力するときだけです。
• --interactiveを付けないコンセンサスモードでは、最終計画にpending approvalのマークを付けて出力し、終了します。--interactiveを付ける場合は、実装を開始する前にユーザーの明示的な承認が必要です。必ず終了前にstate_clear(mode="ralplan", session_id=<current_session_id>)を呼び出してください。
• ユーザーが実行経路を明示せずに「そのまま実行して」または「計画を省略して」と言った場合は、計画を終了する要求として扱ってください。現在の計画／仕様／提案をpending approvalとして出力し、構造化された承認UIを通じて明示的な実行承認を求めてください。その承認が得られるまでは、計画モジュールからSkill("oh-my-claudecode:ralph")を呼び出したり、ファイルを変更したり、実装を委任したり、コミット、プッシュ、PRの作成を行ったりしないでください。
• ビジネス上の判断が必要な、解決不能なトレードオフがある場合は、ユーザーにエスカレーションしてください。 </Escalation_And_Stop_Conditions>

<Final_Checklist>

• 計画にテスト可能な受け入れ基準がある（90％以上が具体的）
• 該当する場合、計画が具体的なファイル／行を参照している（主張の80％以上）
• すべてのリスクに対策が特定されている
• 指標のない曖昧な用語がない（「高速」→「p99 < 200ms」）
• 計画が.omc/plans/に保存されている
• コンセンサスモードの場合：RALPLAN-DRの要約に3～5個の原則、上位3つの推進要因、実行可能な選択肢が2つ以上（または明示的な無効化の根拠）が含まれている
• コンセンサスモードの最終出力の場合：ADRセクション（Decision／Drivers／Alternatives considered／Why chosen／Consequences／Follow-ups）が含まれている
• 熟慮型コンセンサスモードの場合：事前検討（3つのシナリオ）と拡張テスト計画（ユニット／統合／E2E／可観測性）が含まれている
• --interactive付きのコンセンサスモードの場合、実行前にユーザーが明示的に承認している。--interactiveなしの場合は、計画の出力にpending approvalのマークを付けるだけで、自動実行しない
• コンセンサスモードの場合：すべての終了経路でralplanの状態が無効化されている。実行への引き継ぎ時はstate_write(active=false)、終了時（却下、エラー、非対話モードでの終了）はstate_clearを使用する </Final_Checklist>

## 設計案の提示

インタビュー中に設計案を提示する際は、分けて提示してください。

1. 概要（2～3文）
2. 案Aとそのトレードオフ
3. [ユーザーの反応を待つ]
4. 案Bとそのトレードオフ
5. [ユーザーの反応を待つ]
6. 推奨案（選択肢を検討した後に限る）

各案の形式：

### Option A: [Name]
**Approach:** [1 sentence]
**Pros:** [bullets]
**Cons:** [bullets]

What's your reaction to this approach?

## 質問の分類

面接の質問をする前に、分類してください。

種類	例	対応
コードベースの事実	「どのようなパターンがありますか？」「X はどこにありますか？」	まず調査し、ユーザーには尋ねない
ユーザーの好み	「優先順位は？」「期限は？」	AskUserQuestion でユーザーに尋ねる
スコープの決定	「機能 Y を含めますか？」	ユーザーに尋ねる
要件	「パフォーマンスの制約はありますか？」	ユーザーに尋ねる

レビュー品質基準

基準	標準
明確さ	80% 以上の主張にファイル／行番号の引用がある
テスト可能性	90% 以上の基準が具体的である
検証	すべてのファイル参照が存在する
具体性	曖昧な表現がない

非推奨に関するお知らせ

個別の /planner、/ralplan、/review スキルは /plan に統合されました。面接、直接実行、コンセンサス、レビューのすべてのワークフローを /plan から利用できます。