brainstorming

brainstormingスキルの概要

brainstormingスキルは何のためのものか

brainstormingスキルは、ざっくりしたアイデアを、コードを書き始める前に承認済みの設計へ落とし込むための、構造化された実装前ワークフローです。抽象的に「アイデアを出す」こと自体が主目的ではありません。先にスコープ、前提、要件、設計上の判断を表に出すことで、手戻りを減らすのがこのスキルの役割です。

どんな人がbrainstormingスキルを入れるべきか

このbrainstormingスキルは、「Xを作るべきだ」と思った瞬間にそのまま実装へ飛びがちな人に特に向いています。とくに有効なのは次のような場面です。

• 機能企画
• コンポーネント設計
• 挙動変更の検討
• 社内ツールの提案
• Requirements Planningのためのbrainstorming

すでにしっかりした仕様策定プロセスがある場合でも、このスキルはその前段に置く軽量な入り口として役立ちます。

通常のプロンプトと何が違うのか

最大の違いは、SKILL.md にある明確なハードゲートです。設計を提示して承認を得るまでは、agent は実装・スキャフォールド・コード生成をしてはいけません。単純に見えますが、これは挙動に大きく効きます。通常の「これを作るのを手伝って」というプロンプトでは、assistant がそのまま解法に飛びつきがちだからです。

インストール前に実際に気になるポイント

多くの人がまず短時間で知りたいのは、だいたい次の3点です。

1. 作業が遅くならないか
2. ありきたりではなく、役に立つ質問をしてくれるか
3. ビジュアルデザインの検討にも使えるか

答えとしては、このスキルは意図的にプロセス上のひと手間を追加します。ただし、アイデアが小さければその負荷も小さく収まります。さらにこのスキルは、「簡単そうな作業」でも短い設計確認を入れるべきだと明示しています。高くつくミスの原因になる隠れた前提は、まさにその段階で表面化することが多いからです。

brainstormingスキルの使い方

brainstormingのインストールと初期セットアップ

リポジトリからスキルを追加するには、次を使います。
npx skills add https://github.com/obra/superpowers --skill brainstorming

インストール後は、まず次のファイルを確認してください。

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

ビジュアル検討も想定しているなら、あわせて次も見ておくとよいです。

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

brainstormingスキルが前提にしている基本ワークフロー

このbrainstormingスキルの使い方には、はっきりした流れがあります。

1. プロジェクトの文脈を把握する
2. 必要なら visual companion を提案する
3. 確認質問を一度に一つずつ行う
4. 設計案を統合してまとめる
5. 明示的な承認を得る
6. その後ではじめて計画または実装に進む

agent がアイデアからいきなりコードに飛ぶなら、その時点でこのスキルに沿っているとは言えません。

brainstormingをうまく使うために渡すべき入力

このスキルは、機能名だけを渡すよりも、もう少し情報があるほうがきちんと機能します。よい出発点には、通常次のような内容が含まれます。

• 解決したい問題
• 想定ユーザー
• 現在のシステムや repo の文脈
• 制約
• 何をもって完了とするか
• 既知の non-goals

弱い入力例:

Add notifications.

強い入力例:

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

後者のように書くと、brainstormingスキルがより鋭い追加質問をしやすくなります。

ラフなアイデアを強い最初のプロンプトに変える方法

brainstorming向けの実用的なプロンプトテンプレートは次のとおりです。

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

これはこのスキルが想定する流れに合っており、質問が汎用的すぎるものになるのを防ぎやすくします。

確認質問はどう進むべきか

見落とされがちですが重要なのが、質問は一度に一つずつ行う前提だという点です。これは、ある回答によって次に聞くべきことが変わるからです。もし agent が最初から15個まとめて質問してきたら、このbrainstormingガイドが意図している対話的な絞り込みが失われます。

visual companionを使うべき場面

このリポジトリには、ブラウザベースの visual companion が含まれています。次のように、見せたほうが選択肢を理解しやすい場面で使うのが効果的です。

• ワイヤーフレーム
• レイアウト比較
• UIフロー
• アーキテクチャ図
• 状態や関係性の可視化

UIに触れているという理由だけで使う必要はありません。たとえば「これは wizard にすべきか modal にすべきか」のような概念的な問いならテキストだけでも十分です。一方で、「この2つの wizard レイアウトのどちらがより分かりやすいか」のような問いは、ビジュアル経路と相性がよいケースです。

visual companionは実際にはどう配信されるか

この visual helper は単なる説明用ドキュメントではなく、ローカルセッションを立ち上げるためのスクリプトも用意されています。

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh はランダムな高位ポートでローカルサーバーを起動し、セッションファイルを /tmp 配下、または .superpowers/brainstorm/ のようなプロジェクトディレクトリ内に保存できます。モックアップをセッション間で残したい場合に便利です。

visualsを前提にする前に知っておきたい実用的な環境メモ

ビジュアルワークフローは、ブラウザからアクセスできる環境を前提にしています。remote container、VM、SSH ワークフローで使うなら、次の点を必ず確認してください。

• --host
• --url-host
• セッションディレクトリの永続化

ローカル限定ならデフォルト設定で扱いやすいです。共有環境やリモート環境で使う場合は、ブラウザフィードバックを前提に組み込む前に、ネットワーク周りを先に設計しておくべきです。

すばやく使い始めるためのおすすめファイル確認順

最短距離で実運用レベルの使い方をつかみたいなら、次の順で読むのがおすすめです。

1. 挙動上の契約を確認するための SKILL.md
2. ブラウザ支援が有効な場面を把握するための visual-companion.md
3. 「実装に進める十分な状態」とは何かを見るための spec-document-reviewer-prompt.md
4. ビジュアル経路が必要な場合の scripts/start-server.sh

この順なら、まず判断ロジックを押さえ、そのあとで必要に応じて補助ツールへ進めます。

brainstormingのよい出力はどんな形か

成功したbrainstormingセッションは、レビュー可能な具体性を持った設計で終わるべきです。たとえば次の内容が含まれている状態です。

• 目的とユーザー
• スコープの境界
• 主要な判断
• 未解決のリスクや前提
• 実装計画に移れるだけの具体性

出力が単なるアイデアの箇条書きで終わっているなら、そのセッションは早い段階で止まりすぎています。

Requirements Planningのためにbrainstormingを使う方法

Requirements Planningのためのbrainstorming では、このスキルを仕様化前のステップとして使います。

1. 問題と制約を明確にする
2. 設計または要件の骨子を作る
3. 承認を取る
4. spec を書く
5. 必要に応じて spec reviewer prompt template を回す

これはこのスキルの特に強い使い方のひとつです。計画が固まる前に、スコープのぶれや曖昧さを拾えるからです。

brainstormingスキル FAQ

brainstormingスキルは大きな案件にしか向きませんか？

いいえ。このスキルは、「小さい作業なら設計を飛ばしてよい」という考え方を明確に退けています。ごく小さな変更なら設計自体は短くて構いませんが、設計ステップそのものは依然として重要です。むしろ価値が高いのは、簡単そうに見える変更で前提が検証されないまま進みがちな場面です。

ふつうの brainstormingプロンプトより優れていますか？

多くの場合は yes です。特に、欲しいのがアイデア数ではなく、実行に移せる明確さである場合はそう言えます。通常の brainstormingプロンプトは多数の選択肢を出すのには向いています。一方、このbrainstormingスキルは、文脈を理解し、選択肢を絞り、承認可能な設計に収束させたいときに向いています。

brainstormingスキルは初心者にも使いやすいですか？

はい。特に、まだ計画の型を持っていない個人開発者やソロビルダーに向いています。この構造は、要件やトレードオフを確認しないまま最初に思いついた案を実装してしまう、ありがちな初学者のミスを補ってくれます。

どんなときにbrainstormingは不向きですか？

次のような場合は、使わないか、かなり短縮してよいです。

• 作業が純粋に機械的で、すでに完全に仕様化されている
• 設計や挙動の判断を伴わない
• ユーザーがすでに詳細な spec を承認していて、あとは実行だけでよい

それでも、ハードゲートが自分のワークフローと衝突しないかは確認してください。このスキルは意図的に厳格です。

このスキルはコードを生成しますか？

いいえ。そしてそれは意図的です。brainstormingスキルは、承認が与えられるまでは実装の手前で止まる前提です。コード生成が必要なら、まずこのスキルで設計を固め、承認後に planning か implementation のスキルへ引き継ぐのが正しい使い方です。

visual companionは必須ですか？

いいえ。ブラウザ経路はオプションです。テキストだけのbrainstormingでも、要件整理、スコープ設定、技術的トレードオフの議論では価値の大半を得られます。ビジュアルツールが最も効くのは、判断対象そのものが視覚的な場合です。

brainstormingスキルを改善する方法

brainstormingスキルに、より豊かなプロジェクト文脈を渡す

結果を最も手早く改善する方法は、議論を現実の文脈にしっかり結びつけることです。

• 関連するファイルやフォルダ
• 現在の挙動
• 最近の変更
• 既知の技術的制約
• 影響を受けるユーザー

このスキル自体も、まずプロジェクト文脈を探索するよう agent に指示しています。その文脈がどこにあるかをこちらから示すことで、精度が上がります。

制約とnon-goalsを早い段階で明示する

弱いbrainstorming出力の多くは、境界条件の指定不足から生まれます。このスキルには、何を守るべきか、何を避けるべきかを先に伝えてください。

• 後方互換性
• パフォーマンス上限
• コンプライアンスやセキュリティ要件
• 期間や人員の制限
• 明示的にスコープ外とする機能

こうすると、より狭く、意思決定に使いやすい設計が出やすくなります。

アイデア集ではなく設計を求める

実装に進める出力がほしいなら、そう明言してください。brainstormingスキルに、最後は次を含めて終えるよう求めます。

• 提案設計
• 前提
• 未解決の論点
• 明示的な承認チェックポイント

これで、終わりのない発想出しではなく、使える成果物へ向かってセッションを進めやすくなります。

visual brainstormingでは、より強いプロンプトを使う

ビジュアル作業では、単に「show mockups」とだけ言わないでください。何を比較したいのかまで指定するのが大事です。

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

この種のプロンプトなら、visual companion も、飾りとしての画面ではなく、判断に使える出力を作りやすくなります。

最大の失敗パターンは、早すぎる解決策への飛びつき

もっとも多い失敗は、問題理解が十分でないうちに実装の話へ入ってしまうことです。そうなったら、次のようにセッションを戻します。

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

これで、このbrainstormingガイドを本来の目的に引き戻せます。

最初の出力は、1回のレビューで磨く

最初の設計が出たあとにやるべきなのは、最初からやり直すことではなく、焦点を絞った改訂依頼です。

• どこが曖昧か
• どこが過剰設計か
• 実装計画の妨げになる点は何か
• 承認に足りないものは何か

ここでは、リポジトリ内の spec-document-reviewer-prompt.md が役立ちます。見た目の修正ではなく、実際に計画を止める要因に合わせてレビュー基準をそろえられるためです。

brainstormingの成果物は小さくても、判断に必要な情報は欠かさない

よくあるミスは、不要な詳細で設計を膨らませすぎることです。よいbrainstormingは、長いbrainstormingではありません。単純な作業なら、目的、スコープ、制約、アプローチ、承認を数段落でコンパクトに押さえるだけでも十分です。基準は文書の長さではなく、次の工程がより少ない推測で進められるかどうかです。

brainstormingをspecレビュー工程と組み合わせる

このスキルを本格的に使うなら、作成した spec や設計に対するフォローアップレビューもセットで運用すると効果的です。付属の reviewer template では、次の点を確認できます。

• placeholders
• contradictions
• 曖昧な要件
• 広すぎるスコープ
• 求められていない複雑さ

こうすることで、brainstormingスキルは単なるチャット上の補助ではなく、実際のデリバリーワークフローに組み込めるものになります。