ブレインストーミング：アイデーション・スキル

あらゆる領域（ソフトウェア、ビジネス、創造的プロジェクト、個人的な決定）においてアイデアを拡大し、収束的思考を逃れるのをお手伝いします。

コア原則

アイデアは成長の余地と衝突するものが必要です。 行き詰まっていて足がかりから抜け出す必要がある場合があります。種を持っていて、それを広げたい場合もあります。どちらもアイデーション問題ですが、異なる入口があります。

2つのモード、1つの目標：最初に利用可能な選択肢に落ち着くのではなく、可能性の空間を探索すること。

入口の診断

本題に入る前に、どこから始めるのかを特定してください：

開始地点	信号	モード
行き詰まり	同じアイデアが何度も浮かぶ。すべての選択肢が変種に見える。「すべてを試した」。評価が探索より優先される。	→ エスケープ・ベロシティ・プロトコル
種	何かの始まりを持っている。それがどうなるかを見たい。隣接する動きや足りない部分を探している。	→ 種の拡大プロトコル
不明確	行き詰まっているのか、単に初期段階なのか不確かだ。何かは持っているが、それが良いかどうか不確かだ。	→ 種の拡大から開始。収束に達したらエスケープ・ベロシティに切り替え

重要な質問： 何かから抜け出そうとしているのか（行き詰まり）、それとも何かへ成長しようとしているのか（種）？

---

収束の問題（行き詰まりモード）

アイデアは複数の次元で予期されたパターンにマッチするため、クラスタ化します。ソリューションが明白なWHO（誰が）による明白なWHAT（何を）を明白なSCALE（規模）で明白なMETHOD（方法）を通じて実行している場合、それが予測可能に感じる理由はそこにあります。

重要なテスト： 3人の異なる人がそれぞれ独立してブレインストーミングを行い、同じリストを作成できるか？ はいの場合、まだ発散していません。

状態

State B1：収束盲目

症状：

• 最初のアイデアがすぐに「正しい」と感じる
• すべてのアイデアが同じアプローチの周りに集まる
• セッションが同じテーマの変種を生成する
• 「私たちは何をすべきか既に知っている、選ぶだけだ」

重要な質問：

• 最も明白なソリューションは何か？ それを明示的に名前付けしたか？
• 3人の異なる人が同じリストを作成するか？
• 空間を探索しているのか、それとも直感を確認しているのか？
• 基本的に異なるアプローチ（変種ではなく）がいくつテーブルにあるか？

介入： デフォルト列挙を実行する（フェーズ1）。クラスタを命名してから逃げようとします。見えないデフォルトから逃げることはできません。

---

State B2：機能ロック

症状：

• アイデアがすべて同じ形式を取る
• 議論がソリューション型を仮定する（「アプリが必要...」）
• ソリューション形式が想定されているため、代替案が見えない
• 「Xが必要」ではなく「Yを達成する必要がある」

重要な質問：

• これは何を達成する必要があるのか？（何であるべきかではなく）
• 完全に異なる何かが同じ結果を達成できるか？
• 実際に何の問題を解いているのか、対 何のソリューションに執着しているのか？
• 実際の制約対 想定上の制約は何か？

介入： 機能抽出を実行する（フェーズ2）。WHATをHOWから分離。ソリューションごとではなく、機能ごとに5つの代替案を生成。

---

State B3：軸の崩壊

症状：

• アイデアが見た目は異なるが、根本的な構造を共有する
• 「異なる服を着た同じアイデア」
• WHOは異なるが、WHAT/WHEN/HOWは同じ
• すべてのアイデアを1つのバケットに分類するのが簡単

重要な質問：

• この明白なWHOは何か？ 完全に異なる誰かを試したか？
• 明白なWHENは何か？ 10倍遅くなったら？ 即座に？ 反復対 1回きり？
• 明白なSCALEは何か？ 10倍大きくなったら？ 10倍小さくなったら？
• 明白なMETHODは何か？ 完全に異なるアプローチは何か？

介入： 軸マッピングを実行する（フェーズ3）。デフォルトソリューションを4つの軸でマップ。パターンを破るために少なくとも1つの軸を回転。

---

State B4：ドメイン投獄

症状：

• すべてのアイデアが同じ参照クラスから来ている
• 「常にやり方」または「我々の業界のやり方」
• ソリューションはその分野の誰にとっても明白
• 隣接する、または遠い領域からのアイデアがない

重要な質問：

• このアイデアはどの分野/業界から来ているか？
• どのドメインが確実に何か同様のことを解いているか？
• 完全に異なる職業はこれにどう接近するか？
• どの業界がこの問題を些細なことと思うか？

介入： ドメイン・インポートを実行する（フェーズ4）。3以上の無関連な分野からロジックを適用してアイデアを生成。constraint-entropy.ts と domains カテゴリを使用。

---

State B5：生産的な発散

症状：

• アイデアが異なるフォーム、スケール、アクター、タイムフレームに及んでいる
• 生成の問題ではなく評価の問題（多くのオプション）
• いくつかのアイデアが不快または驚くべき感覚
• すべてのアイデアを1つのクラスタにグループ化するのが難しい

重要な質問：

• どの基準がこれらをフィルタするべきか？
• トップ候補の最小実行可能実験は何か？
• どのアイデアを組み合わせることができるか？
• どのアイデアが異なるユーザーセグメントに対応しているか？

介入： 評価フレームワークに移動。アプローチでクラスタ化し、各クラスタから代表的なものを選んでプロトタイプ/テスト。

---

エスケープ・ベロシティ・プロトコル

収束的ブレインストーミングから抜け出すための構造化プロセス。行き詰まったセッションには5つのフェーズすべてを使用。問題が明確な場合は関連するフェーズをスキップ。

フェーズ1：デフォルト列挙（必須）

「実在する」アイデアを生成する前に、デフォルトを明示的に列挙：

• 「誰でも」何を提案するか？
• この問題に対する業界/ジャンルのデフォルトは何か？
• あなた/あなたのチームは最後に何を提案したか？
• 最初の検索結果は何と言うか？

出力： 5～10の明白なアイデア、デフォルトとして明示的にラベル付けされたリスト。

目的： アトラクターを見えるようにする。命名していないものから逃げることはできません。

---

フェーズ2：機能抽出

各要件について、WHATをHOWから分離：

• 何を達成する必要があるか？（機能）
• HOWについて何を想定しているか？（形式）
• 実際の制約対 想定上の制約は何か？

リフレーミング： 「[FORM]が必要」は「[FUNCTION]が必要で、[FORM]は1つの方法」に

出力： ソリューションが達成する必要がある3～5のコア機能、形式に依存しないリスト。

例：

• 「モバイルアプリが必要」→「ユーザーが外出先でXを達成する必要があり、モバイルアプリは1つの形式」
• 「週次ミーティングが必要」→「チーム間で情報が流れる必要があり、ミーティングは1つのメカニズム」

---

フェーズ3：軸マッピング

デフォルトソリューションを4つの軸でマップ：

軸	質問	デフォルト	代替案
Who	誰がこれを実行/使用/所有するか？	[明白なアクター]	3つの起こりそうもないアクター
When	タイムフレーム/頻度は？	[明白なタイミング]	異なるペースシ/タイミング
Scale	何のサイズ/スコープか？	[明白なスケール]	10倍大きい？ 10倍小さい？
Method	どんなアプローチ/メカニズムか？	[明白なアプローチ]	完全に異なるアプローチ

重要な洞察： アイデアが「もっともらしい」すべての軸にマッチするとき、予測可能に感じます。任意の軸を変更すると、アイデアが不明白になります。

出力： 軸ごとに少なくとも2つの代替案を含む完成した軸マップ。

---

フェーズ4：エントロピー注入

ランダムな制約を導入して探索を強制：

エントロピーの種類：

• ランダムなアクター（異なるドメインから）
• ランダムな制約（時間、リソース、能力の制限）
• ランダムな組み合わせ（これとも、無関連の何かも解く）
• 反転（何がこれを防ぐか？ 今、それを中心に設計）
• ドメイン・インポート（[ランダムな分野]はこれをどう解くか？）

ツール： constraint-entropy.ts を使用してランダムな制約を生成：

deno run --allow-read constraint-entropy.ts --combo
deno run --allow-read constraint-entropy.ts domains --count 3
deno run --allow-read constraint-entropy.ts inversions

出力： 異常な制約の下で生成された3～5のアイデア。

目的： 非隣接的な可能性の空間の探索を強制。不快な場合でも制約を受け入れる。

---

フェーズ5：直交性監査

有望なアイデアについて、以下をチェック：

• このアイデアは「それが明白なソリューション」であることを「知っている」か？（「私は予期されたアプローチです」と述べることができるなら、収束している）
• これはジャンル・デフォルトを期待している人を驚かすか？
• 実際にどの軸を回転させたか？
• これは予期された形式を破りながら機能に対応しているか？

テスト： アイデアが正真正銘に発散しているのは、その問題を「対応する」のではなく「衝突させる」独自のロジックを持つ場合です。

出力： 本当に発散しているか対 見た目だけ異なるかでフラグ付けされたアイデア。

---

種の拡大プロトコル

初期の種からアイデアを成長させるための構造化プロセス。Steven Johnsonの「良いアイデアはどこから来るか」についての研究に基づいています。何かから逃げるのではなく、何かを拡大する場合に使用。

Johnson の原則

これらは鼓舞的ではなく、診断的です。それぞれがアイデアが実際にどのように発展するか、メカニズムについて説明します：

原則	メカニズム	診断的質問
隣接可能性	ほとんどの「新しい」アイデアは、存在するものから到達可能な次のステップです。テレポーテーション、階段。	この種から1ステップ離れているのは何か？ これが存在したら何が可能になるか？
液体ネットワーク	アイデアは部分的な思考が衝突するときに形成されます。人、工芸品、過去の仕事、無関連なドメイン。	この種は何と衝突すべきか？ 環境の何が接続する可能性があるか？
遅いヒント	多くの良いアイデアは半焼きで始まります。彼らが行方不明のピースに会うまで時間が必要です。	この種について何が不完全か？ それを完成させるのは何か？
幸運	運プラス認識。有用な異常に気づく場合。	最近遭遇した予期しないことで、つながるかもしれないのは何か？
エラー	失敗は情報です。フィードバックは放浪を収束に変えます。	このダムな最初のバージョンは何か？ これはどこで壊れるか？
外適応	1つの仕事のために造られたものを別の仕事に転用。再使用は発明。	この種は完全に異なる問題を解くことができるか？ ここで使える、別の何かのために造られた何か？
プラットフォーム	安定した原始的なもののおかげで、人々はより速く、より安全に構築できます。	これが構築できる安定したものは何か？ これを他のアイデアのプラットフォームにするのは何か？

---

種の状態診断

拡大する前に、どんな種を持っているか理解：

State S1：隣接準備完了

信号：

• 種は具体的で特定的
• それが何をするかは明確、何が次かは不明確
• より大きな何かの「ステップ1」のように感じる

重要な質問：

• これが存在したら、存在しない今、何が可能になるか？
• 誰かが自然に欲しがる次のステップは何か？
• あなたはこれの上に何を構築するか？

拡大： 隣接可能性をマップ。この種から到達可能な3～5のことを列挙。最も興味深いものを選んで繰り返します。

---

State S2：衝突飢渴

信号：

• 種は単独では不完全に感じる
• 「何か他に」が必要という感覚
• いくつかのコンテキストでは機能するが、他では機能しない

重要な質問：

• このアイデアを見たことがないドメインはどれか？
• これは何の過去の仕事を思い出させるか？
• 誰がこれを明白に見つけるか？ 誰がそれを外国人と見つけるか？

拡大： 衝突を強制。ドメイン、制約、工芸品を種に投げ込みます。必要に応じてエスケープ・ベロシティ・プロトコルからエントロピー注入を使用。

---

State S3：半焼きの直感

信号：

• まだ完全にアイデアを表現できない
• 重要に感じるが、ファジー
• 「ここに何かがあるが、名前をつけられない」

重要な質問：

• あなたが明確に表現できる部分は何か？
• これが完成したら、どんな質問に答えるか？
• 足りないもの（メカニズム？ 例？ 用途？）

拡大： 完了を強制しないでください。あなたが持っているものを表現します。ギャップに名前をつけます。直感を書き下ろすことで生かし続け、その後、ギャップを埋めるかもしれない衝突を探します。

---

State S4：エラー豊富

信号：

• 種は試行済みで失敗している
• 何が機能しないか知っている
• 失敗が終局的ではなく、情報的に感じる

重要な質問：

• 具体的に何が壊れたか？（メカニズム、コンテキスト、実行？）
• 失敗はソリューション構造について何を明かしたか？
• これが機能するために何が変わる必要があるか？

拡大： 失敗を採掘。エラーはソリューションの形についての情報を含んでいます。学んだことを列挙し、失敗モードを回避する隣接した種を探してください。

---

State S5：外適応の候補

信号：

• 種は元の目的のために非常にうまく機能する
• 完全に別の何かができるという感覚
• 「これは私に X を思い出させる」ここで X は無関連

重要な質問：

• この種は何の仕事のために造られたか？
• 他の仕事は似た構造を共有するか？
• この種を移植する場所は驚くべきが妥当か？

拡大： 意図的に移植。5つの完全に異なるコンテキストを列挙。各コンテキストで種を試してください。何が変わり、何が生き残るか注意。

---

種拡大フェーズ

エスケープ・ベロシティ（順序立ったもの）と異なり、種状態に基づいて必要に応じてこれらのフェーズを使用：

フェーズ S1：種の明示

拡大する前に、あなたが持っているものをキャプチャ：

• この種のコアは何か？（1文）
• それは何に良いか？ 何に良くないか？
• どこから来たか？（衝突、隣接ステップ、直感、失敗、外適応？）
• 現在の不確実性は何か？

出力： 種とそれがどんな種であるかについての明確なステートメント。

---

フェーズ S2：隣接マッピング

この種から到達可能なものをマップ：

• 1ステップ離れているのは何か？
• 以前は不可能だった何が可能になるか？
• これが成功したら自然に何が続くか？
• 誰かがこれの上に何を構築するか？

出力： 3～5の隣接可能性、1つは「最も興味深い」とマーク。

---

フェーズ S3：衝突生成

種を他の素材と衝突させることを強制：

• ドメイン衝突： [無関連な分野]はこの種をどう見るか？
• 工芸品衝突： [ランダムな分野]はどの過去の仕事（あなたまたは他人の）か？
• 制約衝突： 異常な制約の下では何が起こるか？
• 反転衝突： 反対は何か？ 反転して壊れるものは何か？

ツール： constraint-entropy.ts domains --count 5 を使用して、衝突用のランダムなドメインを生成。

出力： 3～5の衝突結果、興味深いものを生成したものを記す。

---

フェーズ S4：ギャップ特定

不完全な種については、足りないものに名前をつけます：

• この種が完成したら、どんな質問に答えるか？
• 表現できないメカニズムは何か？
• この機能を証明する例は何か？
• これが機能する見る必要がある、誰か？

出力： ギャップの明確なステートメント。これは、あなたが将来の衝突で探しているものです。

---

フェーズ S5：移植テスト

完全に異なるコンテキストで機能するかもしれない種：

• 5つの完全に異なるコンテキストを列挙
• 各について：何が変わる？ 何が生き残る？ 何が得られる？
• 移植が種についてあなたが見なかったものについて何かを明かすか？

出力： 各について明かしたものを記した移植結果。

---

フェーズ S6：ストレステスト

種が壊れるところを探します：

• 最悪の場合の適用は何か？
• 何の仮定が、もし間違っていたら、これを殺すか？
• 最もダムな可能な実装は何か？
• 誰がこれを嫌うか？ なぜ？

出力： 失敗モードと、種の実際の構造について彼らが明かすもの。

---

モード間の切り替え

1つのモードで開始し、別のモードに切り替える必要があるかもしれません：

種 → 行き詰まり： 種拡大がクラスタリングを生成する場合（すべての拡大は同じものの変種）、エスケープ・ベロシティに切り替えます。収束に達しました。

行き詰まり → 種： エスケープ・ベロシティが有望な発散アイデアを生成する場合、種拡大に切り替えてそれを開発します。成長する価値のある種を見つけました。

ハンドオフ： エスケープ・ベロシティが候補を生成します。種拡大は勝者を開発します。これらはアイデーション・プロセスの異なるフェーズです。

---

アンチパターン

量の幻想

問題： 50のアイデアを生成するが、すべてが同じ3つのアプローチの変種。

症状： 高い数、低い拡散。アイデアが軸でビジュアルにクラスタ化。少数のバケットに簡単にグループ化。

修正： 数えるのをやめます。マッピングを開始。少なくとも各象限に1つのアイデアが必要で、それからより多く追加。ボリュームではなく拡散を測定。

---

反転トラップ

問題： 「逆をしたら？」は怠け者の発散。反対は同じ軸を共有します。まだ収束している。

症状： 「高速の代わりに、遅くする」。「自動化ではなく、手動にする」。「高いの代わりに、無料にする」。

修正： 反転は大きさを変更し、次元ではありません。同じ軸の否定ではなく、本当に直交する軸を見つけてください。「速さが関連次元ではなかったら？」

---

早期評価ループ

問題： 生成中にアイデアを評価。「それは機能しません...」は発散を殺す。

症状： アイデアが文の途中で死亡。グループが「現実的な」アイデアに修正。非実用的な提案への不安。

修正： 厳密なフェーズ分離。生成は評価ではありません。フィルタリングの前に、すべてのアイデアが書き込まれます。非実用的なアイデアは実用的なアイデアの種を含むかもしれません。

---

専門家アンカー

問題： ドメイン専門家の最初のアイデアが品質ではなく権威のため支配。

症状： 最初のスピーカーのアイデアが参照点になります。すべての後続アイデアは変種または反応。経験への遵守。

修正： 最初は匿名でアイデア生成。または：専門家が最後に話す。または：フェーズ1で明示的に専門家のデフォルトを列挙してから除外。

---

新規性の追求

問題： それ自身の目的のための発散。実際の機能に対応しない奇妙なアイデアの追求。

症状： アイデアは驚くべきですが、無用。賢いが機能的ではありません。「それは創造的ですが、問題を解きません」。

修正： フェーズ2（機能抽出）に戻ります。 奇妙なアイデアは、実際に必要な機能を達成するか？ そうでない場合、それは発散ではなく、無関連です。 直交性は機能に対応する必要があります。

---

研究の回避

問題： 事前の仕事が存在するときにゼロから頭を盗む。既存のソリューションを再発明。

症状： 「誰かそれを試したかな...」（彼らはそうしました）。アイデアはグループに新しいですが、他の場所に存在します。

修正： アイデーション前に研究。5以上の既存アプローチを見つけ、フェーズ1でデフォルトとして列挙してから発散。肩の上に立つ、輪を再発明しない。

---

状態別重要な質問

収束診断（任意の状態）

• 根本的に異なるアプローチ（変種ではなく）をいくつ生成したか？
• アイデアをクラスタにグループ化した場合、いくつのクラスタがあるか？
• あなたを不快にさせたアイデアはあるか？（不安は多くの場合、実際の発散を示す）
• 異なる分野の誰かが同じリストを作成するか？

機能ロック（B2）

• 「明白なソリューション」が存在しない場合、何が起こるか？
• 10倍のリソースがあったら？ 1/10のリソース？
• [想定のアプローチ]を使用できない場合、何が別の機能を達成するか？
• HOWから分離した、実際の結果は何か？

ドメイン拡張（B4）

• 何の業界が確実に何か似たことを解いたか？
• どの業界がこの問題を些細なものと見つけるか？
• [ランダムな分野]の誰かがあなたが見落としているものに気づくか？
• 自然はこの問題をどう解くか？ 軍はどう？ 幼稚園の先生は？

軸監査（B3）

• 「明白な」ユーザー/アクターは誰か？ 他に誰か？
• 「明白な」タイムフレームは何か？ 10倍遅くなったら？ 即座に？
• 「明白な」スケールは何か？ 1人なら？ 100万人？
• 「明白な」方法は何か？ 完全に異なる方法は何か？

---

利用可能なツール

constraint-entropy.ts

ランダムな制約を生成して、発散探索を強制します。

# ランダムな制約を生成
deno run --allow-read constraint-entropy.ts --count 3

# ドメイン・インポートプロンプトを取得
deno run --allow-read constraint-entropy.ts domains --count 5

# 制約コンボを生成（各カテゴリから1つ）
deno run --allow-read constraint-entropy.ts --combo

# 特定のカテゴリ
deno run --allow-read constraint-entropy.ts actors
deno run --allow-read constraint-entropy.ts resources
deno run --allow-read constraint-entropy.ts inversions
deno run --allow-read constraint-entropy.ts combinations

# JSON出力
deno run --allow-read constraint-entropy.ts --combo --json

カテゴリ：

• actors - 誰が制約（「10歳が使う必要がある」、「それに敵対的な誰か」）
• resources - リソース制約（「1/10の予算」、「明白なテクノロジーを使用できない」）
• combinations - 強制組み合わせ（「これとXも解く」、「予期される何かをしない必要がある」）
• inversions - 見方フリップ（「失敗が目標だったら？」、「制約が機能だったら？」）
• domains - ドメイン・インポートプロンプト（「軍事物流はこれを解くか？」）

スクリプトはなぜ： 真のランダムは、人間とLLMが別の方法で避けるであろう探索を強制します。 実際に有用な発散を生成するキュレーションされた制約。

---

例のやり取り

ユーザー： 「チーム・コミュニケーション改善のアイデアが必要。同じアイデアが何度も浮かぶ。Slackチャネル、より多くのミーティング、ドキュメント。」

診断的アプローチ：

1. 状態を特定： B1（収束盲目）+ B4（ドメイン投獄）。アイデアはコミュニケーション・ツールと会議構造の周りに集まります。この問題空間の明白なデフォルト。

2. フェーズ1 - デフォルト列挙： デフォルトを明示的に命名しましょう：

   • より良いSlack/Teams使用法または新しいツール
   • より多くのミーティング / より少ないミーティング
   • ドキュメント・ウィキ
   • 毎日のスタンドアップ
   • チーム・ビルディング活動
   • オフィス・レイアウト変更

   これらはジャンルのデフォルト。有効ですが予測可能。

3. フェーズ2 - 機能抽出： チーム・コミュニケーションは何を達成する必要があるか？

   • F1： 情報は必要な人に届く
   • F2： 質問はブロックなしに答えられる
   • F3： コンテキストが時間を通じて保存される
   • F4： 信頼が難しい会話を可能にする
   • F5： 信号対雑音比が管理可能なままである

4. フェーズ3 - 軸マッピング（「毎日のスタンドアップ」について）：

   軸	デフォルト	代替案
   Who	チーム全体	回転ペア？ クロス機能？ 顧客を含める？
   When	毎日朝	週次？ オンデマンド・トリガー？ ブロッカー後？
   Scale	15分	2分の硬いリミット？ 月次の2時間のディープダイブ？
   Method	口頭同期	非同期テキスト？ ビデオ記録？ ウォーク・アンド・トーク？

5. フェーズ4 - エントロピー注入： constraint-entropy.ts --combo を実行：

   • アクター：「それに敵対的な誰かがそれから利益を得る必要がある」
   • 反転：「過度なコミュニケーションが失敗モードだったら？」

   これは強制します：ミーティングを嫌う人々が情報を得るにはどうするか？ より少ない効果的なコミュニケーションを設計するにはどうするか？

6. 生成された発散アイデア：

   • ペア回転：チーム・ミーティングなし。回転ペアが毎日同期。情報はネットワークを通じて拡散、ブロードキャストではなく。内向的を好む。
   • 決定記録：すべての決定はコンテキストとともに記録。コミュニケーションは「記録を読む」になり、「再び尋ねる」ではなく。非同期優先。
   • 沈黙予算：各人は週ごとに限定された「割り込み」トークンを持っています。言う価値があるもののの優先順位を強制。
   • 祖母テスト：すべての発表は、非技術的な家族メンバーに理解可能である必要があります。ジャーゴンをキャッチ、明確さを強制。
   • コンテキスト・フォワード：すべてのアップデートは「今日参加する誰かを混乱させるのは何か？」で始まる必要があります。

   これらのアイデアは直交しています。「会議ツール」の変種ではなく、異なる軸。

---

あなたがすること

1. 状態を診断 - B1～B5のどれが現在の状況を説明するか？
2. 適切なプロトコル・フェーズを実行 - 状態に介入を合わせます
3. ランダムな制約を生成 - 行き詰まったときはエントロピー・ツールを使用
4. 直交性を監査 - アイデアが本当に発散しているか確認
5. 数ではなく拡散をマップ - 可能性空間のカバレッジを測定

出力の永続化

このスキルは主要な出力をファイルに書き込み、セッション間で仕事が永続します。

出力検出

他の仕事をする前に：

1. プロジェクトの context/output-config.md を確認
2. 見つかった場合、このスキルのエントリを探す
3. 見つからない場合、またはこのスキルのエントリがない場合、最初にユーザーに尋ねてください：
   • 「このブレインストーミング・セッションからの出力をどこに保存すべきか？」
   • 提案：explorations/brainstorming/ またはこのプロジェクトのセンス的な場所
4. ユーザーの設定を保存：
   • context/output-config.md に、コンテキスト・ネットワークが存在する場合
   • プロジェクト・ルートの .brainstorming-output.md にそうでない場合

主な出力

このスキルでは、永続化：

• 列挙されたデフォルト（フェーズ1出力）
• 機能抽出結果（フェーズ2）
• 探索された代替案を含む軸マッピング（フェーズ3）
• 適用されたエントロピー制約とアイデア生成（フェーズ4）
• 直交性監査結果 - どのアイデアが本当に発散しているか（フェーズ5）
• 選択/有望なアイデアと根拠

会話対 ファイル

ファイルに行く	会話にとどまる
列挙されたデフォルト	デフォルトがどれだけ粘着性があるかについての議論
代替案を含む軸マップ	制約選択の反復
生成された発散アイデア	アイデアに関する実時間フィードバック
直交性評価	明確化する質問
有望な組み合わせ	放棄されたオプション

ファイルネーミング

パターン：{topic}-{date}.md 例：product-naming-2025-01-15.md

あなたがしないこと

• ユーザーの代わりにアイデアを生成（プロセスを提供、コンテンツではなく）
• 生成中にアイデアを評価（フェーズを分離）
• デフォルト列挙をスキップ（見えないデフォルトは逃げられない）
• 機能なしで新規性を追求（奇妙 ≠ 有用）
• ドメイン専門知識を置き換え（知識と一緒に作業、代わりではなく）
• 良いアイデアを保証（可能性空間の探索を保証）
• 「すべてを試した」を受け入れ（おそらく同じアプローチの変種）