executing-plans

実装計画があり、タスクごとにサブエージェントを出さず、このセッションで自分で実装するときに効きます。利用者がその実行の仕方を選んだとき、またはサブエージェントを出せない環境のときです。

約 18KB で、4 つの仕組みで組まれている

2026 年 9 月の改訂で、中身が大きく変わりました（以前は約 2KB の短い手順で、困ったら止まって聞く作りでした）。いまは約 18KB で、次の考え方で組まれています。

• 計画の各タスクの「指示書」仕様の代わり。覚えている要約ではなく、毎回これを読む
• 台帳（progress.md）記憶の代わり。会話が圧縮されても、どのタスクが済んだかが残る
• 試験を先に書くタスクごとの関門。落ちるのを見てから通す
• 最後の見直しもう一組の目。ブランチ全体を 1 回だけ、別の文脈で見る

Task 1 の前に、タスク同士で受け渡すもの（前のタスクが作り、後のタスクが使うもの）の食い違いを洗い出し、台帳に書きます。タスクを閉じるときは同梱の task-done が試験を流し、通ったときだけ台帳に完了の 1 行を足します。落ちたら何も記録されません。

止まらずに進み、判断は記録する

以前と最も違うのはここです。本文は「タスクの間で利用者に確認を取るな」と書いています。利用者が安く済ませるためにこの実行の仕方を選んだのだから、毎回「続けますか」と聞くな、という理由です。

計画の食い違いや曖昧さは、自分で決めて進みます。そのかわり、決めたことは必ず台帳に Ruling: 何を決めたか — なぜ — 間違っていたときの代償 の形で残します。

台帳に残さずに計画から外れるのは「こっそり決めた」ことになる、と書かれています。

止まるのは 4 つのときだけ

止まるのは次の 4 つのときだけです。

• 元に戻せない操作元に戻せない、または破壊的な操作
• セキュリティセキュリティに関わる操作
• 作業場所の外への副作用ふつうは先に聞くもの（マージ、共有の枝への push、公開）
• 計画が壊れているどの道も当てずっぽうになるとき

終わり方

全タスクが済んだら、ブランチ全体をまとめた資料を作り、最も能力の高いモデルの見直し役に渡します。サブエージェントが無ければ自分で見直し、「自己点検だった」と台帳と最後の報告に書きます。

重大・重要な指摘は 1 回だけの修正の回で直し（それぞれ試験を落としてから通す）、軽微なものは台帳に回します。最後の報告には「自分が下した裁定」と「後回しにした軽微な指摘」の一覧を必ず入れ、そのあと finishing-a-development-branch に進みます。

タスクごとに見直しを挟みたいとき

本文も、利用者がタスクごとの見直しを望むときや、計画が長くて後半が圧縮された文脈で走りそうなときは subagent-driven-development を勧めています。台帳と作業場所の形は共通なので、途中で実行役を替えても続きから再開できます。

計画が無いとき

計画を書くのは writing-plans です。本文も「計画がすでに考えを済ませている。そのとおりに実行せよ」という前提です。

途中で方針を話し合いながら進めたいとき

途中で確認を取らない作りなので、探索的な作業とは噛み合いません。

解析で見つかったもの

SKILL.md の解析では、シェルコマンドの実行とファイルの削除の記述が見つかっています。同梱ファイルは 2 件で、タスクの開始と完了を記録するスクリプトです。

途中で相談せずに最後まで進む

以前の版を知っている人ほど注意してください。仕様と計画の食い違いを自分で「裁定」して進みます。

作業場所を最後に消す

計画ごとの作業場所（リポジトリの中の git の対象外のフォルダ .superpowers/sdd/）に台帳や指示書を置き、最後の見直しが済むと削除します。git clean -fdx でも消えるので、そのときは git log から戻す、と書かれています。

主幹の枝では始めない

利用者の明示の許可なしに main や master で実装を始めない、と決めています。

単体では完結しない

試験を先に書く test-driven-development を最初に読み込み、見直しには requesting-code-review の見直し役の指示を使い、最後に finishing-a-development-branch を呼びます。

ライセンス

ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。

subagent-driven-development とどちらを使いますか

費用と見直しの細かさの取り引きです。サブエージェント方式は、タスクごとに新しい実装役と見直し役を出すので、精度は高いが高くつきます。こちらは自分の文脈 1 つと、最後の見直し 1 回だけです。本文は、計画が十分に細かければ中くらいのモデルでもよく回り、最も能力の高いモデルが要るのは最後の見直しだけ、としています。

会話が圧縮されたら、同じタスクをやり直しませんか

それを防ぐのが台帳です。圧縮のあとは、自分の記憶より台帳と git log を信じよと書かれています。台帳に「完了」とあるタスクはやり直さず、最初の未完了のタスクから再開します。

計画の間違いを見つけたらどうなりますか

仕様を満たす最小の変更を自分で決め、台帳に裁定として残して進みます。コードの誤りなら、原因を探す別のスキル（systematic-debugging）を使い、症状だけを直して期待の出力に合わせることはしない、と決めています。

対応しているエージェントはどれですか

Claude Code と Codex です。公開元の案内に、サブエージェントの道具の対応として各環境が挙がっています。当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。