mcpField
B
brainstorming

brainstorming

github.com/zenobi-usエージェントワークフロー6848 回インストール今日更新
リポジトリ

brainstorming について

段階的な質問と代替案の比較、各セクションの確認を通じて、初期のアイデアを設計や仕様にまとめる協働スキルです。実装前のプロジェクト検討に使えます。

主な機能

  1. 01一問ずつ目的と制約を明確化
  2. 02既存プロジェクトの状況を確認
  3. 032~3案とトレードオフを比較
  4. 04確認しやすい単位で設計を提示
  5. 05決定事項を記録し実装を計画

活用シーン

  1. 01初期のプロジェクト案を具体化
  2. 02設計案を比較して選択
  3. 03実装前にアーキテクチャを検証

インストール

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

$npx skills add https://github.com/zenobi-us/dotfiles --skill brainstorming

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

詳細

アイデアをデザインにまとめる

概要

自然な対話を通じて、アイデアを完成度の高いデザインや仕様にまとめるのを支援します。

まず現在のプロジェクトの状況を把握し、アイデアを深めるために一度に1つずつ質問します。作成するものを理解できたら、デザインを200〜300語の短いセクションに分けて提示し、各セクションの後に、ここまでの内容で問題ないか確認します。

プロセス

アイデアの把握:

  • まず現在のプロジェクトの状態を確認します(ファイル、ドキュメント、最近のコミット)
  • アイデアを深めるために、一度に1つずつ質問します
  • 可能であれば選択式の質問を優先しますが、自由回答でもかまいません
  • 1回のメッセージにつき質問は1つだけにします。さらに掘り下げる必要がある場合は、複数の質問に分けます
  • 目的、制約、成功基準の把握に重点を置きます

専門家による調査:

  • アイデアに専門知識が関わる場合は、関連する専門家を特定します
  • task(Researcher) ツールを使って、サブエージェントに調査タスクを委任します

アプローチの検討:

  • トレードオフを含めて、異なるアプローチを2〜3案提案します
  • 推奨案とその理由を添えて、会話形式で選択肢を提示します
  • 推奨案を最初に提示し、その理由を説明します

デザインの提示:

  • 作成するものを理解できたら、デザインを提示します
  • 200〜300語のセクションに分けます
  • 各セクションの後に、ここまでの内容で問題ないか確認します
  • アーキテクチャ、コンポーネント、データフロー、エラー処理、テストを扱います
  • 内容に不明点があれば、立ち戻って確認します

議論中

質問の提示:

  • 質問と選択肢を明確かつ簡潔に提示します
  • 質問はタイトルとして示し、その下に選択肢や詳細を記載します
  • 選択肢には番号付きリストまたは文字付きリストを使い、ユーザーが番号や文字で回答できるようにします
  • デザインのセクションを提示した後に、「ここまでの内容で問題ありませんか?」と尋ねます

一貫性の確保:

  • これまでの回答とデザイン上の決定事項を把握しておきます
  • 以前の内容に立ち返り、整合性が保たれているか確認します
  • フィードバックや新しい情報に応じて、デザインを調整します

方向性の変更:

  • ユーザーが大きな方向転換を示した場合は、いったん立ち止まって再検討します
  • ユーザーが以前の質問を起点とする別案を検討しているか確認します。そうであれば、その質問に戻って選択肢を再提示します
  • 新しい方向性を理解するため、確認の質問をします
  • 新しい方向性で進める前に、理解が正しいか確認します

デザインの完成後

ドキュメント作成:

  • 承認されたデザインを、指定されたストレージバックエンドを使って記述します。
  • 利用可能であれば、elements-of-style:writing-clearly-and-concisely スキルを使います
  • デザインドキュメントを git にコミットします

実装(続ける場合):

  • 「実装の準備を始めますか?」と尋ねます。はいの場合:
    • superpowers_using_git_worktrees スキルを使って、分離されたワークスペースを作成します
    • superpowers_writing_plans を使って、詳細な実装計画を作成します
  • そうでなければ、セッションを終了します

基本原則

  • 一度に質問は1つだけ — 複数の質問で相手を圧倒しない
  • 選択式を優先 — 可能であれば、自由回答よりも答えやすい形式にする
  • YAGNIを徹底する — すべてのデザインから不要な機能を取り除く
  • 代替案を検討する — 決定する前に、必ず2〜3案を提示する
  • 段階的に検証する — デザインをセクションごとに提示し、それぞれを検証する
  • 柔軟に対応する — 内容に不明点があれば、立ち戻って確認する

コメント