ce:plan-beta

技術計画の作成

注：現在の年は2026年です。 計画の日付を記入するときや、最新のドキュメントを検索するときに使用してください。

ce:brainstorm では構築する内容を定義します。ce:plan では構築する方法を定義します。ce:work では計画を実行します。

このワークフローでは、長期にわたって活用できる実装計画を作成します。コードの実装、テストの実行、実行時の結果からの学習は行いません。答えを得るためにコードを変更して動作を確認する必要がある場合は、ここではなく ce:work の対象です。

対話方法

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

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

機能の説明

<feature_description> #$ARGUMENTS </feature_description>

上記の機能の説明が空の場合、ユーザーに次のように尋ねてください。「何を計画しますか？お考えの機能、バグ修正、または改善について説明してください。」

計画を立てるための明確な入力が得られるまで、先に進まないでください。

基本原則

1. 要件を信頼できる情報源とする - ce:brainstorm で要件ドキュメントが作成されている場合、動作を一から考え直すのではなく、その内容を基に計画を立ててください。
2. コードではなく意思決定を記録する - アプローチ、境界、ファイル、依存関係、リスク、テストシナリオを記録してください。実装コードや、シェルコマンドの手順を先回りして書かないでください。レビュー担当者が方針を検証するのに役立つ場合は、疑似コードの概要や DSL の文法を記載してもかまいません。ただし、方向性を示すガイダンスであり、実装仕様ではないことを明確にしてください。
3. 構成を考える前に調査する - 計画をまとめる前に、必要に応じてコードベース、組織内の知見、外部のガイダンスを調査してください。
4. 成果物の規模を適切にする - 小規模な作業には簡潔な計画を、大規模な作業にはより詳しい構成を用いてください。深さにかかわらず、基本方針は変わりません。
5. 計画と実行時の発見事項を分ける - 計画時に解決できる疑問はここで解決してください。実行時に判明する不確実な点は、実装時に対応するものとして明示的に先送りしてください。
6. 計画のポータビリティを保つ - ツール固有の実行者向け指示を埋め込まず、継続的に更新するドキュメント、レビュー用成果物、課題本文のいずれとしても使える計画にしてください。
7. 必要な場合に限り、実行方針を簡潔に示す - リクエスト、元のドキュメント、またはリポジトリの状況から、テストファースト、特性化ファーストなど、標準とは異なる実行方針が明確に示されている場合は、その方針を計画に簡潔に反映してください。計画を段階的な実行手順にしないでください。

計画の品質基準

すべての計画に次の内容を含めてください。

• 問題の明確な定義とスコープの境界
• リクエストまたは元のドキュメントに基づく、具体的な要件の追跡可能性
• 提案する作業の正確なファイルパス
• 機能を含む実装単位ごとの、明示的なテストファイルパス
• タスクを列挙するだけでなく、根拠を伴う意思決定
• 参考にする既存のパターンやコードへの参照
• 具体的なテストシナリオと検証結果
• 明確な依存関係と作業順序

実装担当者が、コードの書き方を計画に頼らずに自信を持って着手できる状態になれば、計画は完成です。

ワークフロー

フェーズ0：再開、情報源、スコープ

0.1 適切な場合は既存の計画作業を再開する

ユーザーが既存の計画ファイルに言及している場合、または docs/plans/ に最近作成された明らかに関連性の高い計画がある場合：

• その計画を読む
• そのまま更新するか、新しい計画を作成するか確認する
• 更新する場合は、完了済みのチェックボックスを維持し、引き続き関連するセクションのみを改訂する

0.2 上流の要件ドキュメントを探す

計画に関する質問をする前に、docs/brainstorms/ 内で *-requirements.md に一致するファイルを検索します。

関連性の基準： 要件ドキュメントが関連しているのは、次の条件を満たす場合です。

• トピックが機能の説明と意味的に一致している
• 過去30日以内に作成されている（ドキュメントが明らかに引き続き関連している、または明らかに古くなっている場合は、判断に基づいて例外を認めます）
• 同じユーザーの課題またはスコープを扱っていると思われる

複数のソースドキュメントが一致する場合は、利用可能であればプラットフォームのブロッキング質問ツールを使って、どれを使用するか尋ねます（「対話方法」を参照）。それ以外の場合は、チャットで番号付きの選択肢を提示し、ユーザーの返信を待ってから進めます。

0.3 ソースドキュメントを主要な入力として使用する

関連する要件ドキュメントが存在する場合：

1. 内容を十分に読みます
2. それを計画の起点となるドキュメントとして使用することを伝えます
3. 次のすべてを引き継ぎます。
   • 問題の枠組み
   • 要件と成功基準
   • スコープの境界
   • 重要な決定とその根拠
   • 依存関係または前提条件
   • 未解決の質問。ブロッキングか後回しかも維持します
4. 計画と調査の主要な入力としてソースドキュメントを使用します
5. 引き継いだ重要な決定を、計画内で (see origin: <source-path>) として参照します
6. ソースの内容を黙って省略してはいけません。起点となるドキュメントで扱われている内容は、たとえ簡潔でも計画で取り上げる必要があります。最終化する前に、起点となるドキュメントの各セクションを確認し、内容が抜けていないことを確かめます。

関連する要件ドキュメントが存在しない場合は、ユーザーの依頼を直接の出発点として計画を進めてもかまいません。

0.4 要件ドキュメントがない場合の代替手順

関連する要件ドキュメントが存在しない場合：

• 依頼が直接技術計画を立てられるほど明確かどうかを評価します
• 曖昧さの主な原因が、製品の枠組み、ユーザーの行動、またはスコープの定義である場合は、まず ce:brainstorm を推奨します
• それでもここで続けたいというユーザーには、拒否する代わりに、短い計画の初期確認を行います

計画の初期確認では、次の事項を明確にします。

• 問題の枠組み
• 想定される動作
• スコープの境界と明らかな対象外事項
• 成功基準
• ブロッキング質問または前提条件

この初期確認は簡潔にします。完全なブレインストーミングの代わりではなく、直接開始する手軽さを保つためのものです。

初期確認で重大な製品上の未解決事項が明らかになった場合：

• 改めて ce:brainstorm を推奨します
• それでもユーザーが続行を希望する場合は、先へ進む前に明示的な前提を求めます

0.5 計画の前に未解決の質問を分類する

起点となるドキュメントに Resolve Before Planning または同様のブロッキング質問が含まれている場合：

• 先へ進む前に、それぞれを確認します
• 実際に技術、アーキテクチャ、または調査に関する質問である場合に限り、計画側で扱う作業に再分類します
• 製品の動作、スコープ、または成功基準を変える可能性がある場合は、ブロッカーのままにします

真の製品上のブロッカーが残っている場合：

• その内容を明確に示します
• 利用可能であれば、プラットフォームのブロッキング質問ツールを使って（「対話方法」を参照）、次のどちらにするかユーザーに尋ねます。
  1. ce:brainstorm に戻り、ブロッカーを解決する
  2. 明示的な前提または決定として扱い、続行する
• 真のブロッカーが未解決のまま計画を続けてはいけません

0.6 計画の深さを評価する

作業を次のいずれかの計画の深さに分類します。

• 軽量 - 小規模で、範囲が明確に定まり、曖昧さが少ない
• 標準 - 通常の機能開発、または記録すべき技術的な決定を伴う、範囲の限定されたリファクタリング
• 詳細 - 複数の領域にまたがる、戦略的、高リスク、または実装の曖昧さが大きい作業

深さが明確でない場合は、的を絞った質問を1つしてから続行します。

フェーズ1：コンテキストを収集する

1.1 ローカルリサーチ (常に実行)

リサーチエージェントへの入力として渡す、簡潔な計画コンテキストの要約 (1～2 段落) を準備します:

• 元となるドキュメントが存在する場合は、そのドキュメントから問題の枠組み、要件、主要な決定事項を要約します
• それ以外の場合は、機能の説明をそのまま使用します

以下のエージェントを並行して実行します:

• Task compound-engineering:research:repo-research-analyst(Scope: technology, architecture, patterns. {planning context summary})
• Task compound-engineering:research:learnings-researcher(planning context summary)

以下を収集します:

• 技術スタックとバージョン (セクション 1.2 でより的確な外部リサーチの判断に使用します)
• 従うべきアーキテクチャパターンと規約
• 実装パターン、関連するファイル、モジュール、テスト
• 計画に実質的な影響を与える AGENTS.md のガイダンス (CLAUDE.md は存在する場合の互換性フォールバックとしてのみ使用)
• docs/solutions/ からの組織的な学び

1.1b 実行姿勢のシグナルを検出

計画に軽量な実行姿勢のシグナルを含めるべきかどうかを判断します。

次のようなシグナルを探します:

• ユーザーが TDD、テストファースト、または特性化ファーストの作業を明示的に求めている
• 元のドキュメントがテストファーストの実装、またはレガシーコードの探索的な堅牢化を求めている
• ローカルリサーチにより、対象領域がレガシーで、テストが不十分、または歴史的に脆弱であることが示され、動作を変更する前に特性化によるカバレッジが必要であることが示唆される
• ユーザーが外部委任を求めている、または「use codex」「delegate mode」と言及している、あるいはトークン節約に触れている -- 純粋なコード記述である実装ユニットに Execution target: external-delegate を追加します

シグナルが明確な場合は、関連する実装ユニット内で暗黙的に引き継ぎます。

姿勢が実行順序やリスクを実質的に変え、責任を持って推測できない場合にのみ、ユーザーに質問します。

1.2 外部調査を行うか判断する

元のドキュメント、ユーザーの反応、ローカルでの調査結果に基づいて、外部調査が役立つかどうかを判断します。

行間を読み取ります。 これまでの会話から得られる次のような手がかりに注意してください。

• ユーザーの習熟度 — 特定のファイルやパターンを指摘していますか？ コードベースをよく理解している可能性があります。
• ユーザーの意図 — 速度と徹底性のどちらを求めていますか？ 探索ですか、それとも実行ですか？
• トピックのリスク — セキュリティ、決済、外部 API に関わる場合は、ユーザーの反応にかかわらず、より慎重に対応します。
• 不確実性の度合い — アプローチは明確ですか、それともまだ定まっていませんか？

repo-research-analyst のテクノロジー情報を活用します。

repo-research-analyst の出力には、テクノロジーとインフラストラクチャの概要が構造化されて含まれています。これを活用して、外部調査の判断精度を高めます。

• 特定のフレームワークとバージョンが検出された場合（例：Rails 7.2、Next.js 14、Go 1.22）、その識別情報をそのまま framework-docs-researcher に渡し、バージョンに対応したドキュメントを取得します。
• 機能が、スキャンでコードベースに十分な実績が確認されたテクノロジーレイヤーに関わる場合（例：新しいバックグラウンドジョブを計画する際に、既存の Sidekiq ジョブがある）、外部調査を省略する方向で判断します。ローカルのパターンで十分な可能性があります。
• 機能が、スキャンでコードベースにほとんど存在しないか、十分に確立されていないテクノロジーレイヤーに関わる場合（例：新しい gRPC サービスを計画する際に、既存の proto ファイルがない）、外部調査を行う方向で判断します。参照できるローカルのパターンがありません。
• スキャンでデプロイインフラストラクチャ（Docker、K8s、サーバーレス）が検出された場合は、下流のエージェントに渡す計画コンテキストに記載し、デプロイ時の制約を考慮できるようにします。
• スキャンでモノレポが検出され、特定のサービスに対象が絞られている場合は、すべてのサービスの情報を集約するのではなく、そのサービスのテクノロジー情報を下流の調査エージェントに渡します。スキャンでワークスペースのマップが示されたものの、対象が絞られていない場合は、調査を進める前に機能の説明から関連するサービスを特定します。

次の場合は、常に外部調査を優先します。

• トピックのリスクが高い場合：セキュリティ、決済、プライバシー、外部 API、移行、コンプライアンス
• コードベースに関連するローカルのパターンがない場合
• ユーザーが不慣れな領域を探索している場合
• テクノロジースキャンで、関連するレイヤーがコードベースに存在しないか、十分に確立されていないと判明した場合

次の場合は、外部調査を省略します。

• コードベースに確立されたローカルのパターンがすでにある場合
• ユーザーがすでに意図する構成を把握している場合
• 外部の情報を追加しても、実用面でほとんど価値がない場合
• テクノロジースキャンで、関連するレイヤーに既存の参考例があり、十分に確立されていると判明した場合

続行する前に、判断を簡潔に伝えます。例：

• 「このコードベースには確立されたパターンがあります。外部調査を行わずに進めます。」
• 「決済処理に関わるため、まず最新のベストプラクティスを調査します。」

1.3 外部調査（条件付き）

ステップ 1.2 で外部調査が有用と判断した場合、次のエージェントを並行して実行します。

• Task compound-engineering:research:best-practices-researcher(planning context summary)
• Task compound-engineering:research:framework-docs-researcher(planning context summary)

1.4 調査結果をまとめる

次の内容を要約します。

• 関連するコードベースのパターンとファイルパス
• 関連する組織内の知見
• 収集した場合は、外部の参考資料とベストプラクティス
• 関連するイシュー、PR、または先行事例
• 計画に実質的な影響を与える制約

1.5 フローとエッジケースの分析（条件付き）

標準または詳細な計画の場合、あるいはユーザーフローの網羅性がまだ不明確な場合は、次を実行します。

• Task compound-engineering:workflow:spec-flow-analyzer(planning context summary, research findings)

出力を次の目的に活用します。

• 不足しているエッジケース、状態遷移、または引き継ぎの漏れを特定する
• 要件のトレーサビリティや検証戦略を強化する
• 計画の改善に実質的に役立つフローの詳細のみを追加する

フェーズ 2：計画に関する質問の解決

以下を基に、計画に関する質問のリストを作成します。

• 元のドキュメントで保留になっている質問
• リポジトリまたは外部調査で見つかった不足情報
• 有用な計画を作成するために必要な技術的判断

質問ごとに、次のどちらに該当するかを判断します。

• 計画中に解決 — リポジトリのコンテキスト、ドキュメント、またはユーザーの選択から回答が分かる質問
• 実装時まで保留 — コード変更、実行時の挙動、または実行時の調査によって答えが決まる質問

回答がアーキテクチャ、スコープ、順序、またはリスクに大きく影響し、責任を持って推測できない場合に限り、ユーザーに質問します。利用可能な場合は、プラットフォームのブロッキング質問ツールを使用してください（「対話方法」を参照）。

このフェーズでは、テストの実行、アプリのビルド、実行時の挙動の調査は行わないでください。目的は部分的な実行ではなく、優れた計画を作成することです。

フェーズ 3：計画の構成

3.1 タイトルとファイル名

• feat: Add user authentication や fix: Prevent checkout double-submit のような一般的な形式で、分かりやすく検索しやすいタイトルを作成します
• 計画の種類を決めます。feat、fix、または refactor
• リポジトリの規則に従ってファイル名を作成します。docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-beta-plan.md
  • docs/plans/ が存在しない場合は作成します
  • 今日の日付の既存ファイルを確認し、次の連番を決めます（3 桁のゼロ埋め、001 から開始）
  • 説明部分は簡潔に（3～5 語）、ケバブケースにします
  • 安定版として生成された計画と区別するため、-plan の前に -beta を付けます
  • 例：2026-01-15-001-feat-user-authentication-flow-beta-plan.md、2026-02-03-002-fix-checkout-race-condition-beta-plan.md
  • 避けるもの：連番の欠落、「new-feature」のような曖昧な名前、無効な文字（コロン、スペース）

3.2 ステークホルダーと影響の考慮

Standard または Deep の計画では、この変更の影響を受ける人（エンドユーザー、開発者、運用担当者、他のチームなど）と、それを計画にどう反映するかを簡潔に検討します。複数領域にまたがる作業では、「システム全体への影響」セクションに影響を受ける関係者を記載します。

3.3 作業を実装単位に分割

作業を論理的な実装単位に分割します。各単位は、通常、実装者がアトミックなコミットとして取り込める、意味のある変更を 1 つ表す必要があります。

適切な単位は次のとおりです。

• 1 つのコンポーネント、挙動、または統合箇所に焦点を当てている
• 通常、関連する少数のファイルを変更する
• 依存関係に沿った順序になっている
• コードを事前に書かなくても実行できる程度に具体的である
• 進捗を追跡できるよう、チェックボックス形式になっている

避けるもの：

• 2～5 分で終わる細かすぎる手順
• 関連のない複数の懸念事項にまたがる単位
• 実装者が依然として計画を考案しなければならないほど曖昧な単位

3.4 高レベルの技術設計（任意）

実装単位の詳細を記述する前に、概要を示すことでレビュー担当者が意図したアプローチを検証しやすくなるかどうかを判断します。このセクションでは、実装方法を指定することなく、ソリューションの全体像、つまり各要素がどのように連携するかを伝えます。

含める場合：

作業の内容...	最適な概要形式
DSL または API サーフェスの設計	疑似コードによる文法または契約の概要
複数コンポーネントの統合	Mermaid のシーケンス図またはコンポーネント図
データパイプラインまたは変換	データフローの概要
状態を多く扱うライフサイクル	状態図
複雑な分岐ロジック	フローチャート
形状が自明でない単一コンポーネント	疑似コードの概要

省略する場合：

• 説明文とファイルパスだけで全体像が伝わる、既存のパターンに沿った作業
• 単純な CRUD または慣例に従う変更
• アプローチが明白な軽量な計画

作業に適した形式を選びます。図のほうが伝わりやすい場合に疑似コードを既定として選んだり、その逆をしたりしないでください。

すべての概要には、次の文を添えます："これは意図したアプローチを示すものであり、レビューのための方向性を示すガイダンスであって、実装仕様ではありません。実装を行うエージェントは、再現すべきコードではなく、文脈として扱ってください。"

概要は簡潔に保ちます。方向性を検証できるだけの内容にとどめ、本番環境へそのままコピー＆ペーストできるほど詳細にしないでください。

3.5 各実装単位を定義する

各単位には、次の項目を含めます：

• 目標 - この単位で達成すること
• 要件 - どの要件または成功基準を前進させるか
• 依存関係 - 先に存在している必要があるもの
• ファイル - 作成、変更、またはテストする正確なファイルパス
• アプローチ - 重要な決定、データフロー、コンポーネントの境界、または統合に関する注意事項
• 実行上の注記 - 任意。テストファースト、特性評価ファースト、外部委任など、既定以外の実行方針がその単位に有効な場合にのみ記載
• 技術設計 - 任意。その単位のアプローチが自明でなく、説明文だけでは曖昧さが残る場合の疑似コードまたは図。実装仕様ではなく、方向性を示すガイダンスであることを明記する
• 従うべきパターン - 手本とする既存のコードまたは規約
• テストシナリオ - 対象とする具体的な動作、エッジケース、失敗時の経路
• 検証 - シェルコマンドのスクリプトではなく、結果として実装者が単位の完了を判断する方法

機能を含む各単位の **Files:** には、テストファイルのパスを必ず記載します。

Execution note は必要な場合にのみ使用します。適切な例：

• Execution note: Start with a failing integration test for the request/response contract.
• Execution note: Add characterization coverage before modifying this legacy parser.
• Execution note: Implement new domain behavior test-first.
• Execution note: Execution target: external-delegate

単位を文字どおりの RED/GREEN/REFACTOR の小ステップに分割しないでください。

3.6 計画時の不確定事項と実装時の不確定事項を分ける

重要ではあるものの、まだ把握できない事項がある場合は、計画内で解決したかのように扱わず、実装時に保留する注記として明示的に記録します。

例：

• メソッド名またはヘルパー名の詳細
• 実際のコードを確認した後に決める最終的な SQL またはクエリの詳細
• 実際のテスト失敗を確認してから判明するランタイム動作
• 実装開始後に不要になる可能性があるリファクタリング

フェーズ 4：計画を作成する

すべての深さで、同じ計画方針を用います。計画と実行の境界は変えず、詳細の量を調整します。

4.1 計画の詳細度に関するガイダンス

軽量

• 計画を簡潔に保ちます
• 通常、実装単位は2～4個です
• 価値をほとんど加えない任意のセクションは省略します

標準

• 今回の作業で価値のない任意のセクション（High-Level Technical Designを含む）を省略し、コアテンプレート全体を使用します
• 通常、実装単位は3～6個です
• 関連する場合は、リスク、先送りする質問、システム全体への影響を含めます

詳細

• 必要に応じて任意の分析セクションを加え、コアテンプレート全体を使用します
• 通常、実装単位は4～8個です
• 明確さが向上する場合は、単位をフェーズごとにまとめます
• 必要に応じて、検討した代替案、ドキュメントへの影響、より詳細なリスク対応を含めます

4.1b 詳細な計画に追加できる任意の項目

十分に大規模でリスクが高い、または複数の領域にまたがる作業では、本当に役立つセクションを追加します。

• 検討した代替アプローチ
• 成功指標
• 依存関係／前提条件
• リスク分析と軽減策
• 段階的な提供
• ドキュメント計画
• 運用／ロールアウトに関する注意事項
• 将来の検討事項：現在の設計に実質的な影響を与える場合のみ

これらを定型文として追加しないでください。実行の質やステークホルダー間の合意形成を高める場合にのみ含めます。

4.2 コア計画テンプレート

特に軽量な計画では、明らかに該当しない任意のセクションを省略します。

---
title: [Plan Title]
type: [feat|fix|refactor]
status: active
date: YYYY-MM-DD
origin: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md  # include when planning from a requirements doc
deepened: YYYY-MM-DD  # optional, set later by deepen-plan-beta when the plan is substantively strengthened
---

# [Plan Title]

## Overview

[What is changing and why]

## Problem Frame

[Summarize the user/business problem and context. Reference the origin doc when present.]

## Requirements Trace

- R1. [Requirement or success criterion this plan must satisfy]
- R2. [Requirement or success criterion this plan must satisfy]

## Scope Boundaries

- [Explicit non-goal or exclusion]

## Context & Research

### Relevant Code and Patterns

- [Existing file, class, component, or pattern to follow]

### Institutional Learnings

- [Relevant `docs/solutions/` insight]

### External References

- [Relevant external docs or best-practice source, if used]

## Key Technical Decisions

- [Decision]: [Rationale]

## Open Questions

### Resolved During Planning

- [Question]: [Resolution]

### Deferred to Implementation

- [Question or unknown]: [Why it is intentionally deferred]


## High-Level Technical Design

> *This illustrates the intended approach and is directional guidance for review, not implementation specification. The implementing agent should treat it as context, not code to reproduce.*

[Pseudo-code grammar, mermaid diagram, data flow sketch, or state diagram — choose the medium that best communicates the solution shape for this work.]

## Implementation Units

- [ ] **Unit 1: [Name]**

**Goal:** [What this unit accomplishes]

**Requirements:** [R1, R2]

**Dependencies:** [None / Unit 1 / external prerequisite]

**Files:**
- Create: `path/to/new_file`
- Modify: `path/to/existing_file`
- Test: `path/to/test_file`

**Approach:**
- [Key design or sequencing decision]

**Execution note:** [Optional test-first, characterization-first, external-delegate, or other execution posture signal]

**Technical design:** *(optional -- pseudo-code or diagram when the unit's approach is non-obvious. Directional guidance, not implementation specification.)*

**Patterns to follow:**
- [Existing file, class, or pattern]

**Test scenarios:**
- [Specific scenario with expected behavior]
- [Edge case or failure path]

**Verification:**
- [Outcome that should hold when this unit is complete]

## System-Wide Impact

- **Interaction graph:** [What callbacks, middleware, observers, or entry points may be affected]
- **Error propagation:** [How failures should travel across layers]
- **State lifecycle risks:** [Partial-write, cache, duplicate, or cleanup concerns]
- **API surface parity:** [Other interfaces that may require the same change]
- **Integration coverage:** [Cross-layer scenarios unit tests alone will not prove]

## Risks & Dependencies

- [Meaningful risk, dependency, or sequencing concern]

## Documentation / Operational Notes

- [Docs, rollout, monitoring, or support impacts when relevant]

## Sources & References

- **Origin document:** [docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md](path)
- Related code: [path or symbol]
- Related PRs/issues: #[number]
- External docs: [url]

大規模な Deep 計画では、有用な場合に限り、次のようなセクションでコアテンプレートを拡張します。

## Alternative Approaches Considered

- [Approach]: [Why rejected or not chosen]

## Success Metrics

- [How we will know this solved the intended problem]

## Dependencies / Prerequisites

- [Technical, organizational, or rollout dependency]

## Risk Analysis & Mitigation

- [Risk]: [Mitigation]

## Phased Delivery

### Phase 1
- [What lands first and why]

### Phase 2
- [What follows and why]

## Documentation Plan

- [Docs or runbooks to update]

## Operational / Rollout Notes

- [Monitoring, migration, feature flag, or rollout considerations]

4.3 計画のルール

• 変更されやすい行番号より、パスとクラス／コンポーネント／パターンの参照を優先します
• 進捗管理用の - [ ] 構文を使い、実装単位を確認可能な状態に保ちます
• 実装コードは含めません。インポート、正確なメソッドシグネチャ、フレームワーク固有の構文も含めないでください
• 設計の方向性を伝える場合は、High-Level Technical Designセクションおよびユニットごとの技術設計フィールドで、疑似コードのスケッチやDSLの文法を使用できます。実装仕様ではなく、方向性を示すガイダンスであることを明記してください
• 文章だけでは把握しにくい関係やフローを明確にできる場合は、Mermaid図の使用を推奨します。データモデルの変更にはER図、複数サービス間の連携にはシーケンス図、ライフサイクルの遷移には状態遷移図、複雑な分岐ロジックにはフローチャートを使用します
• gitコマンド、コミットメッセージ、具体的なテストコマンドの手順は含めません
• 実装単位を、細かな RED/GREEN/REFACTOR の手順に分解しません
• 計画を完全に見せるためだけに、実行時に確認すべき質問を解決済みのように扱わないでください

フェーズ5：最終レビュー、ファイルへの書き込み、引き継ぎ

5.1 書き込み前のレビュー

最終決定する前に、次の点を確認します。

• 計画に、ce:brainstorm で定義されるべきプロダクトの挙動を勝手に作り出していない
• 元となるドキュメントがない場合、範囲を限定した計画策定の準備によって、責任を持って計画を立てるのに十分なプロダクトの明確さが得られている
• すべての主要な決定が、元となるドキュメントまたは調査に基づいている
• 各実装単位が具体的で、依存関係の順序に沿っており、実装に着手できる状態になっている
• テストファーストまたは特性評価ファーストの方針が明示されている、あるいは強く示唆されている場合、該当する単位に簡潔な Execution note として引き継がれている
• テストシナリオが、テストコード化しない範囲で具体的になっている
• 先送りする項目が明示されており、確実性を装って隠されていない
• ハイレベル技術設計のセクションを含める場合、作業に適した形式を使用し、規範的でない書き方を保ち、実装コード（インポート、正確なシグネチャ、フレームワーク固有の構文など）を含んでいない
• 単位ごとの技術設計フィールドがある場合、コピーしてそのまま使えるほど詳細にせず、簡潔で方向性を示すものになっている

計画の作成元が要件ドキュメントの場合、そのドキュメントを読み直し、次の点を確認します。

• 選択したアプローチが、引き続きプロダクトの意図に合致している
• スコープの境界と成功基準が維持されている
• 阻害要因となる質問が解決済み、明示的な前提として設定済み、または ce:brainstorm に差し戻されている
• 元のドキュメントのすべてのセクションが計画で扱われている — 各セクションを確認し、暗黙のうちに抜け落ちたものがないことを確かめる

5.2 計画ファイルの作成

必須：選択肢を提示する前に、計画ファイルをディスクに書き込みます。

Write ツールを使い、計画全体を次の場所に保存します。

docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-beta-plan.md

次の内容を確認します。

Plan written to docs/plans/[filename]

パイプラインモード： LFG、SLFG などの自動ワークフロー、または disable-model-invocation のコンテキストから呼び出された場合は、対話形式の質問を省略します。必要な選択を自動で行い、計画の書き込みに進みます。

5.3 生成後のオプション

計画ファイルを書き込んだ後、利用可能な場合はプラットフォームのブロッキング質問ツールを使ってオプションを提示します（「インタラクション方法」を参照）。それ以外の場合は、チャットで番号付きのオプションを提示し、続行する前にユーザーの返信を待ちます。

質問：「計画の準備ができました：docs/plans/YYYY-MM-DD-NNN-<type>-<name>-beta-plan.md。次に何をしますか？」

オプション：

1. エディターで計画を開く - 確認できるよう、計画ファイルを開きます
2. /deepen-plan-beta を実行する - 計画にさらなる確信が必要な場合、対象を絞った調査で弱いセクションを検証します
3. document-review スキルを実行する - 構造化されたドキュメントレビューを通じて計画を改善します
4. Proof に共有する - 共同レビューと共有のために計画をアップロードします
5. /ce:work を開始する - 現在の環境でこの計画の実装を開始します
6. 別のセッションで /ce:work を開始する - 現在のプラットフォームがサポートしている場合、別のエージェントセッションで実装を開始します
7. Issue を作成する - 設定済みのトラッカーに Issue を作成します

選択内容に応じて：

• エディターで計画を開く → 現在のプラットフォームのファイルを開く機能またはエディターの機能を使って、docs/plans/<plan_filename>.md を開きます（例：macOS では open、Linux では xdg-open、または IDE のファイルを開く API）
• /deepen-plan-beta → 計画のパスを指定して /deepen-plan-beta を呼び出します
• document-review スキル → 計画のパスを指定して document-review スキルを読み込みます
• Proof に共有する → 計画をアップロードします：

  CONTENT=$(cat docs/plans/<plan_filename>.md)
  TITLE="Plan: <plan title from frontmatter>"
  RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \
    -H "Content-Type: application/json" \
    -d "$(jq -n --arg title "$TITLE" --arg markdown "$CONTENT" --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}')")
  PROOF_URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
  

  成功した場合は View & collaborate in Proof: <PROOF_URL> を表示し、その後オプションに戻ります
• /ce:work → 計画のパスを指定して /ce:work を呼び出します
• 別のセッションで /ce:work を開始する → 現在のプラットフォームが別のエージェントセッションの起動をサポートしている場合は、そのセッションで計画のパスを指定して /ce:work を開始します。サポートしていない場合は、制限を簡潔に説明し、代わりに現在のセッションで /ce:work を実行するよう提案します。
• Issue を作成する → 以下の「Issue の作成」セクションに従います
• その他 → 修正内容を自由記述で受け付け、オプションに戻ります

ultrathink が有効な場合、またはプラットフォームの推論／労力レベルが max または extra-high に設定されている場合、計画が Standard または Deep である場合、ハイリスクである場合、あるいは意思決定、順序、システム全体への影響、リスク、検証に関する重要な確信不足が依然として見られる場合に限り、自動的に /deepen-plan-beta を実行します。

Issue の作成

ユーザーが「Issue を作成する」を選択したら、AGENTS.md、互換性のために必要な場合は CLAUDE.md からプロジェクトのトラッカーを検出します。

1. project_tracker: github または project_tracker: linear を探します

2. GitHub の場合：

   gh issue create --title "<type>: <title>" --body-file <plan_path>
   

3. Linear の場合：

   linear issue create --title "<title>" --description "$(cat <plan_path>)"
   

4. トラッカーが設定されていない場合：

   • 利用可能であれば、プラットフォームのブロッキング質問ツールを使って、使用しているトラッカーを尋ねます（「インタラクション方法」を参照）
   • 今後の実行のために、トラッカーを AGENTS.md に追加するよう提案します

Issue の作成後：

• Issue の URL を表示します
• /ce:work に進むかどうかを尋ねます

コーディングは絶対にしないでください！調査し、判断し、計画を書いてください。