brainstorm について
不確実な状況を判断や焦点を絞った実験につなげる、協働ブレインストーミングのスキルです。選択肢を比較し、重要な前提を検証して、判断の理由を記録します。
主な機能
- 01状況に合った探索方法を選択
- 02過去の作業を踏まえて問いを整理
- 03トレードオフと不確実性を比較
- 04的を絞った実験で前提を検証
- 05判断と根拠を記録
活用シーン
- 01異なる製品の方向性を検討
- 02重要な実現可能性の前提を検証
- 03トレードオフを踏まえて案を選択
- 04修正案の前に原因を診断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/brainstormを入力して読み込まれたか確認します。
同梱ファイルreferences/evidence.md
詳細
共同ブレインストーミング
不確実性を、役立つ選択肢や焦点を絞った実験に変えます。
ユーザーの指示はこのスキルより優先されます。既存の許可は引き継ぎ、承認の手順を新たに追加しないでください。
作業の進め方を選ぶ
| 状況 | 役立つ成果物 |
|---|---|
| ユーザーが自由な探索を望んでいる | 明確に異なる方向性、具体的なトレードオフ、未解決の問い |
| 問題は明確だが、仕組みが不明 | 推奨案と、その判断を覆す証拠 |
| ある前提が実現可能性を左右する | 設計に進む前に、その前提を小規模に検証する |
| アプローチが選ばれ、実装が許可されている | 実装に進む |
| ユーザーが何かの原因を尋ねている | 修正を設計する前に原因を診断する |
問いを明確にする
インストール済みの Sibyl スキルが設定されている場合は、それを使って過去の決定を確認し（sibyl context "<decision>" --intent plan）、返された変わりやすい主張を再確認します。別案を出す前に、最も近い既存の事例と過去の作業を探します。
好みを具体例や観察可能な事実に置き換えます。「滑らかに」なら、どの操作でどの程度の遅延が見えるのかを特定します。「美しく」なら、参考資料を調べ、残すべき構図、動き、タイポグラフィを明らかにします。指標が体験を表す場合は定量化が役立ちますが、代理指標で体験そのものを置き換えることはできません。ユーザーが提示した参考資料は仕様です。解釈を加える前にそれに合わせ、動かせるコンセプトなら、実際に動く様子を示します。
ユーザーの見立ては仮説として扱います。決定的な確認によって、その一部が裏付けられ、残りが否定されることもあるため、両方を報告します。明示的な「X を使う」という指示を、くだけた書き方だからという理由で単なる好みに格下げしてはいけません。実現可能性と衝突する場合は、それを設計に反映する前に伝えます。
重要な選択肢を比較する
明白な選択肢が、まだ検証されていない前提を共有している場合に限り、型破りな選択肢を加えます。
| アプローチ | 改善される点 | 継続的なコスト | 主な不確実性 | 決定的な確認 |
|---|---|---|---|---|
| [仕組み] | [ユーザーまたはシステムの成果] | [保守、実行時、移行] | [無効にする可能性のあるもの] | [実験または証拠] |
仕上げる前に不確実性を検証する
次の一手は、判断を変える力を基準に選びます。粗いプロトタイプのほうが、設計についてもう一段落書くより多くのことを明らかにする場合があります。
| 証拠の不足 | 次の一手 |
|---|---|
| API やモデルの機能が変更されている可能性がある | 最新の一次資料を読み、インストール済みのバージョンを確認する |
| パフォーマンスが実現可能性を左右する | 代表的なワークロードを、ベースラインとリソース上限に照らしてテストする |
| 複数の独立した領域が選択に影響する | 許可されている場合は範囲を限定した調査を委任するか、まとめて調査する |
| ステークホルダーが異なる成果を重視している | 価値のトレードオフをユーザーに提示する |
| 有力なアプローチの裏付けが弱い | 具体的な反例や失敗条件を探す |
レビュー担当者の意見が一致しても、証明にはなりません。レビュー担当者が同じトレーニング、情報源、または枠組みを共有している可能性があるためです。重要な意見の相違は、コード、情報源、または実験で解決し、証拠が決め手にならない場合はその旨を伝えます。
決定し、その理由を残す
最も根拠のある方針を、主なトレードオフと次のアクションとともに提案してください。あるいは、それが成果物である場合は、探索を続けられる状態にしておいてください。
長期的に参照できる決定については、選択、理由、記憶しておく価値のある却下した代替案、根拠、再検討のきっかけを、設定済みのプロジェクトメモリに記録してください。意図的に未決定のままにしておく事項や、言い換えると意味が狭まるユーザーの訂正は、原文のまま残してください。
未解決の事実に関する質問は research に、複雑な実行作業は plan に、範囲が明確で限定された変更は implement に振り分けてください。これらの組み合わせは任意であり、必須のパイプラインではありません。
根拠
2026-09-04 および 2026-10-27 に確認済みです。情報源とその制約については references/evidence.md を参照してください。
反パターン
| 反パターン | より適切な対応 |
|---|---|
| コードを編集するたびにブレインストーミングする | 未解決の方針がある場合にのみ探索する |
| 既知の制約をユーザーに再確認する | 以前の承認と決定を引き継ぐ |
| 表面的な違いしかない選択肢を提示する | 異なる仕組みやトレードオフを比較する |
| 検証していない前提に基づく方法を仕上げる | まず実現可能性を確認する |
| 逸話を普遍的なルールとして扱う | 仕組みを保ち、適用条件を明示する |
このスキルが対象としないもの
- 実装、デバッグ、日常的な修正の前提条件ではありません。
- 仕様書の作成、選択肢の数の固定、最終承認の質問を必須とするものではありません。
- ユーザーのプロダクトに関する判断や、最新の技術的根拠に代わるものではありません。