omc-plan

<目的> Planは、インテリジェントな対話を通じて、包括的で実行可能な作業計画を作成します。リクエストが曖昧な場合はユーザーへのインタビューを自動的に行い（ブロードリクエスト）、詳細なリクエストの場合は直接計画を生成します。さらに、コンセンサスモード（Planner/Architect/Criticの反復ループとRALPLAN-DR構造化審議）およびレビューモード（既存計画のCritic評価）をサポートします。 </目的>

<使用時>

• ユーザーが実装前に計画を立てたい場合 -- 「これを計画して」「計画を」「計画しよう」
• ユーザーが漠然としたアイデアに対して構造化された要件収集を希望する場合
• ユーザーが既存の計画のレビューを希望する場合 -- 「この計画をレビューして」、--review
• ユーザーが計画に対して複数視点からのコンセンサスを希望する場合 -- --consensus、「ralplan」
• タスクが広範囲または曖昧で、コードを書く前にスコープ定義が必要な場合 </使用時>

<使用不可時>

• ユーザーが自律的なエンドツーエンドの実行を希望する場合 -- 代わりにautopilotを使用
• ユーザーが明確なタスクですぐにコーディングを開始したい場合 -- 代わりにralphを使用するか、エグゼキュータに委任
• ユーザーが直接回答できる単純な質問をした場合 -- そのまま回答
• タスクが明確なスコープを持つ単一の修正に集中している場合 -- この計画モジュールから実行する代わりに、実行スキルを使用 </使用不可時>

<存在理由> 要件を理解せずにコードに飛び込むと、手戻り、スコープクリープ、エッジケースの見落としが発生します。Planは、構造化された要件収集、専門家による分析、品質ゲートを経た計画を提供することで、強固な基盤の上で実行を開始できるようにします。コンセンサスモードは、ハイステークスなプロジェクトに対して複数視点からの検証を追加します。 </存在理由>

<実行ポリシー>

• リクエストの具体性に基づいて、インタビューモードと直接モードを自動検出
• インタビュー中は一度に1つの質問のみ行う -- 複数の質問をまとめて行わない
• ユーザーに質問する前に、exploreエージェントを使用してコードベースの事実を収集
• 計画は品質基準を満たす必要あり：主張の80%以上がファイル/行を引用、基準の90%以上がテスト可能
• コンセンサスモードはデフォルトで完全自動実行。ドラフトレビューと最終承認ステップでユーザープロンプトを有効にするには--interactiveを追加
• コンセンサスモードはデフォルトでRALPLAN-DRショートモードを使用。--deliberateを使用するか、リクエストが高リスクを明示的に示す場合（認証/セキュリティ、データ移行、破壊的/不可逆的な変更、本番インシデント、コンプライアンス/PII、公開APIの破損）には、デリバレートモードに切り替え
• 計画/実行の境界: 計画モードはコンテキストを検査し、計画/仕様/提案を生成するのみ。ユーザーが現在のターンで明示的に実行をオプトインしているか、構造化された承認UIを介している場合を除き、成果物をpending approvalとしてマークする必要があります。明示的な実行承認前は、計画モードはミューテーション指向のシェルコマンドの実行、ソースファイルの編集、コミット、プッシュ、PRの作成、実行スキルの呼び出し、実装タスクの委任をしてはなりません。
• Goalワークフローの境界: 計画がClaude Code /goal、Ralph、Team、またはアーティファクトのみのUltragoalを比較する場合、正確に1つのプライマリループ権限を特定し、非決定的な警告処理ではなく、refuse、adopt_existing、artifact_onlyの決定論的競合ポリシーを使用します。/goalの事実はClaude Code/Anthropicのソースのみを引用し（Claude Code /goal docs: https://code.claude.com/docs/en/goal; Anthropic Claude Code changelog: 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に合わせてください。 </実行ポリシー>

<ステップ>

モード選択

モード	トリガー	動作
インタビュー	ブロードリクエストのデフォルト	インタラクティブな要件収集
直接	--direct、または詳細なリクエスト	インタビューをスキップし、直接計画を生成
コンセンサス	--consensus、「ralplan」	Planner -> Architect -> Criticループを合意に達するまで繰り返し、RALPLAN-DR構造化審議（デフォルトはショート、高リスク時は--deliberate）を実施。ドラフトおよび承認ステップでユーザープロンプトを有効にするには--interactiveを追加
レビュー	--review、「この計画をレビューして」	既存計画のCritic評価

インタビューモード（ブロード/曖昧なリクエスト）

1. リクエストを分類: ブロード（曖昧な動詞、特定のファイルなし、3つ以上の領域に影響）はインタビューモードをトリガー
2. 1つの焦点を絞った質問をする: AskUserQuestionを使用して、好み、スコープ、制約を確認
3. 最初にコードベースの事実を収集: 「あなたのコードはどのようなパターンを使っていますか？」と尋ねる前に、exploreエージェントを起動して調査し、その上で情報に基づいたフォローアップ質問を行う
4. 回答に基づいて構築: 各質問は前の回答に基づく
5. アナリスト（Opus）に相談: 隠れた要件、エッジケース、リスクを特定
6. 計画を作成: ユーザーが準備完了の合図をしたら（「計画を作成して」「準備ができました」「作業計画にしてください」）

直接モード（詳細なリクエスト）

1. クイック分析: オプションで簡単なアナリスト相談
2. 計画を作成: すぐに包括的な作業計画を生成
3. レビュー（オプション）: リクエストがあればCriticレビューを実施

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

RALPLAN-DRモード: ショート（デフォルト、境界のある構造）およびデリバレート（--deliberateまたは明示的な高リスクリクエスト用）。どちらのモードも同じPlanner -> Architect -> Criticシーケンスと同じAskUserQuestionゲートを維持します。

プロバイダーオーバーライド（プロバイダーCLIがインストールされている場合にサポート）:

• --architect codex — Claude Architectパスをomc ask codex --agent-prompt architect "..."で置き換え、実装重視のアーキテクチャレビューを実行
• --critic codex — Claude Criticパスをomc ask codex --agent-prompt critic "..."で置き換え、実行前の外部レビューパスを実行
• 要求されたプロバイダーが利用できない場合は、簡単にその旨を伝え、そのステージのデフォルトのClaude Architect/Criticステップで続行

状態ライフサイクル: 永続モードのストップフックは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. Plannerが最初の計画とコンパクトなRALPLAN-DRサマリーを作成（Architectレビューの前）。サマリーには必須で以下を含める:

   • 原則（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つの意味のあるトレードオフの緊張、そして（可能な場合）統合パス。デリバレートモードでは、Architectは原則違反を明示的にフラグ付けする。このステップが完了するのを待ってからステップ4に進む。 ステップ3と4を並列に実行しない。Architectは、ステップ1でPlannerが生成した同じ固定計画スナップショットを、変更せずに評価する必要があります。Architectの出力はCriticに渡してはなりません。

4. CriticがTask(subagent_type="oh-my-claudecode:critic", ...)を使用して品質基準に照らして評価。Criticは必須で以下を検証する: 原則とオプションの一貫性、代替案の公正な探索、リスク軽減の明確さ、テスト可能な受入基準、具体的な検証ステップ。Criticは必須で、浅い代替案、ドライバーの矛盾、曖昧なリスク、弱い検証を明示的に却下する。デリバレートモードでは、Criticは必須で、プレモーテムの欠落/弱さ、または拡張テスト計画の欠落/弱さを却下する。ステップ3が完了してからのみ実行する。Criticは同じ固定計画スナップショットを独立して評価する必要があり、独立した個別に待機されるTask呼び出しとして行います。CriticはArchitectのレビューを消費したり受け取ったりしてはなりません。

   1つの固定計画スナップショットに対する独立した逐次レビュー。 ArchitectとCriticはそれぞれ、ステップ1でPlannerが生成した同じ固定計画スナップショットをレビューし、どちらのレビューもそれを変更しません。Architectの出力はCriticに渡してはなりません。ArchitectとCriticは、独立した個別に待機されるTask呼び出しとして順次実行する必要があります（決して並列ではありません）。Critic Taskは、Architect 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. 改善を適用: レビューアーが改善提案とともに承認した場合、先に進む前に、すべての受け入れられた改善を計画ファイルにマージ。最終的なコンセンサス出力には必須で以下を含むADRセクションを含める: 決定、ドライバー、検討された代替案、選択理由、結果、フォローアップ。具体的には: a. ArchitectとCriticの応答からすべての改善提案を収集 b. 提案を重複排除し、カテゴリ化 c. .omc/plans/内の計画ファイルを、受け入れられた改善で更新（不足している詳細を追加、ステップを洗練、受入基準を強化、ADRを更新など） d. どの改善が適用されたかを、計画の最後に簡単な変更ログセクションで記載

7. Critic承認時（改善が適用された場合）: 明示的な実行承認がすでに取得されていない限り、計画ステータスをpending approvalとしてマーク。(--interactiveの場合のみ) --interactiveで実行している場合、AskUserQuestionを使用して計画を提示し、以下のオプションを提供:

   • チームによる実行を承認（推奨） — 調整された並列チームエージェント（/team）を介して進めるための明示的なオプトイン。Teamはv4.1.7以降の標準的なオーケストレーションサーフェスです。
   • ralphによる実行を承認 — 検証付きRalph永続化を介して進めるための明示的なオプトイン
   • コンパクト化して実行承認のために戻る — 最初にコンテキストウィンドウをコンパクト化し（計画後のコンテキストが大きい場合に推奨）、保存されたpending-approval計画で停止し、実行を開始する前に再度尋ねるための明示的なオプトイン
   • 変更をリクエスト — ユーザーフィードバックを組み込んでステップ1に戻る
   • 拒否 — 計画を完全に破棄 --interactiveで実行していない場合、最終計画をpending approvalとして出力し、state_clear(mode="ralplan", session_id=<current_session_id>)を呼び出して停止。自動実行はしない。

8. (--interactiveの場合のみ) ユーザーは構造化されたAskUserQuestionUIを介して選択（プレーンテキストで承認を求めないでください）。ユーザーが拒否を選択した場合、state_clear(mode="ralplan", session_id=<current_session_id>)を呼び出して停止。

9. ユーザーが…

[翻訳のため省略]