Superpowers の Brainstorming スキルで設計品質を上げる

症状・対象

要件が曖昧なまま実装を始め、途中で API やデータモデルを作り直している人が対象です。Brainstorming では実装を止め、目的・制約・選択肢・成功条件を先に確定します。

最短解決

1. /brainstorm で目的と既知の制約を渡す。
2. 一度に一つの質問へ答え、未確定事項を明示する。
3. 複数案の trade-off を比較し、設計を明示承認してから計画へ進む。

コピペ例

> /brainstorm
> 既存サービスに passkey ログインを追加したい。
> 制約:
> - 現在の password login は残す
> - account recovery を失わない
> - 既存 session schema の変更は最小限
> - この段階ではコードを書かない
> 質問は一度に一つ。設計案ごとに trade-off と検証方法を示して。

期待結果

• 実装前に、未確定事項を解消する質問が一つずつ提示される。
• 設計案ごとに利点、欠点、移行リスク、検証方法が示される。
• 承認前に source code の実装変更が始まらない。

検証

設計案に次が含まれるか確認します。

• 対象ユーザーと解決する問題
• scope 内・scope 外
• data flow と error / recovery path
• migration と rollback
• test strategy と acceptance criteria

作業前後の差分も確認します。

git status --short

設計文書以外の実装差分がなければ、brainstorming の境界を守れています。

落とし穴

• 「自動で最善案を選んで」と丸投げせず、不可逆な trade-off はユーザーが承認します。
• 質問をまとめて回答すると前提の食い違いを見逃します。一問ずつ確定します。
• 小さな変更でも、外部 API、認証、migration を伴うなら失敗経路を省きません。
• 最新 Superpowers では Skill の文章や lifecycle が更新されます。固定の step 数ではなく、承認ゲートと成果物で判断します。

次の一手

• Superpowers のサブエージェント駆動開発パイプライン — 承認済み設計を計画と実装へ進める
• TDD ワークフローを Claude Code で実践する — acceptance criteria を失敗テストへ落とす