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 の破壊的変更）を示している場合は、熟考モードに切り替えてください </Execution_Policy>

モードの選択

モード	トリガー	動作
インタビュー	幅広い依頼に対するデフォルト	対話形式で要件を聞き取ります
直接	--direct、または詳細な依頼	インタビューを省略し、直接計画を作成します
コンセンサス	--consensus、「ralplan」	RALPLAN-DR による構造化された検討を用い、合意に達するまで Planner -> Architect -> Critic のループを実行します（デフォルトはショートモード。高リスクの場合は --deliberate）。ドラフトと承認の段階でユーザーに確認するには、--interactive を追加してください
レビュー	--review、「この計画をレビューして」	Critic が既存の計画を評価します

インタビューモード（幅広い依頼／曖昧な依頼）

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

直接モード（詳細な依頼）

1. 簡易分析：必要に応じて Analyst に簡単に相談します
2. 計画の作成：包括的な作業計画をすぐに生成します
3. レビュー（任意）：依頼があれば Critic がレビューします

コンセンサスモード（--consensus／「ralplan」）

RALPLAN-DR モード：Short（デフォルト、構造を限定）と Deliberate（--deliberate または明示的な高リスクのリクエスト向け）です。どちらのモードも、同じ Planner -> Architect -> Critic の順序と、同じ AskUserQuestion のゲートを維持します。

1. Plannerは、Architectによるレビューの前に、初期計画と簡潔なRALPLAN-DRサマリーを作成します。このサマリーには、必ず以下を含めます。
   • 原則（3～5項目）
   • 判断基準（上位3項目）
   • 実行可能な選択肢（2つ以上）。各選択肢について、範囲を限定した長所と短所を示します
   • 実行可能な選択肢が1つだけの場合は、却下した代替案について、却下の根拠を明示します
   • 慎重モードでは、事前検証（失敗シナリオを3つ）と、単体テスト／統合テスト／E2Eテスト／可観測性を網羅する拡張テスト計画
2. ユーザーフィードバック（--interactiveの場合のみ）：--interactiveで実行する場合、必ずAskUserQuestionを使用し、初期の方向性をすり合わせるために、ドラフト計画とRALPLAN-DRの「原則／判断基準／選択肢」のサマリーを併せて提示し、次の選択肢を示します。
   • レビューに進む — ArchitectとCriticに評価を依頼します
   • 変更を依頼する — ユーザーフィードバックを反映して手順1に戻ります
   • レビューをスキップする — 最終承認（手順7）に直接進みます --interactiveで実行しない場合は、自動的にレビュー（手順3）に進みます。
3. Architectは、Task(subagent_type="oh-my-claudecode:architect", ...)を使用し、アーキテクチャの妥当性をレビューします。Architectのレビューには、支持されている選択肢に対する最も強力なスティールマン形式の反論（反対説）、少なくとも1つの重要なトレードオフの緊張関係、そして可能な場合は統合案を必ず含めます。慎重モードでは、原則への違反を明示的に指摘します。手順4に進む前に、この手順が完了するのを待ちます。手順3と4を並行して実行してはいけません。
4. Criticは、Task(subagent_type="oh-my-claudecode:critic", ...)を使用し、品質基準に照らして評価します。Criticは、原則と選択肢の一貫性、代替案の公平な検討、リスク軽減策の明確さ、テスト可能な受け入れ基準、具体的な検証手順を必ず確認します。浅薄な代替案、判断基準との矛盾、曖昧なリスク、または不十分な検証は、必ず明示的に却下します。手順3の完了後にのみ実行します。
5. 再レビューのループ（最大5回）：Criticが却下した場合、次の閉ループを実行します。 a. ArchitectとCriticからの却下フィードバックをすべて収集します b. フィードバックをPlannerに渡し、計画を改訂します c. 手順3に戻り、Architectが改訂版の計画をレビューします d. 手順4に戻り、Criticが改訂版の計画を評価します e. Criticが承認するか、最大5回に達するまで繰り返します f. 承認されないまま最大回数に達した場合は、専門家間で合意に至らなかった旨を添えて、AskUserQuestionで最善の案をユーザーに提示します
6. 改善の適用：レビュアーが改善案を提示したうえで承認した場合、先に、採用するすべての改善案を計画ファイルに反映します。最終的な合意内容には、ADRセクションとして、決定事項、判断基準、検討した代替案、選定理由、結果、フォローアップを必ず含めます。 a. ArchitectとCriticの回答から、すべての改善案を収集します b. 改善案の重複を取り除き、分類します c. .omc/plans/内の計画ファイルを、採用した改善案に合わせて更新します（不足している詳細の追加、手順の見直し、受け入れ基準の強化、ADRの更新など） d. 計画の末尾に簡潔な変更履歴セクションを設け、適用した改善案を記録します
7. Criticが承認した場合（改善の適用後）：（--interactiveの場合のみ）--interactiveで実行する場合は、AskUserQuestionを使用して計画を提示し、次の選択肢を示します。
   • 承認して実行する — ralph+ultraworkで実装に進みます
   • 承認してチームで実装する — 連携する並列チームエージェントで実装に進みます
   • コンテキストをクリアして実装する — まずコンテキストウィンドウを圧縮し（計画後にコンテキストが大きくなっている場合に推奨）、保存済みの計画ファイルを使って、新たにralphで実装を開始します
   • 変更を依頼する — ユーザーフィードバックを添えて手順1に戻ります
   • 却下する — 計画を完全に破棄します --interactiveで実行しない場合は、承認済みの最終計画を出力して終了します。自動的に実行してはいけません。
8. （--interactiveの場合のみ）ユーザーは構造化されたAskUserQuestion UIで選択します（承認をプレーンテキストで尋ねてはいけません）。
9. ユーザーの承認後（--interactiveの場合のみ）：
   • 承認して実行する：承認済みの計画パス（.omc/plans/内）をコンテキストとして、必ずSkill("oh-my-claudecode:ralph")を呼び出します。直接実装してはいけません。計画エージェントでソースコードファイルを編集してはいけません。ralphスキルがultraworkの並列エージェントを使って実行を処理します。
   • 承認してチームで実装する：承認済みの計画パス（.omc/plans/内）をコンテキストとして、必ずSkill("oh-my-claudecode:team")を呼び出します。直接実装してはいけません。teamスキルが、段階的なパイプライン全体で並列エージェントを調整し、大規模なタスクをより迅速に実行します。
   • コンテキストをクリアして実装する：まずSkill("compact")を呼び出してコンテキストウィンドウを圧縮し（計画中に蓄積したトークン使用量を削減します）、次に.omc/plans/内の承認済み計画パスを指定してSkill("oh-my-claudecode:ralph")を呼び出します。計画セッション後にコンテキストウィンドウの使用量が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", ...)を使用します
• 要件分析には、Task(subagent_type="oh-my-claudecode:analyst", ...)を使用します
• consensusモードとreviewモードでの計画レビューには、Task(subagent_type="oh-my-claudecode:critic", ...)を使用します
• 重要 — consensusモードでのエージェント呼び出しは必ず順次実行し、並列で実行してはいけません。 CriticのTaskを呼び出す前に、必ずArchitectのTaskの結果を待ちます。
• consensusモードでは、デフォルトでRALPLAN-DRのショートモードを使用します。--deliberateが指定された場合、または明示的な高リスクの兆候（認証／セキュリティ、移行、破壊的変更、本番環境のインシデント、コンプライアンス／PII、公開APIの破壊的変更）がある場合は、deliberateモードを有効にします
• --interactiveを指定したconsensusモードでは、ユーザーからのフィードバックを得る手順（ステップ2）と最終承認の手順（ステップ7）にAskUserQuestionを使用します。プレーンテキストで承認を求めてはいけません。--interactiveを指定しない場合は、両方のプロンプトを省略し、最終的な計画を出力します。
• --interactiveを指定したconsensusモードでは、ユーザーが承認したら、実行のために（ステップ9）必ずSkill("oh-my-claudecode:ralph")を呼び出します。計画エージェントが直接実装してはいけません
• ステップ7（--interactiveのみ）でユーザーが「コンテキストをクリアして実装」を選択した場合は、まず蓄積した計画コンテキストを圧縮するためにSkill("compact")を呼び出し、続けてすぐに計画パスを指定してSkill("oh-my-claudecode:ralph")を呼び出します。実装ループを開始する前にコンテキストを解放するため、このcompactの手順は重要です </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?" ``` 悪い理由：プランナーはユーザーに尋ねるのではなく、exploreエージェントを起動して調べるべきです。 複数の質問をまとめて尋ねる： ``` "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つの選択肢とそのトレードオフを提示して反応を得てから、次の選択肢を提示してください。 - 計画を立てられる程度に要件が明確になったら、インタビューを停止する。過度にインタビューしないこと - コンセンサスモードでは、Planner/Architect/Critic の反復を 5 回行った後に停止し、最良のバージョンを提示する - `--interactive` なしのコンセンサスモードでは、最終計画を出力して停止する。`--interactive` ありの場合は、実装を開始する前にユーザーの明示的な承認が必要 - ユーザーが「just do it」や「skip planning」と言った場合は、**必ず** `Skill("oh-my-claudecode:ralph")` を呼び出して実行モードに移行すること。計画エージェント内で直接実装しないこと - 業務上の判断を要する、調整不可能なトレードオフがある場合は、ユーザーにエスカレーションする

<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 つのシナリオ）と拡張テスト計画（unit/integration/e2e/observability）が含まれている
• --interactive 付きのコンセンサスモードでは、実行前にユーザーが明示的に承認している。--interactive なしの場合は計画の出力のみで、自動実行は行わない </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 からご利用いただけます。