domains / software-engineering / execute-implementation-plan / executing-plans

executing-plans

Skill card

combined

The copies describe two different execution models. obra/superpowers is an inline, continuous-execution skill with a ledger, TDD gates, and a single final review. The other three copies (sickn33, LeoYeAI, FreedomIntelligence) are a batched, checkpoint-driven skill that pauses for review between batches. They overlap in the high-level goal (execute a written plan) but disagree on batching, stopping behavior, and required sub-skills, so crowning one would hide a real alternative.

Repositories

Other copies

Combined skill

# Executing Plans

## Overview
Execute a written implementation plan. Choose the execution mode based on the user's instruction and the plan's characteristics.

**Announce at start:** "I'm using the executing-plans skill to implement this plan."

## Execution Modes

### Mode A: Inline Continuous (from obra/superpowers)
Use when the user chose inline execution, no subagent tool is available, or tasks are mostly independent and the plan is fully specified.

**Core principle:** The plan already did the thinking. Execute it exactly, prove each step with a test you watched fail and then pass, and leave a record that survives your own forgetting.

**Process:**
1. **Setup:** Set up worktree, workspace + ledger, read plan + spec, pre-flight scan.
2. **Per Task:**
   - Read the brief and BASE.
   - Work the steps in order: TDD, run every verification, read every output.
   - If step output does not match plan's Expected: if plan is wrong, rule and ledger; if code is wrong, use systematic-debugging.
   - Commit as the plan's commit steps say.
   - Check completion contract. If met, run tests, ledger the result, mark todo complete.
   - If not met, finish the task.
3. **Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping.
4. **Rulings, not stalls:** Conflicts, ambiguities, plan defects — decide them. Record every decision in the ledger as `Ruling: <what you decided> — <why> — <what it costs if wrong>`, and keep going.
5. **Four things stop you, and only these:** an irreversible or destructive operation; a security-sensitive action; a side effect outside this worktree that norms say you ask about first (a merge, a push to a shared branch, a publish); and a plan so broken that every path forward is a guess. For those, stop and ask.
6. **Final whole-branch review:** Dispatch a fresh reviewer if you have one. Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger.
7. **Final review clean:** Delete this plan's workspace.
8. **Use finishing-a-development-branch skill** to complete the work.

### Mode B: Batched with Checkpoints (from sickn33, LeoYeAI, FreedomIntelligence)
Use when the user wants review checkpoints between batches, or when the plan is long enough that later tasks would run on a compacted context.

**Core principle:** Batch execution with checkpoints for architect review.

**Process:**
1. **Load and Review Plan:**
   - Read plan file.
   - Review critically - identify any questions or concerns about the plan.
   - If concerns: Raise them with your human partner before starting.
   - If no concerns: Create TodoWrite (or use the project's existing task/todo mechanism) and proceed.
2. **Execute Batch:**
   - Batch size follows the user's explicit instruction or project contract; otherwise choose a practical reviewable group (default: first 3 tasks).
   - For each task:
     - Mark as in_progress.
     - Follow each step exactly (plan has bite-sized steps).
     - Run verifications as specified.
     - Mark as completed.
3. **Report:**
   - When batch complete: Show what was implemented, show verification output.
   - Continue to the next authorized batch unless the user explicitly requested a checkpoint; provide concise progress without ending the task unnecessarily.
4. **Continue:**
   - Based on feedback: Apply changes if needed, execute next batch, repeat until complete.
5. **Complete Development:**
   - After all tasks complete and verified: Announce: "I'm using the finishing-a-development-branch skill to complete this work."
   - Use the actually available finishing-a-development-branch skill only when appropriate; repository-specific maintainer/merge workflows take precedence. Do not invent a superpowers plugin dependency.
   - Follow that skill to verify tests, present options, execute choice.

## When to Stop and Ask for Help

**Pause only the dependent step when an indispensable input/authorization or unresolved external blocker prevents it; preserve independent work. Repair ordinary failures autonomously.**

Examples of issues to investigate include:
- A missing dependency or failing test: inspect the actual cause and attempt relevant repair; it is not automatically a reason to stop.
- Plan has critical gaps preventing starting.
- You don't understand an instruction.
- Verification fails repeatedly.

**Ask for clarification rather than guessing.**

## When to Revisit Earlier Steps

**Return to Review (Step 1) when:**
- Partner updates the plan based on your feedback.
- Fundamental approach needs rethinking.

**Don't force through blockers** - stop and ask.

## Remember
- Review plan critically first.
- Follow plan steps exactly.
- Don't skip verifications.
- Reference skills when plan says to.
- Between batches: follow the user's authorized cadence and continue when no required checkpoint remains.
- Stop when blocked, don't guess.
- Never start implementation on main/master branch without explicit user consent.

## Integration

**Required workflow skills:**
- **using-git-worktrees** - Set up isolated workspace before starting.
- **writing-plans** - Creates the plan this skill executes.
- **finishing-a-development-branch** - Complete development after all tasks.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.