ce-ideate

改善アイデアの生成

現在の年は2026年です — ドキュメントの日付や最近の成果物を確認する際は、この年を使ってください。

ce-ideate は ce-brainstorm の前に実行します。このスキルが答えるのは、「どのアイデアを検討する価値があるか」です。次に ce-brainstorm が、選んだアイデアが何を意味するのかに答えます。ce-plan は、それをどう構築するかに答えます。

完了条件： <root> が存在する場合は <root>/ideation/ に、存在しない場合は CE の一時パスに、順位付けされたアイデア創出成果物が書き込まれています。生成したアイデアはすべて批評済みで、選ばれた案についてのみ説明されています。ユーザーには次のステップの選択肢が示されています。要件、計画、コードは作成しません。

境界

1. アイデアを出す前に、根拠を集めます。 リポジトリに根拠のない助言はしません。
2. 多くの案を生成し、すべて批評し、選ばれた案だけを説明します。 どの案も批評する前に、候補の全リストを生成してください。却下は理由を明示します。楽観的に順位付けすることではありません。
3. 実行に移す際は、ユーザーをブレインストーミングに案内します。 アイデア創出の出力から、計画へ直接進むことはありません。
4. 対象が特定されていない状態で、処理を振り分けてはいけません。 現在のツールリストにあるホストのブロッキング質問ツールを使って質問してください（ホスト固有の名称ではなく、機能で照合します）。現在のツールリストに存在することは、そのツールが利用可能である証拠です。利用可能かどうかを確かめるために、ユーザー向け質問ツールを呼び出してはいけません。一致するツールがリストにあるものの未ロードの場合は、ホストのツール発見プリミティブを使ってその機能をロードしてください。別のホストのツール名を探してはいけません。該当するツールがリストにない場合は、ユーザーに見える画面に番号付きの選択肢を提示してください。質問を黙って省略してはいけません。「おまかせ」は、適切に終了する「キャンセル」と並べて、実際に選べる選択肢として残してください。解決策の方向性、制約、対象読者、トーン、成功基準について質問してはいけません。それらは ce-brainstorm が尋ねます。質問が3つを超える場合は、アイデア創出に適したワークフローではありません。
5. 内部の分類ラベルを出力してはいけません。 repo-grounded、elsewhere-software、elsewhere-non-software のラベルは、どのエージェントに処理を振り分けるかを判断するためだけに使います。ユーザーには、トピック本来の言葉でモードを説明してください。
6. 根拠の収集に失敗した場合は、警告してから続行します。
7. 処理を振り分ける前に、コストの行をユーザーに提示します。

フォーカスヒントとは、ユーザーまたは呼び出し元のスキルから、この実行時に渡された任意のコンテキストです。このスキルの残りの部分では、これを {focus_hint} と呼びます。

成果物のルート

成果物は <root>/ideation/ に置き、学びは <root>/solutions/ から読み込みます。<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 を併せて読み込んではいけません。

フェーズ 0：再開とスコープ

このフェーズで指定されている2つの参照資料は、対象、モード、形式が明確に見える場合でも、どちらも必ず読みます。この2つの参照資料で、再開時の確認、形式の決定、スコープの分類が定義されています。これらを読む前に、ここに記載された事項を確定してはいけません。

出力モードはどちらか一方のみです。 実行時に生成するのはHTML（.html）またはMarkdown（.md）のいずれかであり、両方ではありません。優先順位は、このプロンプト内のリクエスト、明示されたユーザーの希望と設定（ideate_output:）、最後にデフォルトのhtmlの順です。ヘッドレス実行でも同じ方法で形式を決定し、パイプラインによる上書きはありません。

形式を決定する際は、必ずreferences/output-mode.mdを読みます。この参照資料は必読です。形式決定の各手順と、今回の実行で新しいドキュメントを作成する代わりに既存のドキュメントを更新するかどうかを判断する、過去30日間の作業の確認方法が定義されています。

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

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

ソフトウェア以外のルーティング。 ソフトウェアに関するトピックでない場合は、リポジトリのスキャンではなく、他所モードのグラウンディングを実行します。その後、フェーズ2のフレームとフェーズ5のメニューの代わりにreferences/universal-ideation.mdに従います。成果物は引き続き自動的に作成されます。

フェーズ0の確認事項。 references/scope-gates.mdでは、フェーズ0のすべての確認事項に加え、「おまかせ」実行と戦術的実行での変更点を定義しています。対象を特定できない場合は質問します。go deepは戦術的なシグナルより優先されます。

フェーズ 1：モードを考慮したグラウンディング

グラウンディングエージェントを呼び出す前に、references/grounding.mdを読みます。この参照資料は必読です。このフェーズでのすべての呼び出しに加え、どちらかの呼び出しブロックを実行する前のルーティング判定も定義されています。グラウンディングはフォアグラウンドで並行して実行します。

ジェネリックなサブエージェントとは、送信するプロンプト全体だけを指示として受け取るサブエージェントです。ホストのサブエージェントツールでエージェント名の指定が必要な場合は、ホストの一覧にある名前のみを使います。一覧をまだ確認していない場合は、最初の呼び出し前にエージェント一覧を取得します。独自の役割を追加しないシンプルなものを選んでください。その場合もジェネリックなサブエージェントとして扱われます。レビュアーやワーカーエージェントなど、独自の役割プロンプト、出力形式、ツール制限によってこちらのプロンプトを置き換えたり、範囲を狭めたりするスペシャリストは選ばないでください。

スクラッチデータは、ユーザーの有効なプライベートCEルートの配下に置きます。利用可能な場合は/tmp/compound-engineering-<uid>を使用し、それ以外の場合は検証済みの$TMPDIRのフォールバック先を使用します。.context/は使用しません。8桁の16進数の<run-id>を1つ生成し、キャッシュとすべてのチェックポイントで再利用します。

フェーズ 1.5：トピックの表層分解

フレームを呼び出す前に、トピックを3～5個の直交する軸、つまり対象について考える観点に分解します。references/decomposition.mdを読みます。このフェーズを省略するのは、「おまかせ」モードの場合のみです。対象が分解するには小さすぎるかどうかは、そのファイルに記載された基準に従って判断するため、読み込んだ後に判定します。軸のリストまたは省略理由を、グラウンディングの概要のTopic axesの下に追記します。エビデンススカウトはリポジトリモードでのみ使用します。

フェーズ 2：発散的なアイデア創出

呼び出しプロンプトを作成する前に、references/divergent-ideation.mdを読みます。エージェント群、フレーム、生成ルールは、この参照資料にのみ記載されています。統合、総合、軸の網羅性に関する手順が完了したら、次に必読の資料として指定されているreferences/post-ideation-workflow.mdに進みます。