Superpowers のサブエージェント駆動開発パイプライン

症状・対象

承認済みの計画はあるが、タスクの実装・仕様レビュー・品質レビューが同じコンテキストに混ざり、自己評価だけで完了してしまう人が対象です。Superpowers の SDD で役割と証拠を分けます。

最短解決

1. Brainstorming で設計を承認し、/write-plan で自己完結した plan file を作る。
2. plan file を指定して subagent-driven-development を開始する。
3. 各 task の実装後に仕様準拠とコード品質を別にレビューし、最後に全体検証する。

コピペ例

> /write-plan
> 承認済みの passkey 設計を、対象ファイル・実装手順・失敗テスト・検証コマンド付きの plan にして。
> 各 task は別の実装者が追加説明なしで実行できる内容にして。

plan 作成後に実行します。

> Superpowers の subagent-driven-development で
> docs/superpowers/plans/passkey-login.md を実行して。
> plan file を SDD workspace の identity に使う。
> 各 task は実装 → 仕様準拠レビュー → コード品質レビューの順に通す。
> 最後に plan 記載の全検証を親セッションで再実行して。

期待結果

• plan ごとに分離された .superpowers/sdd/<plan-basename>/ で進捗が管理される。
• review の修正では、別の新規担当ではなく元の実装者が再開される。
• 最終報告に task ごとの変更、review 指摘、修正、検証結果が残る。

検証

plan の各 task と実際の差分を照合します。

git status --short
git diff --check

続けて plan に記載した test・type check・lint を親セッションで実行します。workspace は clean review 後に片付くため、永続的な証拠は Git diff / history と検証ログへ残します。

落とし穴

• plan file を省略すると、別 plan の進捗と区別できません。最新 SDD では plan identity が必須です。
• 実装者の DONE を仕様準拠の証拠にしません。reviewer が実コードを読みます。
• 修正 round ごとに新しい実装者へ投げると文脈と ownership を失います。元の実装者を resume します。
• finishing-a-development-branch は作業破棄を通常メニューで勧めません。破棄はユーザーが明示した場合だけ検討します。

次の一手

• Superpowers の Brainstorming スキルで設計品質を上げる — SDD の入力となる設計を固める
• TDD ワークフローを Claude Code で実践する — 各 task の RED / GREEN / REFACTOR を定義する