brainstorming

何かを作る前です。説明文が強い言い方をしています。

創造的な作業の前には必ずこれを使わなければならない。機能を作る、部品を組む、機能を足す、挙動を変える、新しいことを計画する。

対象はソフトウェアに限りません。説明文は、講演、事業、改装も例に挙げています（2026-10-23 確認）。

前提は「作り手の思い込みは薄い」

本文の冒頭はこういう考え方です。エージェントは作るのが得意で、相手が欲しいと信じたものを作る。ただ、その信じ込みは感じているより薄いことが多い。

だから作る前に、相手が本当に欲しいものと、その理由を見つけます。理由が分かれば、相手が口にしない細かい判断を、相手がしたであろうように下せる、という立場です。

最初に「何が分かっているか」を自問する

返事をする前に、相手が欲しいものとその理由について、何が分かっているかを自分に問います。

実装の前に、4 つを順に済ませる

すぐ済む作業でなければ、実装に入る前にこの順で進めます。

1. 案を並べる作り方の案を、ほかに何も入れない 1 通で出し、相手に 1 つ選んでもらう
2. 設計書を書く小さな変更なら短いもの、案件なら完全なもの
3. 承認をもらうその設計書を相手が承認する
4. 計画へ渡すwriting-plans を呼ぶ

相手がうなずいた試作と、質問を断られたあとに依頼どおりこなすことは、実装に数えません。

聞く前に、まず読む

既存のプロジェクトがあるとき、または仕様・計画・引き継ぎ・指されたファイル・それまでの会話のような文脈を渡されたときは、最初のメッセージより前に読み込みます。関係する部分が今どう動いていて、この変更が何に触れるかを説明できるまで読み続けます。プロジェクトや文脈がすでに答えていることは聞きません。

最初のメッセージは、依頼の具体さで 2 通り

作り方の話はまだしません。本文は、仕様は不完全なことが多いので、その上に作る前に確かめよ、と書いています。

終わり方は、相手が brainstorming を求めたかどうかで変わります。名指しや呼び出し、設計の相談として求められたなら、質問で終えます。求められていなければ、質問のあとに「すぐ取りかかってほしければそう言ってください」のような軽い 1 行を添えます。

飛ばすと言われたら、スキルはそこで終わりです。プラットフォーム・言語・媒体のような作り方の大きな選択を 1 行で述べてから、通常の流れで依頼をこなします。

会話の決まり

• 各メッセージは質問 1 つで終える。答えの例の一覧をぶら下げない
• 平易な言葉で、相手より少しだけ上の水準で話す。相手の語彙に合わせ、手順の専門用語を使わない。このスキルの文面を相手に引用する必要はない
• まず相手に語ってもらう。選択肢を出すのは相手が行き詰まったときだけ
• 「適当に決めて」「どう思う？」と言われたら、具体的な案を出す
• 調べた結果を報告するときは、大事なものを先に出し、残りは申し出るにとどめる

作り方の選択を、誰が決めるか確かめる

どの案件も、媒体・道具・材料・資源の選択の上に立っています。アプリならプラットフォーム、プログラミング言語、ライブラリです。

どれを相手が自分で決めたく、どれを任せてくれるのか、何をすでに持っているのかを早めに確かめます。既存の作業があれば、それが使っているものの上に作ります。自分で決めたことは、設計に「自分の判断」として書きます。相手が同意したことにはしません。

押さえる範囲は 6 つ。ただし台本ではない

• 何かどんな種類のものか、何が特別か
• なぜ今なぜ今か、相手にとっての成功とは何か
• 目標目標・非目標・反目標（技術的には動いても失敗になるもの）
• 先行例よそで見て気に入ったもの、嫌ったもの
• 現状今あるもの、すでに試したこと
• 細部相手がこだわる細部

本文は「これを質問として読み上げるな」と書いています。聞く順番の台本ではなく、会話でカバーすべき範囲です。

質問は具体に、案は別のメッセージで並べる

質問は相手のプロジェクトと、相手が話したことに合わせます。鋭い同僚のように、前の答えや自分が見つけたことの上に次の質問を立て、相手が見落としていそうな帰結や場合を考えさせます。本文の例は「投票は会議の前に締め切られ、今月 2 人が入会した。途中で入った人に票はあるか」です。理由が明らかでなければ、何を知りたいのか、答えで何が変わるのかを言います。直せる提案に理由を添えるほうが、質問より効くことが多いとしています。

ある程度掴めたら、下調べを申し出ます。相手のコードベースやプロジェクトの奥、相手のファイルやデータ、ウェブを見に行く。何を探すかを言い、行くかどうかは相手が決めます。

欲しいものが分かったら、何かを書き上げる前に、作り方の案をほかに何も入れない 1 通で出します。本当の代替案をいくつか考え、弱いもの、相手の「なぜ」に逆らうもの、既存の作業が許さないものを落とします。残った 2〜3 個を、プロジェクトが実際にしていることに即して示し、それぞれが引き換えにするものを言います。1 つを理由とともに勧め、どれで行くかを聞きます。筋の通る道が本当に 1 つなら、そう言って、ほかが合わない理由を説明します。

案を並べるのは作り方についてだけです。何が欲しいかは、まず相手に語ってもらいます。

見せる、試作する

読むより見たほうが分かるときは、視覚的な相棒（ブラウザのタブ）を申し出ます。本文が挙げる場面は 5 つです。見るもの（画面・ページ・印刷物・看板）、配置（画面・部屋・予定）、流れや手順、見た目の違う選択肢、図や年表や地図のように見たほうが分かる構造。

試作（spike）も勧めています。「エージェントの作業は滝型だが、とても、とても速い」。使い捨ての試作が、欲しいものや実現性を知る一番安い方法であることが多い、という考えです。

試作はテストなしか最小限で、頑丈ではなく、計画・実装・見直しの流れを飛ばします。相手がただ試作したいだけなら、邪魔をしない。試作から学んだことは会話に持ち帰ります。

進めながら書き返す

一部分を説明できるほど理解したら、その部分を 200〜300 語で書き返し、次の部分の質問に戻ります。書き返しと質問を、会話の最後まで交互に続けます。

相手が言ったことだけを相手のものとして書き、自分が埋めたことは理由を添えた自分の提案として書きます。各まとまりの最後に、何が違うか、何が足りないかを聞きます。書き返す中身が画面や予定表のような「見るもの」で、まだ相棒を申し出ていなければ、先に申し出を送ってまとまりは次に回します。

作業の大きさは 2 つ。どちらも設計書を書く

相手の欲しいものが分かり、作り方の案を選んだら、大きさを平易に言います。相手は上書きできます。

短くても完全でも、設計書には案の部を置きます。検討した 2〜3 の作り方、それぞれが引き換えにするもの、相手が選んだものとその理由です。選ぶのは会話の中で、設計書を書く前です。

依頼に大事なことが全部ある、すぐ済む明確な作業はこの表の外です。やって、何をしたかを言います。

途中で大きくなったら、止まって、そう言って、一段上げます。実は独立した複数の案件なら、そう言って順番を決め、1 つずつ進めます。

設計書と「作り手の確認」

設計書は、その分野の有能な作り手が、相手に聞き直さずに計画を立てられる平易な文書です。中身は 6 つ。意図と理由、目標・非目標・反目標、制約、案（上）、相手が決めた作り方（決めたとおりに）、作り手に任せる部分です。

小さな変更の短い設計書は、同じ項目を 1〜2 行ずつ書き、作り手の確認を通さずに相手へ渡します。

案件の設計書は、新しいサブエージェントに作り手として読ませます（2026-10-23 確認）。

1. 予告する書き上げると伝えるときに、見直し役が先に読み、質問を持って 1 度戻るかもしれないと言う
2. 作り手に読ませる同梱の builder-check-prompt.md で新しいサブエージェントを送る。確認が戻るまで文書を渡さない
3. 3 つに仕分ける答え済み（文書に答えを入れる）、小さい（自分で決めて「自分の判断」と記す）、相手のもの（相手しか答えられず、作るものが変わる）
4. 相手に聞く「相手のもの」を重要な順に 1 通にまとめて聞く
5. 渡す答えを文書に入れ、自分が下した判断の短い一覧を添えて渡す

この確認が生む質問は、この 1 回だけです。サブエージェントの道具が無ければ、自分がその作り手になって読みます。同梱の指示文は、作り手に「推測が外れると困る点」だけを重要な順に挙げさせ、無ければ「nothing important left」と返させます。

承認の関門

本文には <HARD-GATE> という札で囲まれた段落があります。

例外は 2 つです。質問を断られたらスキルは終わり、関門もなくなります。相手がうなずいた試作は作ってよいが、使い捨てのまま。その成果を残すのは新しい依頼で、関門を通り直します。

設計書が承認されたら、次は計画です。writing-plans を呼び、ほかのスキルは呼びません。

合理化の言葉を 6 個潰している

同じ公開元の他のスキルと同じ作りです。

視覚的な相棒は、その場で申し出る

先回りして申し出ません。上の 5 つの場面が初めて出たときに、ほかに何も入れない別のメッセージで申し出ます。断られたら文章のまま続け、相手が言い出さない限り二度と申し出ません。

相棒は道具であってモードではない、とも書かれています。受け入れても、すべての質問がブラウザに行くわけではありません。画面の下書き・配置・図・並べた案はブラウザで、要件・範囲・利害・概念の選択は文章で。UI の話題の質問が、自動的に「見せる質問」になるわけではありません。

すでに設計が決まっているなら飛ばせる

仕様から計画に落とすなら writing-plans が直接の担当です。大事なことが依頼に全部あるなら、このスキル自身も「やって、何をしたかを言う」だけで済ませます。

不具合の調査には向かない

そちらは systematic-debugging で、あちらは根本原因を突き止めるまで修正させません。

人が応答できない状況では進まない

承認の関門があり、会話は質問と書き返しを交互に重ねる作りです。無人で完走させる設計ではありません。

設計を絞り込みたいだけなら別物

grilling は決定の木を辿って質問を束ねます。このスキルは相手に語ってもらい、作り方の案は別の 1 通で選ばせる側です。

「とりあえず動かして」なら最初に断ればよい

brainstorming を求めていない依頼では、最初のメッセージに「すぐ取りかかってほしければそう言って」の 1 行が付きます。そう答えればスキルはそこで終わり、作り方の大きな選択を 1 行で述べてから作業に入ります。自分から brainstorming を求めた場合はこの 1 行は付かないので、自分から言い出してください。試作だけしたいときも、本文は邪魔をするなと書いています。

設計書をファイルに書き、コミットする

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 7 件です（2026-10-23 確認）。

ただし設計書は、ソフトウェアのリポジトリなら docs/superpowers/specs/ に保存してコミットします。置き場所の決まりは、小さな変更の短い設計書と案件の設計書を分けていません。それ以外の場所では置き場所を聞きます（スキルを入れる前に確認すること）。

やり取りが増える

質問は 1 回に 1 つ、書き返しは 200〜300 語ずつ、作り方の案は別の 1 通、そのうえ案件の設計書には作り手の確認が入ります。時間が限られているなら、最初に「質問を飛ばして」と答えるか、小さな変更として扱うよう伝えてください。大きさは相手が上書きできます。小さな変更でも、短い設計書の承認は求められます。

大きさは途中で上がる

設計書の見直しにサブエージェントを使う

案件の設計書は、渡す前に新しいサブエージェントが作り手として読みます。その分の時間と利用量がかかり、確認が戻るまで文書は渡されません。

「視覚的な相棒」はブラウザのタブを開く

承認すると開く形ですが、何が開くかは先に確認してください。

同梱の手引き（visual-companion.md）によると、同梱のスクリプトで手元に小さなサーバーを立て、URL に付いた鍵がないと画面を読めない作りです。プロジェクトの場所を渡すと画面の下書きは .superpowers/brainstorm/ に残るので、.superpowers/ を .gitignore に足すよう利用者に促せ、とあります。

ライセンス

MIT。再配布や商用利用の前に公開元の表記を確認してください。

小さな変更でも承認が要りますか

要ります。関門は設計書の承認で、小さな変更なら短い設計書がその対象です。ただし、大事なことが依頼に全部あるすぐ済む作業は、やって、何をしたかを言うだけです。最初に質問を断った場合も、関門はなくなります。

質問を飛ばしてすぐ作らせることはできますか

できます。brainstorming を求めていない依頼なら、最初のメッセージに、すぐ取りかかってよいという 1 行が付きます。そう答えるとスキルはそこで終わります。プラットフォームや言語のような作り方の大きな選択を 1 行で述べてから、通常の流れで依頼をこなします。

作業の大きさはどう決まりますか

相手の欲しいものが分かり、作り方の案を選んだ段階で、エージェントが小さな変更か案件かを平易に言います。相手はその判断を上書きできます。依頼に大事なことが全部ある、すぐ済む明確な作業は、会話を始めずにそのままこなします。

途中で大きさが変わりますか

大きくなったら上がります。止まって、そう言って、一段上げる、と本文にあります。実は独立した複数の案件だったと分かれば、順番を決めて 1 つずつ進めます。

設計書はどこに保存されますか

ソフトウェアのリポジトリなら docs/superpowers/specs/YYYY-MM-DD-<主題>-design.md に保存され、コミットされます。それ以外は置き場所を聞き、相手の好みがどちらにも優先します。

承認されたあとは writing-plans へ引き渡されます。

対応しているエージェントはどれですか

Claude Code と Codex です。公開元は群の入口（using-superpowers）に実行環境ごとの補足ファイルを置き、writing-skills では Claude Code・Codex・Copilot CLI・Gemini CLI の置き場所まで書き分けています。

当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。