Execute development plans in batches with checkpoint reviews

Executing Plans is a skill for carrying out a written implementation plan in a separate session, with review checkpoints. Its overview is a single line: load the plan, review it critically, execute tasks in batches, and report for review between batches. The core principle is batch execution with checkpoints for architect review. When it starts, the agent announces that it is using the executing-plans skill to implement the plan.

The process has five steps.

Step 1, load and review the plan. Read the plan file and review it critically, identifying any questions or concerns. If there are concerns, raise them with your human partner before starting. If there are none, create a TodoWrite list and proceed.

Step 2, execute a batch. The default batch is the first three tasks. For each task, mark it as in_progress, follow each step exactly because the plan has bite-sized steps, run the verifications as specified, and mark the task as completed.

Step 3, report. When the batch is complete, show what was implemented, show the verification output, and say "Ready for feedback."

Step 4, continue. Based on the feedback, apply changes if needed, execute the next batch, and repeat until the plan is complete.

Step 5, complete development. After all tasks are complete and verified, announce that you are using the finishing-a-development-branch skill. That skill is a required sub-skill, referenced as superpowers:finishing-a-development-branch, and following it verifies tests, presents options and executes the chosen option.

Use it when you already have a written implementation plan to execute, especially in a separate session where a human wants to review progress between batches.

The skill is explicit about when to stop and ask for help. Stop executing immediately when you hit a blocker mid-batch, such as a missing dependency, a failing test or an unclear instruction. Stop when the plan has critical gaps that prevent starting, when you do not understand an instruction, or when verification fails repeatedly. Ask for clarification rather than guessing.

Go back to the review step when the partner updates the plan based on your feedback, or when the fundamental approach needs rethinking. Do not force your way through blockers.

The input is a plan file whose tasks are broken into small steps, each with its own verification. The outputs after every batch are a summary of what was implemented and the verification results, followed by a request for feedback. Between batches the agent only reports and waits, and it does not continue on its own.

The skill closes with a short set of reminders: review the plan critically first, follow the plan steps exactly, do not skip verifications, reference other skills when the plan says to, and stop when blocked rather than guess. You can invoke it by naming it in a request, for example asking to use executing-plans for a task that has a written plan and review checkpoints.

The Limitations section adds three boundaries: use the skill only when the task clearly matches this scope, do not treat its output as a substitute for environment-specific validation, testing or expert review, and stop and ask if required inputs, permissions, safety boundaries or success criteria are missing.

The skill is aimed at developers who split planning and implementation between sessions, and at teams that want an agent to execute in controlled batches with a human review after each one. Its metadata lists a community source.