deepen-plan

計画の掘り下げ

はじめに

注：現在は2026年です。 最近のドキュメントやベストプラクティスを検索する際は、この点を考慮してください。

ce:plan は最初の計画を立てます。deepen-plan は、2回目の信頼性チェックです。

計画がすでに存在し、問うべきことが「このドキュメントは明確か？」ではなく、「この計画は、関わる複雑さとリスクに見合うだけの根拠があるか？」である場合に、このスキルを使用してください。

このスキルは、計画を実装スクリプトに変えるものではありません。弱いセクションを特定し、そのセクションに限って的を絞った調査を行い、計画をその場で強化します。

document-review と deepen-plan は異なります。

• ドキュメントの明確さ、簡潔さ、完全性、スコープの管理が必要な場合は、document-review スキルを使用してください
• ドキュメントの構成はしっかりしているものの、根拠、順序付け、リスクへの対応、またはシステム全体を考慮した視点をさらに強化する必要がある場合は、deepen-plan を使用してください

対話方法

利用可能な場合は、プラットフォームの質問ツールを使用してください。ユーザーに質問する際は、プラットフォームにブロッキング質問ツールがあれば、そちらを優先してください（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）。それ以外の場合は、チャットで番号付きの選択肢を提示し、ユーザーの返答を待ってから続行してください。

質問は一度に1つずつ行ってください。自然な選択肢がある場合は、簡潔な単一選択形式を優先してください。

計画ファイル

<plan_path> #$ARGUMENTS </plan_path>

上記の計画パスが空の場合：

1. docs/plans/ で最近のファイルを確認してください
2. 可能であれば、プラットフォームのブロッキング質問ツールを使って、どの計画を掘り下げるかユーザーに尋ねてください（「対話方法」を参照）。それ以外の場合は、チャットで番号付きの選択肢を提示し、ユーザーの返答を待ってから続行してください

有効な計画ファイルのパスが得られるまで、先に進まないでください。

基本原則

1. 水増しせず、厳しく検証する - 掘り下げによって、正当な確信を高めてください。理由もなく計画を長くしてはいけません。
2. 必要な箇所だけ深く掘り下げる - すべてを充実させるのではなく、最も弱い2～5つのセクションに焦点を当ててください。
3. 最もシンプルな実行方法を優先する - デフォルトではエージェントによる直接的な統合を使用してください。調査範囲が十分に広く、すべての調査結果をインラインで返すと不要なコンテキスト負荷が生じる場合に限り、成果物に基づく調査に切り替えてください。
4. 計画の境界を守る - 実装コード、Git コマンドの手順、具体的なテストコマンドの手順を含めないでください。
5. 成果物に含まれる根拠を使用する - 記述された計画、その Context & Research、Sources & References、および存在する場合は元のドキュメントに基づいて作業してください。
6. プロダクトの境界を尊重する - 新しいプロダクト要件を作り出さないでください。掘り下げによってプロダクトレベルの不足が見つかった場合は、未解決の質問として提示するか、ce:brainstorm に差し戻してください。
7. リスクと横断的な影響を優先する - 作業が危険、または他の要素との相互依存が強いほど、計画をもう一度見直す価値が高まります。

ワークフロー

フェーズ0：計画を読み込み、掘り下げる必要があるか判断する

0.1 計画と補足資料を読む

計画ファイルを最後まで読んでください。

計画のフロントマターに origin: パスが含まれている場合：

• 元のドキュメントも読んでください
• それを使って、計画がプロダクトの意図、スコープの境界、成功基準を今も反映しているか確認してください

0.2 計画の深さとトピックのリスクを分類する

ドキュメントから計画の深さを判断してください。

• 軽量 - 小規模で範囲が限定され、曖昧さが少なく、通常は実装単位が2～4個
• 標準 - 複雑さは中程度で、技術的な判断がいくつか必要となり、通常は実装単位が3～6個
• 詳細 - 複数領域にまたがる、高リスク、または戦略的に重要な作業で、通常は実装単位が4～8個、または段階的なデリバリーを伴う

また、リスクのプロファイルも作成してください。次の要素は高リスクの兆候として扱います。

• 認証、認可、またはセキュリティに関わる動作
• 支払い、請求、または金融関連のフロー
• データ移行、バックフィル、または永続データの変更
• 外部 API またはサードパーティとの連携
• プライバシー、コンプライアンス、またはユーザーデータの取り扱い
• インターフェース間の一貫性、または複数の画面・環境にまたがる動作
• 大規模なロールアウト、モニタリング、または運用上の懸念

0.3 深掘りすべきかどうかを判断する

次のデフォルトを使用します。

• 軽量な計画は、高リスクであるか、ユーザーが明示的に要求しない限り、通常は深掘りの必要はありません
• 標準的な計画は、1つ以上の重要なセクションがまだ薄いままである場合に、しばしば恩恵を受けます
• 詳細または高リスクの計画は、的を絞った2回目のパスからしばしば恩恵を受けます

計画がすでに十分に根拠づけられていると思われる場合:

• その旨を簡潔に伝えます
• /ce:work または document-review スキルへ進むことを推奨します
• それでもユーザーが明示的に深掘りを求めた場合は、軽いパスを続行し、最大1～2セクションまで深掘りします

フェーズ1: 現在の ce:plan 構造を解析する

計画を現在のテンプレートにマッピングします。次のセクション、またはそれに最も近い同等のものを探します:

• Overview
• Problem Frame
• Requirements Trace
• Scope Boundaries
• Context & Research
• Key Technical Decisions
• Open Questions
• High-Level Technical Design（任意の概要 — 疑似コード、DSL文法、mermaid図、またはデータフロー）
• Implementation Units（ユニットごとの Technical design サブセクションを含む場合があります）
• System-Wide Impact
• Risks & Dependencies
• Documentation / Operational Notes
• Sources & References
• Alternative Approaches Considered、Success Metrics、Phased Delivery、Risk Analysis & Mitigation、Operational / Rollout Notes などの任意の詳細計画セクション

計画が手動で書かれている場合、または異なる見出しを使用している場合:

• 正確な見出し名ではなく意図によってセクションをマッピングします
• セクションが構造的に存在していてもタイトルが異なる場合は、同等のセクションとして扱います
• 計画に本当にセクションが欠けている場合は、その欠如が計画の深さにとって意図的なものか、スコアリングに値する信頼度のギャップかどうかを判断します

また、次のものも収集します:

• フロントマター（既存の deepened: 日付が存在する場合はそれも含む）
• 実装ユニットの数
• どのファイルとテストファイルが名前付けされているか
• どの学び、パターン、または外部参照が引用されているか
• どのセクションが不要なために省略されたように見えるか、対して欠落しているために省略されたように見えるか

フェーズ2: 信頼度ギャップをスコアリングする

チェックリストを優先し、リスクで重み付けしたスコアリングパスを使用します。

各セクションについて、次を計算します:

• トリガー数 - 該当するチェックリストの問題の数
• リスクボーナス - トピックが高リスクであり、このセクションがそのリスクに実質的に関連する場合は1を加算します
• 重要セクションスコア - 標準 または 詳細 の計画において、Key Technical Decisions、Implementation Units、System-Wide Impact、Risks & Dependencies、または Open Questions に対して1を加算します

次の場合、そのセクションを候補として扱います:

• 合計2ポイント以上に達した場合、または
• 高リスク領域で1ポイント以上に達し、かつそのセクションが実質的に重要である場合

スコア順に上位2～5セクションのみを選びます。ユーザーが軽量な計画の深掘りを明示的に求めた場合は、トピックが高リスクでない限り、1～2セクションを上限とします。

例:

• チェックリストのトリガーが1つあり、重要セクションスコアが付いた Key Technical Decisions セクションは2ポイントとなり、候補になります
• 高リスクの移行計画における Risks & Dependencies セクションも、リスクボーナスが適用されるため候補になります

計画にすでに deepened: 日付がある場合:

• スコアが同程度であれば、まだ大幅に強化されていないセクションを優先します
• すでに深掘りされたセクションは、それが他の選択肢よりも明らかに高いスコアである場合、またはユーザーが明示的に再度のパスを求めた場合にのみ再検討します

2.1 セクション別チェックリスト

以下のトリガーを使用してください。

要件のトレーサビリティ

• 要件が曖昧である、または実装単位と結び付いていない
• 成功基準が欠けている、または後続の作業に反映されていない
• 各単位が、トレースされた要件の達成にどのように寄与するのか明確でない
• 起点となる要件が、後続の作業に明確に引き継がれていない

コンテキストと調査／情報源と参照資料

• 関連するリポジトリのパターンが挙げられているものの、判断や実装単位で使われていない
• 引用された知見や参照資料が、計画に実質的な影響を与えていない
• リスクの高い作業に、適切な外部または内部の根拠がない
• 調査が一般的で、このリポジトリや計画に結び付いていない

主要な技術的決定

• 決定は示されているが、その根拠がない
• 根拠でトレードオフや却下した代替案が説明されていない
• 決定がスコープ、要件、起点となるコンテキストに結び付いていない
• 明らかな設計上の分岐があるのに、計画で選択理由が説明されていない

未解決の質問

• プロダクト上のブロッカーが前提条件として隠されている
• 計画段階で解決すべき質問が、誤って実装段階に先送りされている
• 解決済みの質問について、リポジトリのコンテキスト、調査、起点となる決定に基づく明確な根拠がない
• 先送りされた項目が曖昧すぎて、後で役立たない

高レベルの技術設計（記載されている場合）

• 作業に適さない形式が使われている（例：シーケンス図のほうが伝わりやすいのに、擬似コードが使われている）
• 擬似コードではなく、実装コード（インポート、正確なシグネチャ、フレームワーク固有の構文）が含まれている
• 規範的でない説明がない、または弱い
• 主要な技術的決定や実装単位に結び付いていない

高レベルの技術設計（記載されていない場合） (Standard または Deep プランのみ)

• 作業に DSL 設計、API サーフェス設計、複数コンポーネントの統合、複雑なデータフロー、または状態を多く扱うライフサイクルが含まれている
• 視覚的な表現や擬似コードがあれば、主要な技術的決定を検証しやすくなる
• 実装単位のアプローチの説明が簡素であり、より高レベルの技術設計があればコンテキストを補える

実装単位

• 依存関係の順序が不明確、または誤っている可能性が高い
• 明示すべきファイルパスやテストファイルのパスが記載されていない
• 単位が大きすぎる、曖昧すぎる、または細かい手順に分割されすぎている
• アプローチの説明が簡素、または準拠すべきパターンが示されていない
• テストシナリオや検証結果が曖昧である

システム全体への影響

• 影響を受けるインターフェース、コールバック、ミドルウェア、エントリーポイント、または同等性を保つべき箇所が抜けている
• 失敗の伝播についての検討が不十分である
• 該当する場合に、状態のライフサイクル、キャッシュ、またはデータ整合性のリスクが考慮されていない
• 複数レイヤーにまたがる作業の統合テストが不十分である

リスクと依存関係／ドキュメント／運用上の注意事項

• リスクが軽減策なしで列挙されている
• 必要な場合に、ロールアウト、監視、移行、またはサポートへの影響が記載されていない
• 外部依存関係に関する前提が不十分、または記載されていない
• 明らかに該当するセキュリティ、プライバシー、パフォーマンス、またはデータのリスクが考慮されていない

根拠として、プラン内の Context & Research と Sources & References を使用してください。これらのセクションでパターン、知見、またはリスクに触れているのに、それが決定、実装単位、検証のいずれにも影響していない場合は、信頼性に懸念があると判断してください。

フェーズ 3：対象を絞った調査エージェントを選択する

選択した各セクションについて、必要最小限のエージェントを選んでください。すべてのエージェントを実行してはいけません。セクションごとに最大 1～3 エージェント、通常は合計 8 エージェント以下にしてください。

Task 呼び出しでは、完全修飾されたエージェント名を使用してください。

3.1 セクションとエージェントの決定論的なマッピング

要件のトレース／未解決の質問の分類

• ユーザーフローの不足、エッジケース、引き継ぎの漏れには compound-engineering:workflow:spec-flow-analyzer
• リポジトリに根拠を置いたパターン、規約、実装の実態確認には compound-engineering:research:repo-research-analyst（スコープ：architecture, patterns）

コンテキストと調査／ソースと参考資料の不足

• 組織内のナレッジや過去に解決した問題には compound-engineering:research:learnings-researcher
• 公式のフレームワークやライブラリの挙動には compound-engineering:research:framework-docs-researcher
• 最新の外部パターンや業界のガイダンスには compound-engineering:research:best-practices-researcher
• 過去の判断理由や先行事例が実質的に不足している場合に限り、compound-engineering:research:git-history-analyzer を追加します

主要な技術的決定事項

• 設計の整合性、境界、アーキテクチャ上のトレードオフには compound-engineering:review:architecture-strategist
• リポジトリの情報だけでは不十分で、決定に外部の根拠が必要な場合は、compound-engineering:research:framework-docs-researcher または compound-engineering:research:best-practices-researcher を追加します

技術設計の概要

• 技術設計が意図するアプローチを正確に表現しているかの検証と、不足箇所の特定には compound-engineering:review:architecture-strategist
• 既存のリポジトリのパターンや規約に技術設計の根拠を置くには compound-engineering:research:repo-research-analyst（スコープ：architecture, patterns）
• 技術設計に、外部検証が有効な DSL、API サーフェス、パターンが含まれる場合は compound-engineering:research:best-practices-researcher を追加します

実装単位／検証

• 具体的なファイルの対象、従うべきパターン、リポジトリ固有の順序付けに関する手掛かりには compound-engineering:research:repo-research-analyst（スコープ：patterns）
• 一貫性、重複のリスク、既存パターンとの整合性には compound-engineering:review:pattern-recognition-specialist
• 順序付けがユーザーフローや引き継ぎの完全性に依存する場合は compound-engineering:workflow:spec-flow-analyzer を追加します

システム全体への影響

• 境界をまたぐ影響、インターフェイスの範囲、アーキテクチャへの波及的な影響には compound-engineering:review:architecture-strategist
• リスクに合致する専門家を追加します：
  • スケーラビリティ、レイテンシ、スループット、リソースリスクの分析には compound-engineering:review:performance-oracle
  • 認証、検証、悪用の対象領域、セキュリティ境界のレビューには compound-engineering:review:security-sentinel
  • マイグレーション、永続状態の安全性、一貫性、データライフサイクルのリスクには compound-engineering:review:data-integrity-guardian

リスクと依存関係／運用上の注意事項

• 実際のリスクに合致する専門家を使用します：
  • セキュリティ、認証、プライバシー、悪用のリスクには compound-engineering:review:security-sentinel
  • 永続データの安全性、制約、トランザクション境界には compound-engineering:review:data-integrity-guardian
  • マイグレーションの実現可能性、バックフィル、本番データ変換のリスクには compound-engineering:review:data-migration-expert
  • ロールアウトのチェックリスト、ロールバック計画、リリース検証には compound-engineering:review:deployment-verification-agent
  • 容量、レイテンシ、スケーリングに関する懸念には compound-engineering:review:performance-oracle

3.2 エージェントプロンプトの形式

選択した各セクションについて、以下を渡します。

• セクション 3.1 のスコーププレフィックス（例: Scope: architecture, patterns.）。エージェントがスコープ付き呼び出しに対応している場合に使用します。
• 短い計画概要
• セクションの正確な本文
• そのセクションが選択された理由（どのチェックリストのトリガーが発火したかを含む）
• 計画の深さとリスクプロファイル
• 回答すべき具体的な質問

エージェントには以下を返すよう指示します。

• 計画の品質を変える知見
• より強固な根拠、順序付け、検証、リスク対応、または参考文献
• 実装コードは含めない
• シェルコマンドは含めない

3.3 調査の実行モードを選択する

機能する中で最も軽量なモードを使用します。

• 直接モード - デフォルト。選択したセクションの集合が小さく、親がエージェントの出力をインラインで安全に読める場合に使用します。
• アーティファクト利用モード - 選択した調査スコープが大きすぎて、インラインでの返却が不要なコンテキスト圧迫を生む場合にのみ使用します。

アーティファクト利用モードを正当化するシグナル:

• 5 つを超えるエージェントが意味のある知見を返す可能性が高い
• 選択したセクションの抜粋が長く、複数のエージェント出力でそれらを繰り返すと無駄が大きい
• トピックが高リスクであり、出典に裏付けられた膨大な分析を招きやすい
• そのプラットフォームでは、大規模な並列返却時に親コンテキストが不安定になる履歴がある

アーティファクト利用モードが明確に正当化されない場合は、直接モードにとどめます。

フェーズ 4: 対象を絞った調査を実行してレビューする

ステップ 3.3 で選択した実行モードを使用し、選択したエージェントを並列で起動します。現在のプラットフォームが並列ディスパッチに対応していない場合は、代わりに順次実行します。

まずローカルリポジトリと組織内のエビデンスを優先します。外部調査は、リポジトリのコンテキストやすでに引用済みのソースからでは責任をもってギャップを埋められない場合にのみ使用します。

選択したセクションが、原文ドキュメントをより注意深く読むことで改善できる場合は、外部エージェントをディスパッチする前にそれを行います。

4.1 直接モード

選択した各エージェントに、その知見を親へ直接返させます。

返却ペイロードは焦点を絞ったものにします。

• 最も強力な知見のみ
• 重要となるエビデンスまたはソース
• その知見によって示唆される具体的な計画の改善

直接モードのエージェントが膨大または反復的な出力を生成し始めた場合は、親コンテキストを肥大化させるのではなく、いったん停止し、残りの調査をアーティファクト利用モードに切り替えます。

4.2 アーティファクトを使用するモード

.context/compound-engineering/deepen-plan/ 配下に、実行ごとの一時ディレクトリを使用します。例：.context/compound-engineering/deepen-plan/<run-id>/ または .context/compound-engineering/deepen-plan/<plan-filename-stem>/。

一時ディレクトリは、現在のプラン深化パスに限って使用します。

選択した各エージェントに対して：

• ステップ 3.2 で説明したものと同じプランの概要、セクションのテキスト、選定理由、深度、リスクプロファイルを渡します
• 担当するセクションごとに、簡潔なアーティファクトファイルを 1 つ作成するよう指示します
• 親エージェントには、短い完了サマリーのみを返すよう指示します

機械可読な構造が明らかに有用な場合を除き、簡潔な Markdown アーティファクトを優先します。各アーティファクトには、次の内容を含めます：

• 対象セクションの ID とタイトル
• そのセクションを選定した理由
• 計画の品質を実質的に高める 3～7 件の調査結果
• 根拠に基づく理由。根拠がリポジトリのコンテキスト、オリジンのコンテキスト、組織内の知見、公式ドキュメント、外部のベストプラクティスのいずれに由来するかも含めます
• 各調査結果が示唆する具体的なプランの変更
• プラン内で明示したままにすべき未解決のトレードオフ

アーティファクトのルール：

• 実装コードを含めないこと
• シェルコマンドを含めないこと
• チェックポイントのログや自己診断を含めないこと
• ファイル間で定型文を重複させないこと
• 判定やマージのサブパイプラインを設けないこと

統合の前に：

• 選択した各セクションに、少なくとも 1 つの使用可能なアーティファクトがあることを手早く確認します
• アーティファクトが欠落している、または明らかに不適切な形式の場合は、そのエージェントを再実行するか、そのセクションについて直接モードの推論に切り替えます。検証パイプラインは構築しません

エージェントの出力が矛盾する場合：

• 一般的な助言よりも、リポジトリおよびオリジンに根ざした根拠を優先します
• ライブラリの動作に関する矛盾では、二次的なベストプラクティスの要約よりもフレームワークの公式ドキュメントを優先します
• 実際のトレードオフが残る場合は、矛盾がないかのように扱わず、プランに明示的に記録します

フェーズ 5：計画を統合して書き直す

選択したセクションのみを強化します。計画の一貫性を保ち、全体的な構成を維持します。

成果物ベースのモードを使用した場合：

• 計画、存在する場合は元のドキュメント、選択したセクションの成果物を読みます
• 中断前に直接モードのエージェントからインラインで返された調査結果も取り込みます。初期の結果が黙って失われないようにします
• 1 回で統合します
• ユーザーが別のパスを明示的に求めない限り、独立した判定、統合、品質レビューのフェーズは作成しません

許可される変更：

• 判断の根拠を明確化または強化する
• 要件の追跡性または元資料への忠実性を高める
• 順序に問題がある場合、実装単位の順序を入れ替える、または分割する
• 不足しているパターンの参照、ファイル／テストのパス、または検証結果を追加する
• 根拠がある場合、システム全体への影響、リスク、またはロールアウトの扱いを詳しくする
• 根拠に基づいて、未解決の質問を Resolved During Planning と Deferred to Implementation の間で再分類する
• 作業上有益であり、現在の表現が弱い、適切でない媒体を使用している、または有用であるにもかかわらず存在しない場合は、High-Level Technical Design セクションを強化、置換、または追加する。規範的でない表現を維持する
• アプローチが自明でなく、現在のアプローチに関する記述が不足している場合、単位ごとの技術設計フィールドを強化または追加する
• 実行品質を大きく高める場合に限り、任意の詳細計画セクションを追加する
• 計画を実質的に改善した場合、フロントマターに deepened: YYYY-MM-DD を追加または更新する

禁止事項：

• 実装コードを追加しないこと — インポート、正確なメソッドシグネチャ、フレームワーク固有の構文は追加しません。疑似コードのスケッチや DSL 文法は、トップレベルの High-Level Technical Design セクションと単位ごとの技術設計フィールドの両方で使用できます
• git コマンド、コミットの手順、正確なテストコマンドのレシピを追加しないこと
• あらゆる箇所に汎用的な Research Insights サブセクションを追加しないこと
• 計画全体を一から書き直さないこと
• 新たな製品要件、スコープ変更、成功基準を、明示せずに作り出さないこと

調査によって、動作やスコープを変えるべき製品レベルの曖昧さが明らかになった場合：

• ここで黙って判断を下さないこと
• Open Questions に記録すること
• その不足が真に製品を左右するものであれば、ce:brainstorm を推奨すること

フェーズ 6：最終確認とファイルの書き込み

書き込む前に：

• 単に長くなったのではなく、具体的に強化されていることを確認します
• 計画の境界が保たれていることを確認します
• 選択したセクションが実際に最も弱かったことを確認します
• 元のドキュメントが存在する場合、その判断が維持されていることを確認します
• 最終的な計画が、その深さに対して適切な規模であることを確認します
• 成果物ベースのモードを使用した場合、作業用の成果物が第 2 の隠れた計画形式になっていないことを確認します

既定では、計画ファイルをその場で更新します。

ユーザーが別ファイルを明示的に求めた場合は、.md の前に -deepened を付けます。例：

• docs/plans/2026-03-15-001-feat-example-plan-deepened.md

成果物ベースのモードを使用し、ユーザーが作業用ファイルの確認を求めていない場合：

• 計画が安全に書き込まれた後、一時作業ディレクトリをクリーンアップします
• 現在のプラットフォームでクリーンアップが現実的でない場合は、成果物の保存場所と、それが一時的なワークフロー出力であることを伝えます

強化後の選択肢

実質的な変更を加えた場合は、利用可能であればプラットフォームのブロッキング質問ツールを使って次のステップを提示します（「対話方法」を参照）。それ以外の場合は、チャットで番号付きの選択肢を提示し、ユーザーの返信を待ってから続行します。

質問：「[plan_path] の計画を深めました。次は何をしますか？」

選択肢：

1. 差分を表示 - 変更内容を表示します
2. document-review スキルを実行 - 構造化された文書レビューで更新済みの計画を改善します
3. ce:work スキルを開始 - 計画の実装を開始します
4. 特定のセクションをさらに深める - 名前を指定したセクションを対象に、もう一度掘り下げます

選択内容に応じて：

• 差分を表示 -> 重要な追加内容と変更したセクションを表示します
• document-review スキル -> 計画のパスを指定して document-review スキルを読み込みます
• ce:work スキルを開始 -> 計画のパスを指定して ce:work スキルを呼び出します
• 特定のセクションをさらに深める -> まだ弱いと感じるセクションを尋ね、それらのセクションだけを対象にもう一度掘り下げます

実質的な変更が必要なかった場合：

• 計画はすでに十分な根拠に基づいているように見えると伝えます
• 次のステップとして document-review スキルまたは /ce:work を提案します

コードを書いてはいけません！ 計画の調査、検証、強化を行います。