mcpField
B
brainstorming

brainstorming

github.com/ratacatエージェントワークフロー5849 回インストール37 週間前に更新
リポジトリ

brainstorming について

実装方法を計画する前に、何を作るかを明確にするブレインストーミングを支援するスキルです。要件が曖昧な場合や、複数案の比較、機能範囲の検討に適しています。

主な機能

  1. 01要件の明確さの評価
  2. 02一問ずつの意図確認
  3. 03具体的なアプローチの比較
  4. 04構造化された設計要約
  5. 05段階的な認識合わせ

活用シーン

  1. 01曖昧な機能要望の明確化
  2. 02関係者とのトレードオフ検討
  3. 03実装前の機能範囲の調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ratacat/claude-skills --skill brainstorming

インストール後、Claude Code で/brainstormingを入力して読み込まれたか確認します。

同梱ファイルreference/examples.md

詳細

ブレインストーミング

このスキルでは、どのようなものを構築するかを明確にしてから、どのように構築するかに取り組むための、効果的なブレインストーミングセッションの詳しいプロセスを説明します。

このスキルを使うタイミング

ブレインストーミングが役立つのは、次のような場合です。

  • 要件が不明確、または曖昧である
  • 問題を解決できる方法が複数ある
  • ユーザーとトレードオフを検討する必要がある
  • ユーザーが望んでいることを十分に説明できていない
  • 機能の範囲を調整する必要がある

次のような場合は、ブレインストーミングを省略できます。

  • 要件が明確かつ詳細である
  • ユーザーが望んでいることを正確に把握している
  • タスクが単純なバグ修正、または明確に定義された変更である

基本プロセス

フェーズ 0：要件の明確さを評価する

質問を始める前に、ブレインストーミングが必要かどうかを評価します。

要件が明確であることを示す兆候：

  • ユーザーが具体的な受け入れ基準を提示している
  • 従うべき既存のパターンをユーザーが示している
  • 期待する動作が正確に説明されている
  • 範囲が限定され、明確に定義されている

ブレインストーミングが必要であることを示す兆候：

  • ユーザーが曖昧な表現（「もっと良くする」「何かを追加する」など）を使っている
  • 妥当な解釈が複数ある
  • トレードオフが検討されていない
  • ユーザーが進め方に迷っているように見える

要件が明確であれば、次のように提案します。「要件は明確なようです。計画または実装に直接進むことをご検討ください。」

フェーズ 1：アイデアを理解する

ユーザーの意図を理解するため、一度に一つずつ質問します。複数の質問でユーザーを圧倒しないようにします。

質問のテクニック：

  1. 自然な選択肢がある場合は、選択式を優先する

    • 良い例：「通知方法は、（a）メールのみ、（b）アプリ内のみ、（c）両方のどれがよいですか？」
    • 避ける例：「ユーザーへの通知方法はどうしますか？」

  2. 大まかな質問から始め、徐々に絞り込む

    • 最初に、中心となる目的は何かを尋ねる
    • 次に、ユーザーは誰かを尋ねる
    • 最後に、どのような制約があるかを尋ねる

  3. 前提を明示して確認する

    • 「ユーザーはログイン済みであると想定しています。合っていますか？」

  4. 早い段階で成功基準を尋ねる

    • 「この機能がうまく動作していると、どのように判断できますか？」

検討すべき主なトピック：

トピック質問例
目的どのような問題を解決しますか？動機は何ですか？
ユーザー誰が使いますか？ユーザーの利用状況はどのようなものですか？
制約技術的な制限はありますか？期限はありますか？依存関係はありますか？
成功成功をどのように測定しますか？理想的な利用の流れは何ですか？
エッジケースどのようなことが起きてはいけませんか？考慮すべきエラー状態はありますか？
既存のパターンコードベースに参考にできる類似機能はありますか？

終了条件： アイデアが明確になるまで続けるか、ユーザーが「進めて」または「次に進みましょう」と言うまで続けます。

フェーズ 2：アプローチを検討する

アイデアを理解したら、具体的なアプローチを2～3案提示します。

各アプローチの構成：

### Approach A: [Name]

[2-3 sentence description]

**Pros:**
- [Benefit 1]
- [Benefit 2]

**Cons:**
- [Drawback 1]
- [Drawback 2]

**Best when:** [Circumstances where this approach shines]

ガイドライン：

  • 推奨案を最初に示し、その理由を説明する
  • トレードオフについて率直に伝える
  • YAGNIを考慮する。通常はシンプルな方法が最善です
  • 関連する場合は、コードベースのパターンを参照する
フェーズ 3：設計を記録する

重要な決定事項を、構造化された形式で要約します。

設計ドキュメントの構成：

---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---

# <Topic Title>

## What We're Building
[Concise description—1-2 paragraphs max]

## Why This Approach
[Brief explanation of approaches considered and why this one was chosen]

## Key Decisions
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]

## Open Questions
- [Any unresolved questions for the planning phase]

## Next Steps
→ `/workflows:plan` for implementation details

出力先： docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md

フェーズ 4：次のステップに引き継ぐ

次に行うことについて、明確な選択肢を提示します。

  1. 計画に進む → /workflows:plan を実行
  2. さらに調整する → 設計の検討を続ける
  3. 今回はここまでにする → ユーザーは後で再開する

YAGNIの原則

ブレインストーミング中は、複雑さを積極的に避けます。

  • 仮定上の将来の要件を想定して設計しない
  • 提示された問題を解決する、最もシンプルな方法を選ぶ
  • 巧妙な解決策より、実績のある堅実なパターンを優先する
  • 複雑さが生じたら「本当にこれが必要ですか？」と尋ねる
  • 今決める必要のないことは、判断を先送りする

段階的な検証

各セクションは短く、最大200～300語にしてください。出力の各セクションの後に一度停止し、理解を確認してください。

  • 「意図した内容と合っていますか？」
  • 「続ける前に調整したい点はありますか？」
  • 「この方向性で進めてよいですか？」

こうすることで、方向性がずれた設計に時間を費やすのを防げます。

避けるべきアンチパターン

アンチパターンより良い方法
一度に5つ質問する一つずつ質問する
実装の詳細に飛びつくHOW ではなく WHAT に集中する
複雑すぎる解決策を提案するシンプルに始め、必要な場合にのみ複雑さを加える
既存のコードベースのパターンを無視するまず既存のものを調査する
検証せずに仮定する仮定を明示し、確認する
長大な設計ドキュメントを作成する簡潔にまとめ、詳細は計画に記載する

計画との連携

ブレインストーミングで回答するのは、何を作るか（WHAT）です。

  • 要件と受け入れ基準
  • 選択したアプローチとその理由
  • 重要な決定事項とトレードオフ

計画で回答するのは、どのように作るか（HOW）です。

  • 実装手順とファイルの変更
  • 技術的な詳細とコードのパターン
  • テスト戦略と検証

ブレインストーミングの出力がある場合、/workflows:plan はそれを検出して入力として使用し、独自のアイデアの洗練フェーズを省略する必要があります。

コメント

Markdown 対応