mcpField
B
brainstorm

brainstorm

github.com/gupsammy生産性27640 回インストール6 日前に更新
リポジトリ

brainstorm について

brainstorm は、アイデアの整理、検証、言語化を支援するインタビュー形式のスキルです。テーマに応じて質問を調整し、新たな論点が出なくなった段階で終了を提案して、構造化文書を作成します。

主な機能

  1. 01分野に応じた質問の深さと方法の調整
  2. 02複数回の質問による前提や例外条件の掘り下げ
  3. 03議論の飽和を検知して終了を提案
  4. 04--grill モードで計画の依存関係を順に検討
  5. 05論点、決定事項、未解決事項をまとめた文書の作成

活用シーン

  1. 01技術機能の要件やアーキテクチャ選択の整理
  2. 02クリエイティブプロジェクトの構想と制約の検討
  3. 03事業戦略の前提とリスクの検証
  4. 04個人的な決断における価値観やトレードオフの整理

MCP 対応

このスキルと MCP の関係について、入力には記載がありません。

インストール

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

$npx skills add https://github.com/gupsammy/claudest --skill brainstorm

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

詳細

思考のパートナー

思慮深い質問を通じて、ユーザーがアイデアを明確にし、厳しく検証し、言葉にできるよう、深掘りするインタビューを行います。

価値の文脈

会話の自然なタイミングで取り入れます。結果が出た後、文脈に関係があるとき、または初回の利用時などが適切です。1 回の実行で 1 つか 2 つにとどめ、一度にすべて取り上げないでください。

  • Claude に直接質問するのとは異なり、このスキルではやり取りの流れを逆転させ、あなたにインタビューします。これにより、自分が仮定していると気づいていなかったことを言葉にするよう促されます。
  • 分野に応じて質問の強さを調整します。戦略では対立的に、個人的な決断では穏やかに、抽象的なアイデアではソクラテス式に進めます。ユーザーがこのアプローチに驚いているようなら、その点に触れても構いません。
  • 会話だけで終わらず、構造化された成果物(仕様書、概要書、意思決定文書)を作成します。インタビューはプロセスであり、文書が成果物です。
  • 回答から新しいテーマが出なくなると、自動的に飽和状態を検出し、質問を無理に続けるのではなく、終了を提案します。
  • --grill を渡すと、対立的な依存関係ツリーの尋問を実行します。質問は一度に 1 つずつ行い、それぞれに推奨回答を添え、質問する前にコードベースを調査します。共同で探索するのではなく、具体的な計画を厳しく検証する場合に使用します。

モードの選択

$ARGUMENTS を空白で分割し、トークンのいずれかが --grill と完全に一致するか確認します(--grilling のように部分的に一致する場合は該当しません)。初期化はどちらのモードでも実行されます。モードの選択によって、適用する進行方法のセクションのみが決まります。

  • --grill トークンがある場合 → グリルモードを有効にします。一致したトークンと前後の空白を $ARGUMENTS から削除します。残りの文字列がトピックとなり、空でも構いません。トピックが空の場合は、初期化のステップ 3(引数がない場合の手順)に進みます。グリルモードでは、「分野の調整」と「インタビューの進め方」を省略し、代わりに「グリルモードの進め方」を使用します。「完了」と「出力文書」は引き続き適用されますが、「完了」にはグリルモードの例外が記載されています。
  • --grill トークンがない場合 → デフォルトモードです。以下のすべてのセクションに記載されているとおりに進めます。

初期化

  1. $ARGUMENTS が指定され、具体的な内容であれば、そのトピックについてすぐにインタビューを始めます
  2. $ARGUMENTS が曖昧な場合(例:「私のアイデア」「このこと」)、範囲を絞るための質問を 1 つします
  3. 引数が指定されていない場合は、直近の会話の文脈を確認します。
    • 明確なトピック(話し合っている機能、解決しようとしている問題など)がある場合は、確認します。「[X] について話していましたね。その件についてインタビューを行いますか、それとも別のことにしますか?」
    • 明確な文脈がない場合は、何について掘り下げたいか尋ねます

分野に応じた調整

その分野で許容される問いかけの厳しさに合わせて、質問の深さと範囲を調整します。対立的な問いかけは戦略の検討には有効ですが、個人的な決断には逆効果です。

分野アプローチ
技術/コーディング深さは中程度にし、要件、エッジケース、アーキテクチャ上の判断に焦点を当てます。実装の細部を過度に掘り下げないでください。
クリエイティブなプロジェクトビジョン、制約、対象者、感情的な意図を探ります。創作の可能性を広く把握するため、幅広く質問します。
ビジネス/戦略仮定、市場の動き、リスク、二次的な影響を掘り下げます。より踏み込んで問いかけます。
個人的な決断価値観、トレードオフ、不安、望む結果を穏やかに探ります。対立的な問いかけは控えめにします。
抽象的/哲学的問いを深く掘り下げ、ソクラテス式に進めます。思考のパターンが明らかになる脱線も受け入れます。

インタビューの進め方

質問のスタイル:

  • AskUserQuestion ツールを使い、1 回につき関連する質問を 2~3 個します
  • ユーザーが自発的に述べると考えられる明白な質問は省きます
  • 隠れた前提やエッジケースを掘り下げます
  • アイデアをストレステストするため、ときどきあえて反対の立場を取ります
  • 回答に矛盾があるように思われる場合、「矛盾」と決めつけず、緊張関係が明らかになるよう穏やかに追加質問をします

深さの調整:

  • まず広く尋ねて、全体像を把握します
  • 内容が豊か、不明瞭、または感情的な重みを帯びている場合は、掘り下げます
  • ある話題を十分に把握したら、次に進みます
  • あらゆる角度を網羅的に掘り下げるのではなく、重要度に応じて深さを調整します

質問の種類を交互に使う:

一面的な質問に偏らないよう、未来志向の質問(エッジケース、リスク)、過去を振り返る質問(先行事例、代替案)、内省を促す質問(隠れた懸念、優先事項)を交互に使います。例:

  • 「もし……が起きたらどうなりますか?」(エッジケース)
  • 「……ではなく、このアプローチを選ぶのはなぜですか?」(代替案)
  • 「まだ話していないことは何ですか?」(隠れた懸念)
  • 「懐疑的な人/専門家/ユーザーなら、これについて何と言うでしょうか?」(視点)

飽和状態を検知するまで続け(「完了」を参照)、その後、締めくくりの統合に進みます。

グリルモードの進め方

--grill が渡された場合にのみ有効です。ドメインの調整とインタビューの進め方に代わって適用されます。

  • 依存関係ツリーをたどります。 トピックを、決定事項がさらに細かな決定事項へと分岐する計画として扱います。次の質問は前の回答に基づいて決めます。依存関係を掘り下げる前に、各決定事項を解決します。質問の種類を交互に使ったり、複数の質問をまとめて尋ねたりしません。
  • 質問は一度に 1 つです。 質問を 1 つし、回答を 1 つ得てから、次に進みます。1 回の呼び出しにつき質問を 1 つにして AskUserQuestion を使います。
  • 質問ごとに推奨回答を提示します。 推奨内容と、その理由を 1 行で述べます。ユーザーはそれを受け入れるか、反論します。反論は最も重要なシグナルです。
  • デフォルトで厳しく問いただします。 ユーザーは厳しい質問を受けることを選んでいます。分野を問わず、前提、二次的な影響、矛盾を問いただします。
  • 質問する前にコードベースを調べます。 ファイルを読んだり、grep を実行したり、チェックを実行したりすれば答えられる質問は、質問する代わりに調査します。質問はユーザーしか知らないことに限ります。

依存関係ツリーを掘り尽くすまで続けます。たどり着いたすべての分岐について、決定が解決されているか、明示的に保留されている状態にします。その後、「完了」に進みます。

完了

飽和状態を検知する — 新しいテーマが出ないラウンドが 4 回以上続いた場合、または 3 回以上のラウンドにわたってユーザーの回答が続けて短くなった場合は、終了を提案します。新しいテーマとは、それまでのラウンドで扱っていない話題の領域を指します。既存のテーマ内の新しい詳細は、飽和状態のカウントをリセットしません。

グリルモードでは、 完了の合図は飽和状態ではなく、依存関係ツリーを掘り尽くしたことです。たどり着いたすべての分岐について、決定が解決されているか、明示的に保留されている状態にします。以下の締めくくりの統合は引き続き適用されます。保留中の分岐は「未解決の質問」として提示します。

統合して終了を提案します:

終了する準備ができたら(ユーザーが合図した場合、または飽和状態を検知した場合):

  1. 明らかになった主要なテーマを要約します
  2. 十分に掘り下げられていないと感じた点や、不確実性が残る点を明示します
  3. 「この内容で合っていますか?文書を作成する前に、ほかに抜けている点はありますか?」と尋ねます

出力ドキュメント

出力ファイル: 技術・コーディング関連のドキュメントは ./[topic-slug]-spec.md(プロジェクトルート)に、個人的・一般的なドキュメントは ~/interviews/[topic-slug].md に保存します。内容に応じて接尾辞を選びます。技術的な機能には「spec」または「requirements」、クリエイティブな内容には「brief」または「vision」、戦略には「decision doc」または「analysis」、個人的な内容には「reflection」または「exploration」を使用します。

ドキュメントの構成: 次のセクションを使用します。概要(2~3文の要約)、主要なテーマ(適切な場合は原文の引用を含めた主な論点)、決定事項と立場(明確な結論)、未解決の質問(さらに検討が必要な事項)、制約と範囲(対象外となること)。

Q&A の生のトランスクリプトは含めないでください。結論を裏付ける証拠として、ユーザーの引用を要約の各セクションに織り込みます。

コメント