subagent-driven-development

計画書がすでにあって、それを流し込む段階です。タスクが互いに独立している場合に限って効きます。

1 タスクごとに回す 5 段

1. 渡す新しい下位エージェントに 1 タスクを渡す
2. 実装させる実装・テスト・コミット・自己点検をさせる
3. レビューさせる別の下位エージェントに仕様適合と品質をレビューさせる
4. 直す指摘が出たら修正と再レビュー（上限 5 回）
5. 台帳に書く台帳に完了を書く

最後にブランチ全体のレビューを 1 回通します。

台帳が本体

このスキルの要点は、進捗をファイルに書かせることです。理由が本文に書かれています。会話の記憶は圧縮を越えて残らないため、完了済みのタスク列を丸ごと再実行した事例が観測されたとあります。

台帳は .superpowers/sdd/ の下に計画ごとに作られ、完了の行・修正の途中・下した判断が追記されます。再開したときは自分の記憶より台帳と git log を信じるという指示です。

役割ごとにモデルを選ばせる

費用の指針が具体的です。

• 機械的な実装安いモデル
• 統合や判断標準
• 設計と最終レビュー最も高性能なもの
• 修正が詰まったら1 段上へ

指定を省くとセッションのモデルを継承すると明記されています。高い側が既定になりやすいので、指定漏れがそのまま費用になります。

計画書が無いとき

これは実行の道具です。先に計画を作る側のスキル（同じ公開元の brainstorming など）が要ります。

タスクが密に絡んでいるとき

本文の判断図で、密結合なら手作業か再検討に回すよう分岐しています。

下位エージェントを出せない・費用を抑えたいとき

同じ公開元の executing-plans が、自分の文脈 1 つで全タスクを実装し、最後に 1 回だけ全体を見直す版です。

どちらも同じセッションで動き、計画の作業場所と台帳を共有するので、途中で実行役を替えても続きから再開できます。

人が節目ごとに確認したいとき

これが一番大きい相性の問題です。このスキルはタスクの間で人に確認しない方針で書かれています。「続けていいですか」と訊くのは相手の時間の無駄だ、とまで書かれています。

費用を抑えたいとき

タスクごとに新しい文脈を作り、レビューでもう 1 つ作ります。1 つの文脈で流す形より確実に高くつきます。

最後に作業場を rm -rf で消す

同梱の手引き（references/final-review.md）に、ファイルを削除する手順があります。最終レビューが通ったあと、その計画の作業場を rm -rf で消す手順です。

判断を人に返さない設計

止まってよいのは 4 つだけと決められています。

• 取り消せない操作・壊す操作
• セキュリティに関わる操作
• この作業場の外に出る副作用（マージ、共有ブランチへの push、公開）
• 計画が壊れていて、どの道も推測になる場合

これ以外は自分で決めて進み、理由と外れたときの代価を台帳に書くという形です。最後に「裁定の一覧」として人に提示されます。進め方としては合理的ですが、細かく関与したい人には向きません。

worktree の中で動かす

本文にも「main や master で人の明示的な同意なく実装を始めるな」と書かれています。using-git-worktreesを先に入れておくのが前提の作りです。

修正の上限は 5 回

手順は同梱の references/fix-loop.md にあり、回ごとに読み直させます。1〜3 回目は元の実装役に戻し、4・5 回目は 1 段上のモデルで新しい実装役を出します。進行役が自分で直すことは禁じられています（見直しを通らないため）。超えると個別に裁定して先へ進みます。指摘が残ったまま完了する場合があるので、最後の一覧を必ず読んでください。

同梱ファイルと大きさ

同梱ファイルは 13 件です（2026-10-23 確認）。実装役・レビュー役・再レビュー役に渡す指示文 3 件、作業場・タスクの指示書・差分をまとめるスクリプト 3 本、それに references/ の手引き 7 件（修正の回、最後の見直し、再開、事前の食い違いの洗い出しなど）です。

SKILL.md は 19,506 バイトで、修正の回や最後の見直しの手順はその段に来たときに references/ を読ませる作りです。それでも SKILL.md だけで約 19KB あり、文脈の予算への影響は大きい側です。

並列で動かすスキルとの違いは何ですか

dispatching-parallel-agentsは同時に投げる話、こちらは計画を順に流す話です。このスキルの同梱の手引き（references/batching.md）にも、同じ形の小さな作業は 1 つにまとめて投げよと書かれていて、1 タスク 1 エージェントを固守する作りではありません。一方で、実装役を複数同時に出すことは衝突するとして禁じています。

レビューは本当に毎回必要ですか

本文の「よくある言い訳」の表で、修正が小さいから再レビューを省くという判断を名指しで否定しています。省くと回帰が入る、という理由です。このスキルを使う意味はレビューの強制にあるので、そこを外すなら別の形を選ぶほうが筋が通ります。

費用の目安はどのくらいですか

タスク数 × （実装 + レビュー）の文脈が必要だと考えてください。同梱の手引き（references/final-review.md）に、最終レビュー後の修正を指摘ごとに分けて投げた結果、全タスクの合計より高くついた実例が書かれています。まとめて 1 回で投げるよう指示されています。