ideate

ブレインストーミングスキル

概要

新機能、アーキテクチャ上の意思決定、複雑な問題解決に向けた、共同での設計検討です。短縮フローでは、独立した設計フェーズはありません。{{COMMAND_PREFIX}}ideate が単一の統合された docs/specs/ 成果物の ## Design & Rationale セクションを作成し、その後、自動的に {{COMMAND_PREFIX}}plan に連携して、同じドキュメントに ## Decomposition セクションを追加します。唯一の承認ポイントは plan-review です（統合ドキュメントに対して、新しいコンテキストで実施される、ディスパッチされた敵対的レビュー）。

成果物の形式は統合仕様テンプレートで定義されています。形式を再記述せず、それに沿って作成してください。@skills/plan/references/spec-template.md を参照してください。

起動条件

次の場合にこのスキルを起動します。

• ユーザーが「ブレインストーミングしよう」「アイデアを出そう」「検討しよう」と言う
• ユーザーが {{COMMAND_PREFIX}}ideate コマンドを実行する
• ユーザーが分解の前に設計の根拠について話し合いたい
• 評価が必要な複数の有効な解決策がある問題（deep 段階）

完全な実例については、references/worked-example.md を参照してください。

計画の深さ（デフォルトはワンパス、deep で発散ループを有効化）

設計セクションは3段階のいずれかで作成します。PLAN 開始時に、機能ごとに designDepth として解決し、固定します。これはタスクごとの riskTier に相当する機能単位の値です。リゾルバーは概要のシグナル（不確実性、影響範囲、タスク数）から深さを提案し、作成者が確認または上書きします。上位の段階は、下位の段階を厳密に包含します。

designDepth	このスキルの動作	適用場面
thin	ワンパス：問題の説明と DR-N リストのみ。代替案や検討はありません。	分解そのものが実質となる、単純で影響範囲の小さい機能。
standard	ワンパス：根拠の全項目（問題、選択したアプローチ、受け入れ条件を含む DR-N、技術設計、代替案）。（デフォルト）	ほとんどの機能。
deep	以下の発散ループ：誠実なトレードオフと人間とのやり取りを伴う、真に異なる2〜3つのアプローチの検討、およびオプトインの discover ブリッジ。	オープンな設計プロセスが妥当となる、不確実性または影響範囲の大きい機能。

2〜3つのアプローチを検討するのは deep 段階であり、デフォルトの儀式ではありません。 thin／standard ではワンパスで収束させ、問題が必要としていない代替案を無理に作らないでください。

プロセス

フェーズ 0：制約の確認（フェーズ 1 の前、最初のターン）

目標： 明確化の質問をする前に、提案に関連するアーキテクチャ上の不変条件を明らかにし、最初のターンから設計を重要な制約に基づいて進めます。

.exarchos/invariants.md にあるコア不変条件カタログ（cost-of-load: always-load の項目）を読み込み、関連する不変条件を明記した Constraints セクションを提示します。たとえば、CLI／エージェント優先のインターフェース提案では、INV-5a（入力の使いやすさ）と INV-5c（Aspire の動詞）を基準にします。完全な選択ルール（always-load のベースライン、オンデマンドで読み込む reference-only、提示しない archivable、提案の形状から基準となる不変条件を選ぶ表、出力形式、ならびに invariants.catalogs にカタログが登録されている場合に限って提示するカタログ登録ゲート）は、/ideate、/refactor、/debug で使う設計時の Constraints ステップに関する共通の唯一の信頼できる情報源です。@skills/ideate/references/constraint-anchoring.md を参照してください。

明確化の質問で設計の途中に不変条件を再発見するのではなく、重要な不変条件に照らして提案を掘り下げられるよう、フェーズ 1 の前に（そのリファレンスに従って）Constraints セクションを出力します。

フェーズ 1：理解

目標： 設計を提案する前に、問題を深く理解します。

ルール：

• 一度に質問するのは 1 つだけです
• 次の質問をする前に回答を待ちます
• 目標、制約、既存のパターン、ユーザーの好みに焦点を当てます
• 次のフェーズに進むまでの質問は最大 5 つです

質問の種類：

1. 「どのような問題を解決しますか？」（中核となるニーズ）
2. 「どのような制約がありますか？」（時間、技術、互換性）
3. 「コードベースにはどのようなパターンがありますか？」（一貫性）
4. 「誰が／何がこれを利用しますか？」（ユーザー、API、その他のシステム）
5. 「成功とはどのような状態ですか？」（受け入れ基準）

フェーズ 2：検討 — deep の段階のみ

目標（designDepth: 'deep' の場合）： 明確に異なる 2～3 種類のアプローチを、利点と欠点を率直に示して提示し、1 つを推奨して、ユーザーとのやり取りを通じて方向性を定めます。

references/design-template.md のアプローチ形式を使用します。実質的に異なるアプローチを提示し、根拠とともに 1 つを推奨します。オプトインの discover ブリッジ： deep の段階では、ランタイムが next_actions を介して discover ブリッジの機能を公開します（DR-7）。これは、{{COMMAND_PREFIX}}discover のリサーチワークフローへの、イベントに関連付けられた correlationId による連携を伴うエスカレーションです。自動実行されることはありません。 作成者に提示し、確認を得た場合にのみエスカレーションします。探索セクションには、パスと correlationId を記載して discover レポートを引用し、両方のドキュメント間で出典を追跡できるようにします。

thin／standard ではこのフェーズを省略し、フェーズ 3 で直接方向性を定めます。

フェーズ 3：設計と根拠セクションの作成

目標： @skills/plan/references/spec-template.md の構成を使用し、確定した深度に応じて、統合された docs/specs/ 成果物の ## Design & Rationale セクションを作成します。各セクションは最大 200～300 語とし、複雑なフローには図を使用します。

要件の形式（必須）：

• ### Requirements (DR-N) 見出しの下に、番号付きの要件識別子（DR-1、DR-2、…、DR-N）を使用します
• 各要件には、具体的でテスト可能な基準を記載した **Acceptance criteria:** ブロックを必ず含めます（thin では箇条書き 1 つでも構いません）
• 少なくとも 1 つの要件で、エラー処理、障害モード、またはエッジケースに対処する必要があります
• これらの DR-N 識別子は出典を追跡するための基点です。## Decomposition セクションでは、別のファイルを作成せず、同じドキュメント内でタスクと要件の対応を追跡します

保存先： docs/specs/YYYY-MM-DD-<feature>.md。パスを $SPEC_PATH として記録します。

イテレーションの上限

設計のイテレーション：最大 3 回（deep の発散ループ）。フェーズ 2 が 3 回のラウンドを経てもユーザーの方向性が定まらない場合は、一時停止し、最終判断に向けてトレードオフを要約します。

ユーザーは上書きできます：{{COMMAND_PREFIX}}ideate --max-iterations 5

アンチパターン

しないこと	代わりにすること
すぐに解決策に飛びつく	まず明確化のための質問をする
thin／standard で 2～3 個の選択肢を作り上げる	発散ループは deep の段階に限定する
推奨する選択肢の欠点を隠す	トレードオフを率直に示す
長文を延々と書く	セクションを最大 200～300 語にする
既存のパターンを無視する	コードベースの規約を参照する
別の docs/designs/ ドキュメントを作成する	1 つの docs/specs/ 成果物の「設計と根拠」§を作成する
discover へ自動的にエスカレーションする	ブリッジを提示し、作成者の確認後にのみエスカレーションする

状態管理

このスキルは、コンテキストの永続化のためにワークフローの状態を管理します。

開始時（フェーズ 1 の前）

{{MCP_PREFIX}}exarchos_workflow を使用して、action: "init"、workflowType: "feature"、および featureId を指定し、ワークフローの状態を初期化します。feature ワークフローの初期フェーズは plan です（以前の ideate／GATHER フェーズは PLAN に統合されています）。ここで遷移するフェーズはありません。

設計セクションの保存時（フェーズ 3 の後）

統合された仕様のパスを artifacts.design ではなく artifacts.spec として保存します（新しいフローでは docs/specs/ の成果物を 1 つ作成します）。

action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }

ここではフェーズを遷移させないでください。{{COMMAND_PREFIX}}plan が ## Decomposition セクションを追加して統合ドキュメントを完成させ、plan → plan-review に遷移させます。

フェーズ遷移とガード

このスキルは、機能ワークフロー（workflowType: "feature"）のエントリーポイントです。簡略化されたライフサイクルは次のとおりです。

plan → plan-review → delegate ⇄ review → synthesize → completed

{{COMMAND_PREFIX}}ideate と {{COMMAND_PREFIX}}plan はどちらも、初期の plan フェーズ内で唯一の docs/specs/ 成果物を作成します。遷移の完全な表については、@skills/checkpoint/references/phase-transitions.md を参照してください。

スキーマの確認

パラメータスキーマについては exarchos_workflow({ action: "describe", actions: ["update", "init"] }) を使用し、 フェーズ遷移、ガード、プレイブックのガイダンスについては exarchos_workflow({ action: "describe", playbook: "feature" }) を使用してください。

完了とカバレッジ

簡略化されたフローには、設計の完成度を確認する独立したゲートはありません。check_design_completeness は非推奨のエイリアスです。設計セクションの受け入れ基準のカバレッジは、統合成果物を対象とする check_plan_coverage の一環として検証されます。## Decomposition セクションが存在する場合に、{{COMMAND_PREFIX}}plan が実行します。次の工程に進む前に、各 DR-N に受け入れ基準があり、少なくとも1つの DR-N がエラー処理／エッジケースをカバーしていることを確認してください。

遷移

設計と根拠（Design & Rationale）セクションの作成後、分解へ自動的に続行します（ユーザーの確認は不要です）。

チェーン実行前の検証（必須）

{{COMMAND_PREFIX}}plan を呼び出す前に：

1. ワークフローの状態に artifacts.spec が存在することを確認します
2. 仕様ファイルがディスク上に存在することを確認します：test -f "$SPEC_PATH"
3. 手順1または2に失敗した場合：「仕様成果物が見つかりません。{{COMMAND_PREFIX}}plan に自動的にチェーンできません」

チェーンの手順

1. 状態を更新します：action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }
2. 出力します：「設計と根拠（Design & Rationale）セクションを統合仕様に保存しました。分解へ自動的に続行しています...」
3. 直ちに呼び出します：

   {{CHAIN next="plan" args="$SPEC_PATH"}}
   

これは人間によるチェックポイントではありません。人間による唯一のチェックポイントは、plan-review（統合成果物に対する、委任された敵対的レビュー）とsynthesize（マージの確認）で発生します。

ワークフローの続行： {{COMMAND_PREFIX}}ideate -> {{COMMAND_PREFIX}}plan -> plan-review -> [人間によるチェックポイント] -> {{COMMAND_PREFIX}}delegate -> {{COMMAND_PREFIX}}review -> {{COMMAND_PREFIX}}synthesize -> [人間によるチェックポイント]

Exarchos との連携

Exarchos MCP ツールが利用可能な場合：

1. ワークフロー開始時： exarchos_workflow の action: "init" によって自動的に出力されます。workflow.started を手動で追加しないでください。