Executing Implementation Plans with Claude Code ― executing-plans
機械翻訳 / Machine-translated
機械翻訳 / Machine-translated
Original article: Executing Implementation Plans with Claude Code ― executing-plans (cccskills)
Skill page: executing-plans
Key takeaways from this article
With executing-plans, an agent such as Claude Code can implement a finished implementation plan task by task within the same session.
It is designed to record test results and decisions as it proceeds all the way to the end.
This article covers the workflow, how to install it, example prompts, and notes on worktrees and related skills.
When you hand over a finished implementation plan, the agent itself implements the tasks one by one through to the end.
Test results and decisions are also recorded as work progresses.
A single instruction like the following is all you need.
Please carry out the implementation plan in docs/plans/search.md to completion within this session.
The first thing it does is prepare.
The agent sets up a worktree (a Git mechanism for isolating working areas), reads the plan, and checks for any mismatches in handoffs between tasks.
For each task, it starts by writing a test and confirming it fails.
It then implements the solution, confirms the test passes, and commits according to the plan.
Only tasks whose tests pass are marked as "complete" in the progress log.
Each entry includes the commit range and test results.
Once all tasks are done, it moves on to a full branch review.
The final message contains two lists: "Rulings I made" (decisions taken during implementation) and "Deferred minors" (issues set aside for later).
This gives you everything you need to check in one place.
executing-plans is a skill that lets the agent you are currently talking to implement the plan itself within the same session, without spinning up a separate implementation agent.
There is no dedicated implementation agent or review agent per task — the review happens just once, covering the entire branch at the end.
Quality is maintained through three mechanisms instead: testing, logging, and a final review.
The acceptance criterion for each task is a passing test.
The agent writes the test first, actually observes it failing, then implements the solution and confirms the test passes.
Any test that already passes before implementation is treated as a problem with the test itself.
Each command in the plan has an expected output, and the agent compares actual output against it one by one.
When there is a discrepancy, there are two possible responses depending on the cause.
If the code is at fault, systematic-debugging is used to find the root cause; if the plan is at fault, the decision is logged and work continues.
It is this skill's policy not to pause between tasks to ask "May I continue?"
When the plan contains contradictions or ambiguities, the agent resolves them on its own.
Each decision — the content, the reasoning, and the impact if it turns out to be wrong — is recorded in a single line before moving on.
Work stops to ask a human only in four situations:
Any deviation from the plan that is not logged is considered a "hidden decision," so all changes are always recorded.
Even if the conversation is summarized and context fades, work can continue using the log file and Git history.
Tasks already marked complete are not redone; work resumes from the first incomplete task.
When the log and the agent's own memory conflict, the log and git log take precedence.
Logs are stored in a folder outside Git's tracking, organized per plan.
Logs for other plans are never touched.
Because the location and format are the same as those used by subagent-driven-development, switching approaches mid-way still allows work to resume from the same log.
The final step is a review of the entire branch.
In environments where a separate agent can be invoked, the highest-capability model is explicitly specified for the reviewer role.
In environments where that is not possible, the agent reviews its own work, and the fact that it was a self-review is recorded in both the log and the final report.
Findings are sorted by severity, and only critical and important items are fixed together in a single pass.
For each fix, a reproducing test is written, the failure is observed, and then the fix is applied.
Afterward, the full test suite is confirmed to pass.
This skill is best suited to three situations:
When you want a review between each task, subagent-driven-development is recommended instead.
The same applies when the plan is long and later tasks will run on summarized context.
A log makes recovery possible even in a long plan, but the agent's available capacity decreases with each later task.
If the plan is sufficiently detailed, implementation can be handled by a mid-tier model.
The highest-performance model is only needed for the final review.
There are two ways to install: run a single command, or send a message asking the agent to do it.
The command uses npx skills add and lets you choose the target agent, such as Claude Code or Codex.
npx skills add https://github.com/obra/superpowers --skill executing-plans
If you prefer to ask the agent, send the following message as-is.
The agent will handle everything from reviewing the contents to placing the files.
次の 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/ に配置してください。
The installation locations are as follows:
| Agent | For all projects | For a specific project only |
|---|---|---|
| Claude Code | ~/.claude/skills/ | .claude/skills/ in the project |
| Codex | ~/.agents/skills/ | .agents/skills/ in the project |
The source is obra/superpowers on GitHub.
A prompt simply needs to specify the plan file and briefly state how you want to proceed.
Please carry out this implementation plan in the same session and log the test results for each task.
The agent starts by checking the worktree, then implements tasks in order while verifying test failures and successes.
Each time a task is completed, one more "complete" line is added to the log.
That line contains the commit range and the test results.
Please check the progress log and resume from the first incomplete task.
The first thing it checks is whether the first line of the log belongs to the same plan.
It then skips completed tasks and continues from the first incomplete one.
If the log turns out to belong to a different plan, it leaves that log untouched and starts a new one.
Please review the entire branch after all tasks are complete.
What you get back is a review sorted by severity, along with fixes.
Critical and important findings are addressed with accompanying tests, while minor findings are listed in "Deferred minors" in the final report.
The most essential prerequisite is having a concrete, finished plan.
This skill handles execution — it is not designed for the planning stage.
The more each step in the plan includes tests and expected outputs, the more reliably it will proceed.
It is also important to note that this skill assumes other skills in the same repository will be called.
SKILL.md specifies that test-driven-development must be loaded before the first task begins.
Similarly, using-git-worktrees is specified for setting up the worktree.
The scripts bundled with subagent-driven-development are used to create the working folder and review materials.
The final review follows the requesting-code-review procedure, and the wrap-up follows finishing-a-development-branch.
The assumption is that the related superpowers skills are installed alongside executing-plans.
There are also a few rules around Git.
The agent will not begin implementation on the main or master branch without explicit human consent.
The folder where logs are stored is outside Git's tracking, so it will be wiped by git clean -fdx.
If that happens, the procedure is to reconstruct from Git history.
The license is MIT.
The bundled files are SKILL.md and two scripts: scripts/task-start and scripts/task-done.
Please read them before installing to verify what they do.
Skills used before and after executing-plans are all gathered in the same superpowers repository.
subagent-driven-development is better suited when you want a review between each task or when the plan is long.
executing-plans is the right choice when you want to keep costs down and proceed in the same session, or when your environment does not support calling a separate agent.
Both share the same log format, and switching between them mid-way is supported.
It checks the log file and Git history to identify completed tasks, then resumes from there.
Tasks already marked complete are not redone.
Work resumes from the first task that has no log entry.
Yes.
The agent reads the review procedure and reviews the entire branch itself.
In that case, the fact that it was a self-review is noted in both the log and the final report, and the decision of whether to merge is left to a human.
No.
Work stops for confirmation only in four situations: destructive operations, security-related operations, pushing to a shared branch, and similar cases.
Contradictions in the plan are resolved by the agent itself, and the decisions are logged before moving on.
executing-plans is a skill that lets an agent implement a finished implementation plan from start to finish within the same session.
By writing tests first, confirming failures, then implementing and logging decisions and progress, work can resume from incomplete tasks even if the conversation is interrupted.
At the end, the entire branch is reviewed, and you receive a list of decisions made and a list of deferred minor items.
Start with a small plan containing just a few tasks to get a feel for the logging and review workflow.
A detailed introduction is available on the cccskills page.
This article is a reprint of the cccskills feature article "Executing Implementation Plans with Claude Code ― executing-plans."
Full details on the skill and installation instructions can be found on the cccskills executing-plans page.