superpowers:brainstorming を使ってみた
きっかけ
AnthropicのClaude Code公式マーケットプレースに superpowers というプラグインがあります。
SaaS連携以外のプラグインを一通り導入したのが始まりです。
superpowersにはいくつかのスキルが含まれていますが、その中に superpowers:brainstorming があります。
ある日、コードの修正を依頼したところ、エージェントが自発的にbrainstormingを開始しました。
想定外でしたが、質問の粒度が適切で自然に回答を続けていました。それがきっかけです。
実際のやりとりはこんな感じでした。
- 既存のシェルスクリプトをGoで書き直すタスクの内容
- Claude側が敬語でないのは敬語禁止にしているため
私: 1PasswordからAWSクレデンシャルを取得するツールをGoで作って欲しい
agent: 既存のシェルスクリプトを確認した。
質問1: このツールはどこに置く想定？
A) scripts/aws/ 配下
B) scripts/ 配下に新しいディレクトリ
C) scripts/gtmd/ みたいな独立したGoモジュール
私: C
agent: 質問2: ビルド成果物はどう使う？
A) go install でPATHに入れる
B) Makefileでビルドして特定パスに置く
C) go run で直接実行
私: A、コマンド名はop-aws-cred-helperで
agent: 質問3: keyringのバックエンドは？
A) macOS Keychain
B) システムデフォルト（OS問わず動く）
C) ライブラリ指定あり（zalando/go-keyring など）
私: C、zalando/go-keyring
質問は1つずつ来ます。一気に10個聞かれるのはストレスですが、1問ずつの壁打ち形式なら答えられます。そして答えているうちに、曖昧だった仕様が対話を通じて明確になります。
会話を通じて出力される仕様書は、今回の変更分だけをまとめた1ファイルです。巨大な仕様書全体を読む必要はありません。
小さい修正の場合は、仕様書と実装計画は出力されず普通に修正して終わります。規模の判断はスキル側に委ねられているため、開発者は意識する必要がありません。
仕様書のレビューループが自動で走る
superpowers v5.0系では、生成された仕様書をspec-document-reviewerというサブエージェントが自動的にレビューします。以前はOpusに手動でレビューを依頼していましたが、v5.0からこのループが自動化されました。
開発者としてやることは仕様書の最終確認のみで、レビューと修正はAIが自律的に完結します。
実際にSKILL.mdを読むとこう書かれています。
- If Issues Found: fix, re-dispatch, repeat until Approved
- If loop exceeds 5 iterations, surface to human for guidance
5回を超えると人間に判断を仰ぐ、という設計になっています。
仕様書が承認されたあとは writing-plans スキルに自動で引き渡されます。実装計画が作成され、それをサブエージェントが実行します。
この設計の利点はコンテキストの保全です。メインのセッションは仕様の承認に集中し、実装の詳細はサブエージェントが別のコンテキストで処理します。長大なコンテキストウィンドウを消費しながらコードを書き続けるよりも、役割が明確に分かれているので管理しやすいです。
実装フェーズでは subagent-driven-development スキルが続きを担当します。タスクごとに新しいサブエージェントを投入し、仕様準拠チェックとコード品質チェックの2段階レビューを自動で通します。仕様書が承認されてからコードを書き始めるまで、人間が介在する箇所は限られています。
subagent-driven-developmentを使い始めてからは、コンテキストが積み上がりにくくなったためAutoCompactを無効にして作業しています。200kを超えることは少なくなりました。実際にセッションログを計測したところ、260ターンにわたる作業でも最大コンテキストは142k token（200kの71%）でした。
SKILL.mdを読んでわかった設計思想
SKILL.mdにはほかにも、意図的に設計された点がいくつか見えました。
SKILL.mdには <HARD-GATE> タグで以下が明示されています。
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
Todoアプリであれ設定変更であれ、すべてbrainstormingを通します。「シンプルだから飛ばしていい」という例外を作らない設計です。
YAGNIも徹底されています。
YAGNI ruthlessly - Remove unnecessary features from all designs
AIが生成するコードは過剰な汎用化に陥りやすいため、この制約は効果的です。今必要なものだけに絞る、という原則を明示することで余計な実装を防いでいます。
既存コードベースのパターンに従う点も明示されています。
Explore the current structure before proposing changes. Follow existing patterns.
コードを読んでから提案します。既存のスタイルと整合しない実装を避ける設計です。
v5.0系にはVisual Companionというモードもあります。UIモックアップや図をブラウザで表示する機能です。
ローカルURLが開いてブラウザで選択肢を比較できます。
どちらを選ぶか迷った状態で回答すると、そのコンテキストが次の提案に反映されます。
CLIとブラウザを切り替える手間は気になりますが、テキストベースのやり取りでは判断しにくいUIの比較に有効です。
まとめ
言語化が苦手でも、brainstormingの質問に答えるだけで仕様が固まります。
SDD系ツールの導入にハードルを感じていた方には、brainstormingから始めるのが現実的な選択肢です。
