ce-brainstorm

機能や改善案をブレインストーミングする

ブレインストーミングでは、対話を通じて何を作るか（WHAT）を検討します。その後、ce-plan が同じ統合プラン成果物を充実させ、どのように作るか（HOW）をまとめます。このスキルではコードを実装しません。現在の年は2026年です。成果物の日付を記載する際に使用してください。

成果: ce-plan が、製品の動作、スコープの境界、成功基準を推測せずに作業を進められる分量の成果物です。軽量な作業ではチャットの段落、ファイルを作成する価値がある場合は <root>/plans/ 配下に要件のみを記した統合プランを作成します。

ブレインストーミングの完了条件: 成果物を作成して「Planning Ready チェック」に合格していること。あるいは、対話で、後続の読み手（プランナー、レビュアー、将来の読者）が安定した ID で記録しておく必要のある決定が出ず、ユーザーも記録を求めなかったため、ファイルを作成していないこと。いずれの場合も、Phase 4 の引き継ぎを提示している必要があります。

軽量な作業はチャットで完結します。 Phase 0.3 では、何かをディスパッチする前に、リクエストと範囲を限定したインライン読み取りをもとに作業の規模を分類します。規模が不確かな場合は、より大きい方を選びます。軽量な作業、つまり小規模で範囲が明確で曖昧さの少ない作業は、ファイル、根拠調査、アプローチの生成、主張の検証を行わず、チャットの段落で完結します。ファイルを作成するのは、後続の読み手が安定した ID で記録しておく必要のある決定がある場合、またはユーザーがファイルを求めた場合に限ります。

代わりに停止して別の経路に進むべきケースは3つあります。 記憶に頼らず、references/phase-0.md に従って判断してください。それぞれ独自の方法で実行を終了するため、上記の完了条件は適用されません。ソフトウェア以外の作業では、references/universal-brainstorming.md が Phase 0.2～4 に置き換わります。名前の挙がった外部候補について評価を求められた場合は、ce-pov への引き継ぎを提案します。どちらにも当てはまらない、簡単なサポート、事実に関する質問、単一ステップのタスクには、直接回答します。

機能の説明は、ユーザーが記述したものでも呼び出し元のスキルから渡されたものでも、呼び出し時に受け取る内容です。説明がない場合は、何を検討したいのかをユーザーに尋ね、回答を得るまで先に進まないでください。

mode:return-to-caller（lfg などの呼び出し元スキルが設定する先頭のトークン）がある場合は、これを取り除いて、対話は変更せずに進めます。Phase 4 は、references/handoff.md で定義されている構造化された返却に置き換えます。メニューは表示せず、lfg や ce-plan も呼び出しません。

成果物のルート

<root>/ のパスを初めて組み立てる、または読み取る際に <root> を解決し、それより前には解決しないでください。スクラッチのみの実行や、リポジトリにアクセスしない実行で該当するパスを使用しない場合は、解決を省略します。

成果物のパスを組み立てる前に、CE 成果物のルート <root> を解決してください。

• 読み取り: <repo-root>/.compound-engineering/config.yaml からのみ docs_root を読み取ります（<repo-root> は git rev-parse --show-toplevel で取得します）。config.local.yaml からは読み取りません。未設定の場合は、これまでどおり <root> を docs とします。
• 検証: 値が設定されている場合は、リポジトリ相対のディレクトリであり、シンボリックリンクを解決した実際のパスがリポジトリ内に収まり、リポジトリのルートでも .git/ 配下でもないことを検証します。条件を満たさない場合は、docs_root とその値を示すエラーで停止します。docs にはフォールバックしません。
• 使用: <root> だけを成果物の配置場所として使用します。存在しない場合は作成し、各パスはこのスキル固有のサブディレクトリを使って <root>/<subdir> の形式で組み立てます。また、docs を併せて読み取ることはありません。

brainstorm_output と brainstorm_model は、代わりに以下のルールで解決します。

通常の CE yaml キーは、2つのリポジトリ内ファイルから解決します。

• 読み取り: <repo-root>/.compound-engineering/config.local.yaml、次に config.yaml を読み取ります（<repo-root> は git rev-parse --show-toplevel で取得します）。ファイルが存在しない場合はスキップします。Gitignore は解決に影響しません。
• 優先: 最初に見つかった有効な値（コメントアウトされていない値）を採用します。スカラー値が空の場合は未設定として扱い、無効な値であれば次のレイヤーを確認し、その後スキルのデフォルト値を使用します。リストとマップは、キーが存在する場合、空のリストやマップも含めてキー全体を置き換えます。
• このルールを docs_root に適用しないでください。 このキーは config.yaml のみを参照します。

実行フロー

各フェーズはこの順序で実行します。それぞれ、正しく実行するために欠かせないファイルを示しています。そのフェーズに到達したらファイルを読み、この表だけを頼りに作業を進めてはいけません。

フェーズ	先に読むもの	それらのファイルにしか記載されていない内容
最初の質問の前、および実行全体 — ソフトウェア以外の経路も含む	references/interaction-rules.md を読む	コア原則とインタラクションルール：1ターンにつき質問は1つ、環境から判断できない決定だけを尋ねること、ブロッキング質問ツールの既定動作と、それを上書きするビジュアルプローブのゲート、質問が本当に自由回答式となる場合、このスキルがそこで全文を記載する唯一の ce-prototype ルーティングテスト
会話に含まれる決定を確定済みとして扱う前	references/settled-decisions.md を読む	確定判定テスト。これを省くと、決定済みの質問を再び尋ねたり、検証されていない主張を確定事項に格上げしたりします
0.0 出力モード	references/output-mode.md	OUTPUT_FORMAT の優先順位、トークン解析の規則
0.1–0.4 再開、分類、ルーティング、スコープ設定	references/phase-0.md	再開時のスキャン、停止してルーティングする分類、スコープの段階、作業の一貫性ゲート（これはひとまとまりの作業か？）、2つのトリップワイヤー（視覚的または空間的な機能、未経験の領域）、タスクリスト
1 アイデアを理解する	references/dialogue.md	コンテキストのスキャンとグラウンディング調査、オプトインの Slack 調査担当、ストレステスト、盲点とビジュアルプローブのゲート、既存の CONCEPTS.md および検証済みコードとの競合ゲート、Phase 1.3 の終了条件
2–2.6 アプローチ、統合、検証	references/approaches.md、および統合を作成する前に references/synthesis-summary.md	アプローチの生成、モデルの引き上げ、スコープ設定の統合、主張の検証
3 計画を書く	references/plan-write.md、続いて references/brainstorm-sections.md と形式に対応するレンダリングリファレンス	ドキュメントが必要かどうか、セクションの要件、計画作成準備チェック
4 引き継ぎ	references/handoff.md	選択肢のセットとその表示条件、レンダリングモードのルール、選択ごとのディスパッチ（ce-plan に渡す内容を含む）、締めくくりの要約

これらのルールは、ファイルを読まなくても適用されます。

OUTPUT_FORMAT は排他的です — Markdown または HTML のどちらか一方であり、両方ではありません。適用される形式の優先順位は、すべての実行（ヘッドレス実行を含む）において、プロンプト内のリクエスト、ユーザーが以前に示した好み、設定、Markdown の順です。

ブレインストーミング経路でファイルを書き込む場合、成果物の要件は変わりません：<root>/plans/YYYY-MM-DD-HHMM-<type>-<topic>-plan.<md|html> に書き込みます。HHMM には書き込み時の現地時刻を使用します。フロントマターには artifact_contract: ce-unified-plan/v1 と product_contract_source: ce-brainstorm を含め、本文はゴールカプセルとプロダクト要件で構成します。ゴール起動ブロックやリーダーインデックスは出力しないでください。ソフトウェア以外の経路では、これらを書き込みません。

ファイルを書き込む場合、計画作成準備チェックに不合格の項目がある間は、書き込み済みと宣言したり Phase 4 に進んだりしないでください。チャットで完結する場合は、実行するチェックなしで Phase 4（引き継ぎ）に進みます。即興の引き継ぎメニューも、見えないはずの選択肢を表示し、次のスキルに誤った入力を渡す、もう1つの見えにくい失敗です。

Phase 1.1 のグラウンディング調査、Phase 2.6 の主張検証、オプトインの Slack 調査担当は、モデル名で固定するのではなく、タスクの形状に応じて段階分けされます。これらをディスパッチする前に references/model-tiers.md を読んでください。モデルの引き上げは別の仕組みです（references/reasoning-elevation.md）。