brainstorming

アイデアをデザインに落とし込む

コードベースに基づく構造化された調査を通じて、粗削りなアイデアを実装可能なデザインに仕上げます。パイプライン全体（並列で動作する調査サブエージェント＋評価者）は、自由度の高い複数コンポーネントにまたがる問題向けに調整されています。些細な作業は、以下の早期終了チェックによってパイプラインを省略します。これは複数のフェーズにわたる大がかりな作業です。実行方法として推奨されるのは、Claude Code 組み込みの /goal でラップすることです（以下を参照）。

推奨：/goal でラップして実行する

ブレインストーミングでは、自由度の高い複数ターンにわたる調査を行います。途中でパイプラインが止まることなく、新しい評価者が複数ターンにわたって完了まで導けるよう、Claude Code 組み込みの /goal（v2.1.139 以降）のもとで起動してください。

/goal "Claude has narrated a successful design commit (with commit hash) and the evaluator's verdict is PASS" /superpowers:brainstorming "<problem>"

/goal はユーザーが入力する外側のラッパーです（スキルが実行中に自ら有効化することはできません）。また、その評価者が判定するのはトランスクリプト内で Claude が説明した内容だけです。条件はファイルシステムの状態ではなく、説明された出力（コミットハッシュ、評価者の判定を示す文字列そのもの）に基づいて記述してください。詳細な動作、条件の記述方法、早期終了との連携については、../../skills/references/goal-wrapper.md を参照してください。

重要：早期終了チェック（初期化の前に実行）

$ARGUMENTS を次の3つのカテゴリのいずれかに分類してください。判断に迷ったら「続行」を既定にしてはいけません。その判断は、エージェントを一方向に偏らせ、過剰な設計につながります。

カテゴリ A — 些細な作業範囲を示す強いシグナル（早期終了：デザインファイルを書かず、評価者も起動しない）：

• 単一ファイルまたは1行の変更を指定している（「X を Y に変更」「foo を bar に名前変更」「ログレベルを DEBUG に」など）
• 機械的なリファクタリング（「ヘルパーを抽出」「インポートの順序を変更」「非推奨の API 呼び出しを更新」など）
• 根本原因が明示されたバグ（「Cookie のドメインが間違っているので修正」など）— /superpowers:systematic-debugging に引き継ぎます
• 一度限りのスクリプト／設定の調整／依存関係の更新
• ユーザーが「パッチだけ」「計画不要」「簡潔に修正」と明示している

カテゴリ B — 自由度の高い作業を示す強いシグナル（初期化に進む）：

• 明示されたサブシステムを含む、複数コンポーネントのデザイン（例：「メール＋SMS＋プッシュ通知に対応する通知システムを設計」）
• 対話を通じた要件の明確化をユーザーが期待している、曖昧な要件
• 「まず設計」「ブレインストーミング」と明示された新規機能

カテゴリ C — 曖昧（カテゴリ B を既定とし、質問で中断しない）：

• $ARGUMENTS が短く、どちらとも取れる（例：範囲を示す手がかりがない一文）
• 些細な作業を示すシグナルと、自由度の高い作業を示す表現が混在している
• 作業範囲ではなく成果だけが指定されている（例：「パフォーマンスを改善」「もっと速く」）

カテゴリ A の場合は、以下の早期終了応答を出力して停止してください。カテゴリ B（カテゴリ C のすべてのケースを含む）の場合は、初期化に進んでください。--force トークンは後方互換性のために維持されていますが、現在は何もしません（早期終了は呼び出しごとに判定されます）。後から作業範囲が変わった場合は、フェーズ 1 の途中での方針転換処理で対応します。

早期終了応答（カテゴリ A の場合は、以下をそのまま出力してから、直接編集するか、引き継いでください）：

些細な作業範囲を検出しました。自由度の高い複数コンポーネントにまたがる問題向けに調整されたブレインストーミングパイプラインを省略します。パイプライン全体を実行するには、/superpowers:brainstorming --force "<task>" として再度呼び出してください。

初期化

1. 問題の記述を取り込む：$ARGUMENTS を、ブレインストーミングの対象となる問題を表す約150文字以内の単一の断定文にまとめます。ユーザー自身の表現を使います。言い換えたり、制約を省略して要約したり、ユーザーが使っていない語彙を導入したりしてはいけません。先頭に --force トークンがある場合は取り除きます（ベイルアウトチェックで既に消費されています）。$ARGUMENTS が空の場合は、会話の中でユーザーが直前に説明した未解決の問題を使います。
2. プロジェクトのコンテキストを読む：プロジェクトの制約を理解するため、CLAUDE.md と README.md を読みます。次にドキュメントインデックスを参照します。bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" list --kind design --status active と bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" list --status expired を実行します。expired: とされた設計の結論は権威ある情報として扱わず、期限切れの設計を拡張するのではなく、新しい設計を作成します。同じトピックの active な設計が既にある場合は、それを Phase 1 のスプリント契約に明記し、拡張する（推奨）か、Phase 3 のまとめで置き換えます。次にメモリを参照します。bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" list --kind memory --status active を実行し、Phase 1 の調査に入る前に、関連性の高い上位3～5件のファイルを読みます。
3. 同じターン内で Phase 1 に進む。

基本原則

1. コンテキストを最優先：質問する前にコードベースを調査します
2. YAGNIを徹底：明示的に必要なものだけを含めます
3. テストファーストの考え方：常に BDD 仕様を含めます――superpowers:behavior-driven-development スキルを読み込みます
4. 段階的な検証：次に進む前に、各フェーズの終了条件を検証します
5. 設計によるコンテキストのリセット：調査と QA は新しいサブエージェントのコンテキストで実施します（Anthropic harness-design の原則1）――メインエージェントは統合のみを行います。

Phase 1：スコープの調整

コードベースを調査し、アプローチをその場で確定して、同じ反復内で Phase 2 に進みます。

アクション：

1. コードベースを調査する：Read/Grep/Glob を使って、関連するファイル、パターン、ドキュメント、最近のコミットを見つけます。契約を記録する前にコンテキストを把握します。
2. スプリント契約：ターンの出力に、構造化された提案をその場で記録します。
   • 「[問題]について、私が理解した内容」
   • 「[理由]から、[アプローチ]を推奨します」
   • 「検討した代替案：[トレードオフを含む簡潔なリスト]」
   • 「解決済みの未解決質問：[コードベースの根拠から自分で回答した質問。ユーザーに判断を委ねてはいけません]」
3. 確定して次へ進む：スプリント契約を確定したスコープとして扱い、Phase 2 に進みます。承認を求めて作業を中断してはいけません――品質ゲートは Phase 2 の評価と、コミット後にユーザーが行うレビューです。コードベースから本当に回答できない質問がある場合は、最も安全なデフォルトを選び、その前提をスプリント契約に記録し、評価者が指摘できるよう Phase 2 の設計ファイルにも明記します。

自由度の高い問題：前提への異議申し立てが必要な場合は、スプリント契約の中で第一原理思考を適用します。検証する前提、代替となる捉え方、そしてそれによって選択するアプローチが変わる理由を明示します。

終了条件：選択したアプローチが1つに定まり、要件と制約が明確で、Phase 2 に進む準備ができたスプリント契約がその場で記録されていること。

途中での方針転換（/goal でラップされている場合のみ可能）：新しいスコープで Phase 1 のステップ1を再実行し、スプリント契約を一から作り直します。根本的な上書き、または「中止」／「キャンセル」の場合は、1行のメモを残して停止し、設計ファイルは作成しません。詳しくは ./references/scope-alignment.md §Mid-Stream Pivots を参照してください。

調査のパターン、質問のガイドライン、トレードオフのテンプレートについては、./references/scope-alignment.md を参照してください。

Phase 2：QAと用語の調整を伴う設計

品質保証を組み込んだ設計ドキュメントを作成し、統合の前に、サブエージェント間で異なる用語を調整して標準用語集にまとめます。すべての調査は新しいサブエージェントのコンテキストで行います。メインエージェントは統合と調整のみを行い、コンテンツの作成は行いません。

ステップ1：設計ドキュメントを作成する フォルダー：docs/plans/YYYY-MM-DD-<topic>-design/（-design サフィックスは必須です）。同じトピックで同日に2つ目の設計を作成する場合は、-design-2/（以降は -3/）サフィックスを付けます。ドキュメントのインデックスはフォルダーの完全なパスをキーにします。詳細なルールは ./references/design-and-qa.md §フォルダー命名規則を参照してください。

必須ファイル（4つ）：

• _index.md -- コンテキスト、調査結果、要件、根拠、詳細設計、設計ドキュメント（関連ドキュメントへのリンク）
• bdd-specs.md -- Gherkin シナリオ全体（正常系、エッジケース、エラー条件）
• architecture.md -- システム概要、コンポーネント、データ構造、統合ポイント
• best-practices.md -- セキュリティ、パフォーマンス、コード品質、よくある落とし穴

_index.md では、次のセクション見出しをこの順序で正確に使用する必要があります：Context、Discovery Results、Glossary、Requirements、Rationale、Detailed Design、Design Documents。## Glossary セクションには、以下の用語調整パスで作成した内容を記載します。相違が見つからなかった場合も、将来の読者が標準ラベルを確認できるよう、必ず記載してください。

bdd-specs.md：Gherkin シナリオはすべて、このファイルに直接記述します。個別の .feature ファイルは作成しないでください。これらは実装フェーズに属します。

サブエージェント戦略（必須）：Agent ツールを使用して、3つ以上のサブエージェントを並行して起動し、それぞれを独立した新しいコンテキストで実行します（調査の記録がメインエージェントに混入することはありません）。役割は、アーキテクチャ調査（パターン、ライブラリ、規約。最新の手法を WebSearch で調査）、ベストプラクティス調査（セキュリティ、パフォーマンス、テスト。「superpowers:behavior-driven-development」を読み込みます）、コンテキストと要件の統合です。調査が集中的に必要な領域には、追加のサブエージェントを起動します。詳細なプロンプトと出力については、./references/design-and-qa.md §サブエージェント戦略を参照してください。

用語の調整（統合前に必須）：すべてのサブエージェントの結果が返ってきた後、出力を統合する前に、明示的な確認を1回行います。サブエージェントの出力から、概念を指す用語（説明ではなく概念に名前を付けるもの）を抽出し、概念ごとにサブエージェント別の用語集テーブルを作成します。相違のある概念については、標準ラベルを1つ選び（コードベースのパターンを優先し、採用しなかった表記も記録します）、統合した4つのファイルを作成する前に、サブエージェントの出力にある表記の相違を修正します。最初に作成してから用語を調整してはいけません。標準ラベルは _index.md の ## Discovery Results の直後にある ## Glossary セクションに記録します。手順の詳細と発端となった2026-05-09の事例については、./references/design-and-qa.md §用語の調整を参照してください。

検証（統合後）：4つのファイル全体で grep -oE "<concept-noun>" を実行し、標準ラベルのみが返され、採用しなかった表記が含まれないことを確認します。表記の相違が残っている場合は、調整パスで見落としたファイルがあるため、先に戻って修正してください。

統合：用語の調整後、メインエージェントが返された結果を統合し、残る矛盾をコードベースのパターンを優先して解決したうえで、設計ファイル4つを作成します。

ステップ2：統合後のQA

docs/retros/checklists/design-v{N}.md（最大のN）の最新チェックリストを解決します。superpowers:superpowers-evaluator エージェントを設計モードで起動し、チェックリストのパスを渡します。評価エージェントはレポートの内容をテキストで出力します。その内容を設計フォルダーに evaluation-design-round-{N}.md として書き込みます。その後、レポートの判定を確認します。

• PASS：そのままフェーズ3の締めくくりに進みます。ユーザーの確認待ちで停止してはいけません（PASS 判定と、コミット後の git show の差分がレビュー対象です）。
• REWORK：問題を修正し、必要に応じて評価エージェントを再実行します（evaluation-design-round-2.md などを作成します）。
• 2回以上の REWORK：パッチを当てるのではなく、アプローチを整合させるためにフェーズ1に戻ることを検討します。 不足している場合は自動シード：docs/retros/checklists/design-v{N}.md が存在しない場合でも、中止しないでください。bash "${CLAUDE_PLUGIN_ROOT}/lib/seed-checklists.sh" design docs/retros/checklists/design-v1.md を実行し、Auto-seeded design-v1.md とログに記録してから、新しいファイルで続行します。終了コードの処理：0 = シード済み、3 = すでに存在（成功として扱い、既存のファイルで続行）、1/2 = 実際のエラー（ディスク／使用方法のエラー → 中止）。

終了条件：必要なファイルがすべて揃った設計フォルダーが作成され、QA に合格していること。

出力構造の詳細、サブエージェントのパターン、QA の手順については、./references/design-and-qa.md を参照してください。 評価者チェックリストの調整については、./references/evaluation-checklist-reference.md を参照してください。

フェーズ 3：仕上げ

設計をコミットし、実装計画の作成へ移行します。

アクション： 0. 重要 — 後回しにしないこと：設計をドキュメントインデックスに登録し、後続のライタースキルから見つけられるようにします。bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" upsert design docs/plans/YYYY-MM-DD-<topic>-design/ --status active --summary "<one-line summary>" を実行します。同じトピックの既存の active な設計を置き換える場合は、先に bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" set-status docs/plans/<prior-design-path>/ "superseded-by:docs/plans/YYYY-MM-DD-<topic>-design/" を実行して、置き換え済みとしてマークします。この参照してから登録する組み合わせにより、各フェーズを通じてインデックスの正確性が保たれます。 0.5. 重要 — 後回しにしないこと：条件付きのメモリー書き込み手順。REWORK が 2 回以上（フェーズ 2 のトリガー）発生した場合に実施します。この設計で REWORK が 2 回以上発生した場合は、繰り返し発生した原因を記録します。docs/memory/<category>_<slug>.md を作成し（スコープの撤回なら category: decision、評価者に繰り返し指摘されたミスなら category: pitfall）、続けて bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" upsert memory docs/memory/<category>_<slug>.md --status active --summary "<one-line>" --category <category> を実行します。REWORK が 2 回未満の場合、この手順は何もしません。

1. フォルダー全体を 1 つの連結コマンドでステージングしてコミットします。単独の git add は git プラグインのフックにより拒否されます：git add docs/plans/YYYY-MM-DD-<topic>-design/ && git-agent commit --no-stage --intent "add design for <topic>" --co-author "Claude <Model> <Version> <[email protected]>"
2. 認証エラーが発生した場合は、--free フラグを付けて再試行します。
3. フォールバック：git-agent を利用できない場合は、Skill ツールを使って /git:commit スキルを呼び出します。完全な手順については ../../skills/references/git-commit.md を参照してください。
4. 移行メッセージ（ユーザーに出力）："Design complete. To create a detailed implementation plan, use /superpowers:writing-plans."

コミット後にレビュー／仕上げの反復を追加しないでください。4 つの設計ファイル、評価者による PASS、コミットが終了条件のすべてです。

コミットの詳しいパターンについては、../../skills/references/git-commit.md を参照してください。

参照

• ./references/scope-alignment.md -- 探索のパターン、スプリント契約モデル、質問のガイドライン
• ./references/design-and-qa.md -- 出力構造、サブエージェントのパターン、QA の手順
• ./references/evaluation-checklist-reference.md -- 評価者向け設計評価チェックリストのリファレンス
• ../../skills/references/git-commit.md -- Git コミットのパターン（共通）
• ../../skills/references/goal-wrapper.md -- /goal ラッパーのセマンティクスと条件の表現（共通）