
Claude Codeで実装計画を進める ― executing-plans
cccskills 編集部読了 約 11 分
この記事の結論
- こんな人に
- 作成済みの実装計画を、別エージェントに分けずにClaude Codeなどで順番どおり最後まで実装させたい開発者
- 入れると
- 計画を渡すだけで、テストの失敗と成功を確かめながらタスクが順に実装される
- 計画からの変更や判断が記録に残り、会話が要約されても未完了タスクから再開できる
- 最後にブランチ全体のレビューと修正が入り、判断と先送り事項の一覧が届く
- 向かない人
- 計画がまだない段階の人や、長い計画でタスクごとに別のレビューを挟みたい場面には向きません。
executing-plansを入れると、作成済みの実装計画を、Claude Codeなどのエージェントが同じセッションの中でタスクごとに実装できます。テスト結果と判断を記録しながら、最後まで進める仕組みです。この記事では、処理の流れとインストール方法、依頼文の例、worktreeや関連スキルにまつわる注意点を紹介します。
目次
使うとこうなる
作成済みの実装計画を渡すと、エージェント自身がタスクを1つずつ実装して最後まで進めます。テスト結果と判断も、進めながら記録していく仕組みです。依頼は次のような一文だけで構いません。
docs/plans/search.mdの実装計画を、このセッションで最後まで進めてください。
最初に行うのは準備です。エージェントはworktree(Gitの作業領域を分ける仕組み)を用意し、計画を読みます。タスク同士の受け渡しに食い違いがないかを確かめるのも、この段階です。
各タスクでは、まずテストを書いて失敗を確認します。そのあと実装して成功を確かめ、計画どおりにコミットする流れです。
進捗記録に「完了」として残るのは、テストが通ったタスクだけです。その行にはコミットの範囲とテストの結果が添えられます。全タスクを終えたあとは、ブランチ全体のレビューの番です。
最終メッセージには、判断の一覧「Rulings I made」と先送りした指摘の一覧「Deferred minors」が並びます。人が確かめるべき点を、まとめて受け取れる形です。
executing-plansでできること
executing-plansは、実装担当の別エージェントを立てず、いま対話しているエージェント自身が計画を実装するためのスキルです。タスクごとの実装役もレビュー役も置かず、レビューは最後にブランチ全体へ1回だけ行います。その代わり、品質はテスト・記録・最終レビューの3つで保つ作りです。
タスクごとにテストで区切る
各タスクの合格ラインはテストです。先にテストを書き、失敗するところを実際に見てから実装して、成功を確かめます。実装前に通ってしまうテストは、テスト自体の問題として扱う決まりです。
計画の各コマンドには期待される出力が書かれており、エージェントは実際の出力と1つずつ照らし合わせます。食い違ったときの対応は、原因によって2通りです。コードが原因ならsystematic-debuggingで原因を探り、計画が原因なら判断を記録して先へ進みます。
判断を記録して止まらずに進む
タスクの合間に「続けてよいですか」と確認しないのが、このスキルの方針です。計画の矛盾や曖昧な点は、エージェントが自分で決めます。決めた内容と理由、外れた場合の影響を1行ずつ記録して、先に進む流れです。
作業を止めて人に確認するのは、次の4つの場面に限られます。
- 取り消せない操作や破壊的な操作
- セキュリティに関わる操作
- マージや共有ブランチへのpush、公開など、worktreeの外に影響する操作
- 計画の不備が大きく、どの進め方を選んでも当て推量になる場合
記録のない計画からの逸脱は「隠れて下した判断」とみなされるため、変更は必ず記録に残ります。
記録から再開できる
会話が要約されて記憶が薄れても、記録ファイルとGitの履歴から作業を続けられます。完了と記録されたタスクはやり直さず、最初の未完了タスクから再開する手順です。記録と自分の記憶が食い違うとき、信じるのは記録とgit logのほうです。
記録はGitの管理対象外のフォルダに、計画ごとに作られます。別の計画の記録には触れません。subagent-driven-developmentと同じ場所・同じ形式なので、途中で進め方を切り替えても同じ記録から続きを始められます。
最後にブランチ全体をレビューする
最後の仕上げは、ブランチ全体のレビューです。別エージェントを使える環境では、最も能力の高いモデルを明示してレビュー役に任せます。使えない環境では、エージェントが自分でレビューする形です。その場合は、自己レビューだったことを記録と最終報告に残します。
指摘は重要度で仕分け、重大と重要に当たるものだけを1回の修正でまとめて直します。修正のたびに指摘を再現するテストを書き、失敗を見てから直す手順です。直したあとは、全テストが通ることを確かめます。
別エージェントを使わずに進めたいとき
このスキルが向いているのは、次の3つの場面です。
- 同じリポジトリのwriting-plansで作った計画があり、同じセッションでの実行を選んだとき
- 使っている環境に別エージェントを呼び出す機能がないとき
- 計画のタスクがおおむね互いに独立しているとき
タスクごとにレビューを挟みたい場合は、subagent-driven-developmentが勧められています。計画が長く、後半のタスクが要約後の文脈で動く場合も同じです。長い計画でも記録があれば立て直せますが、後半のタスクほどエージェントの余力は減っていきます。
計画が細かく決まっていれば、実装は中程度のモデルでもこなせます。最も高性能なモデルが必要なのは最終レビューだけ、という位置づけです。
インストール方法
インストールの方法は、コマンドを1行実行するか、エージェントに文面を送って頼むかの2通りです。コマンドではnpx skills addを使い、Claude CodeやCodexなど入れる先のエージェントを選べます。
npx skills add https://github.com/obra/superpowers --skill executing-plans
エージェントに頼む場合は、次の文面をそのまま送ってください。中身の確認から配置までを、エージェントに任せられます。
次の Agent Skill をインストールしてください。
https://github.com/obra/superpowers/tree/main/skills/executing-plans
まず SKILL.md と付属ファイルの中身を確認し、不審な処理(外部への送信、認証情報の読み取りなど)がないことを確かめてから、Claude Code なら ~/.claude/skills/executing-plans/、Codex なら ~/.agents/skills/executing-plans/ に配置してください。
置き場所は次の表のとおりです。
| エージェント | すべてのプロジェクトで使う | 特定のプロジェクトだけで使う |
|---|---|---|
| Claude Code | ~/.claude/skills/ | プロジェクトの.claude/skills/ |
| Codex | ~/.agents/skills/ | プロジェクトの.agents/skills/ |
配布元はGitHubのobra/superpowersです。
使い方の例
依頼文は、計画ファイルを指定して進め方を一言添えれば足ります。
この実装計画を同じセッションで進め、各タスクのテスト結果を記録してください。
エージェントはworktreeの確認から始め、テストの失敗と成功を確かめながらタスクを順に実装します。タスクが1つ終わるたびに、記録には完了の行が1行増えます。その行に書かれるのは、コミットの範囲とテストの結果です。
進捗記録を確認し、未完了のタスクから再開してください。
まず確かめるのは、記録の1行目が同じ計画のものかどうかです。そのうえで完了済みのタスクを飛ばし、最初の未完了タスクから続けます。別の計画の記録だった場合は、その記録には手を付けず、新しい記録を作って始めます。
全タスクの完了後に、ブランチ全体をレビューしてください。
返ってくるのは、重要度で仕分けたレビュー結果と修正です。重大・重要な指摘はテストつきで直され、軽微な指摘は「Deferred minors」として最終報告に並びます。
注意点
最も大事な前提は、作成済みの具体的な計画があることです。このスキルは計画を実行する役で、計画を考える段階は受け持ちません。計画の各手順にテストや期待される出力が書かれているほど、確実に進みます。
同じリポジトリの他のスキルを呼び出す前提である点にも、注意が必要です。SKILL.mdには、最初のタスクの前にtest-driven-developmentを必ず読み込むことが書かれています。worktreeの用意にusing-git-worktreesを使うよう指定されている点も同じです。
作業フォルダとレビュー資料の作成には、subagent-driven-developmentの付属スクリプトを使います。最終レビューはrequesting-code-reviewの手順に、終了処理はfinishing-a-development-branchに従う形です。
executing-plansだけでなく、superpowersの関連スキルもあわせて入れておくのが前提です。
Gitの扱いにも、いくつか決まりがあります。人の明確な同意がない限り、mainやmasterブランチで実装を始めることはしません。
記録を置くフォルダはGitの管理対象外なので、git clean -fdxで消えてしまいます。その場合は、Gitの履歴から立て直す手順です。
ライセンスはMITです。付属ファイルはSKILL.mdと、scripts/task-start・scripts/task-doneの2つのスクリプトです。入れる前に中身を読んで、処理内容を確かめてください。
関連スキル
executing-plansの前後で使うスキルは、同じsuperpowersのリポジトリにまとまっています。
- subagent-driven-developmentは、同じ計画をタスクごとに別エージェントへ任せる進め方です。記録の形式が共通で、途中から切り替えられます。
- requesting-code-reviewは、最終レビューで使うレビュー手順を持つスキルです。別エージェントにコードレビューを依頼します。
- finishing-a-development-branchは、executing-plansの最後に使う仕上げのスキルです。全テストを確かめ、マージ、Pull Request作成、現状維持のいずれかを選んで進めます。
まとめ
executing-plansは、作成済みの実装計画をエージェント自身が同じセッションで最後まで実装するためのスキルです。テストを先に失敗させてから実装し、判断と進捗を記録するので、会話が途切れても未完了のタスクから再開できます。最後にはブランチ全体のレビューが入り、判断の一覧と先送りした指摘の一覧が届く流れです。
まずはタスクが数個の小さな計画で、記録とレビューの流れを確かめてみてください。
詳しい紹介はcccskillsのページにまとめています。
よくある質問
- subagent-driven-developmentとはどう使い分けますか
- タスクごとにレビューを挟みたいときや計画が長いときは、subagent-driven-developmentが向いています。費用を抑えて同じセッションで進めたいときや、別エージェントを呼べない環境なら、executing-plansの出番です。両者は記録の形式が同じで、途中での切り替えもできます。
- 会話が要約されて作業を忘れたらどうなりますか
- 記録ファイルとGitの履歴をもとに、完了済みのタスクを確かめて再開します。完了と記録されたタスクはやり直しません。続きを始めるのは、記録がないタスクからです。
- 別エージェントが使えない環境でもレビューはできますか
- できます。エージェントがレビュー手順を読み、自分でブランチ全体をレビューします。その場合は自己レビューだったことが記録と最終報告に書かれ、マージしてよいかは人が判断する形です。
- 実装中に何度も確認を求められますか
- 求められません。確認のために止まるのは、破壊的な操作やセキュリティに関わる操作、共有ブランチへのpushなど4つの場面だけです。計画の矛盾は自分で判断し、その内容を記録に残して進みます。
このスキルを試す
executing-plans の入れ方とインストールコマンドは、cccskills のスキルページにまとめてあります。
この記事は、公開されている SKILL.md と cccskills の紹介文をもとに AI(Claude)が下書きし、cccskills 編集部の方針に沿って推敲・公開しています。正確な仕様はスキルのページで原文を確認してください。
他の記事

Claude CodeでX投稿を自動化する ― x-apiスキルの使い方
x-apiスキルをClaude CodeやCodexに入れ、Xの投稿、スレッド公開、検索、反応の集計をAPIで進める方法を解説します。OAuth認証の準備、利用上限への対応、公開前の確認手順まで分かります。
x-apiaffaan-m

Philips Hueの照明をAIで操作する ― openhueスキルの使い方
Philips Hueの照明をClaude CodeやCodexから言葉で操作するopenhueスキルの紹介です。点灯・消灯、明るさ、色温度、部屋単位の操作、シーン切り替えの頼み方と、インストール手順、必要な準備が分かります。
openhueopenclaw

email-opsでメールの仕分け・返信下書き・送信確認をAIに任せる
email-opsは、AIエージェントに受信箱の仕分け、履歴を踏まえた返信の下書き、送信と送信済みの確認を任せるスキルです。使ったアカウントと対応状況が分かる結果の形、インストール方法、依頼文の例、注意点を紹介します。
email-opsaffaan-m