Executing Plans

CRITICAL CONSTRAINTS

You MUST NOT call EnterPlanMode or ExitPlanMode during this skill. This skill operates in normal mode, executing a plan that already exists on disk. Plan mode is unnecessary and dangerous here — it restricts Write/Edit tools needed for implementation.

Executing Plans

Overview

Load plan, review critically, execute all tasks, report when complete.

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

Note: Superpowers works best with subagent support. If subagents are available, use superpowers-extended-cc:subagent-driven-development instead of this skill.

Consulting the Plan Author

Once, at start: run ListAgents and check whether the plan-writing session is alive (the handoff prompt normally names it). If it is, note its name — on every ambiguity or design question during execution, ask IT via SendMessage before guessing and before interrupting your human partner. If it is not listed, ambiguities go to your human partner.

The Process

Step 0: Load Persisted Tasks

1. Call TaskList to check for existing native tasks
2. CRITICAL - Locate tasks file: Try <plan-path>.tasks.json, if not found glob for matching .tasks.json
3. If tasks file exists AND native tasks empty: recreate from JSON using TaskCreate:
   • Include full description from .tasks.json (not just subject)
   • Include metadata field if present (files, verifyCommand, acceptanceCriteria)
   • Restore blockedBy with TaskUpdate
4. If native tasks exist: verify they match plan, resume from first pending/in_progress
5. If neither: proceed to Step 1b to bootstrap from plan

Update .tasks.json after every task status change.

Step 0.5: Verify Workspace (Worktree Check)

Before calling using-git-worktrees, check if a worktree already exists:

1. Run git worktree list to see all existing worktrees
2. If a worktree for the plan's branch already exists: cd into it — do NOT create a new one
3. If on main/master with no worktree: REQUIRED SUB-SKILL: Use superpowers-extended-cc:using-git-worktrees to create one

Step 1: Load and Review Plan

1. Read plan file
2. Review critically - identify any questions or concerns about the plan
3. If concerns: Raise them with your human partner before starting
4. If no concerns: Proceed to task setup

Step 1b: Bootstrap Tasks from Plan (if needed)

If TaskList returned no tasks or tasks don't match plan:

1. Parse the plan document for ## Task N: or ### Task N: headers
2. For each task found, use TaskCreate with:
   • subject: The task title from the plan
   • description: Full structured content (Goal, Files, Acceptance Criteria, Verify, Steps) with json:metadata code fence at the end containing files, verifyCommand, acceptanceCriteria
   • activeForm: Present tense action (e.g., "Implementing X")
3. CRITICAL - Dependencies: For EACH task that has blockedBy in the plan or .tasks.json:
   • Call TaskUpdate with taskId and addBlockedBy: [list-of-blocking-task-ids]
   • Do NOT skip this step - dependencies are essential for correct execution order
4. Call TaskList and verify blockedBy relationships show correctly (e.g., "blocked by #1, #2")

Step 2: Execute Tasks

For each task:

1. Mark as in_progress
2. Follow each step exactly (plan has bite-sized steps)
3. Use metadata for verification: Parse the json:metadata code fence from the task description. Run verifyCommand and check each acceptanceCriteria before marking complete.
4. User-thrown gates are non-skippable. If the task's metadata has "userGate": true OR its tags array contains "user-gate", you MUST:
   • Execute the gate exactly as specified — no inline shortcut, no cheaper substitute, no "I already verified this informally".
   • Capture concrete output for every entry in acceptanceCriteria (command output, entity state, log line, subagent result).
   • If any criterion cannot be proven right now, leave the task in_progress and surface the blocker to the user. Do NOT close it.
   • Do not re-decide what the plan settled. A verification approach the plan already fixed may be re-surfaced to the user ONLY if a MATERIAL condition changed since planning: a different branch/fixture, a new blocker, or a broken plan assumption. Absent a changed condition, execute the settled verification as written. Pause for consent ONLY at the genuinely irreversible mechanical step (e.g. force-push / live merge), and frame that pause as "confirm this irreversible action," NEVER as "should we do the lesser check instead." Re-asking a settled approach with no changed condition is walking around the gate.
5. Mark as completed
6. Sync .tasks.json: Read the tasks file, update the task's "status" to "completed" (or "in_progress" in step 1), set "lastUpdated" to current ISO timestamp, write back. This keeps the persistence file in sync with native tasks for cross-session resume.

Step 3: Complete Development

After all tasks complete and verified:

• Announce: "I'm using the finishing-a-development-branch skill to complete this work."
• REQUIRED SUB-SKILL: Use superpowers-extended-cc:finishing-a-development-branch
• Follow that skill to verify tests, present options, execute choice

When to Stop and Ask for Help

STOP executing immediately when:

• Hit a blocker (missing dependency, test fails, instruction unclear)
• 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
• Stop when blocked, don't guess
• Never start implementation on main/master branch without explicit user consent

Integration

Required workflow skills:

• superpowers-extended-cc:using-git-worktrees - Ensures isolated workspace (creates one or verifies existing)
• superpowers-extended-cc:writing-plans - Creates the plan this skill executes
• superpowers-extended-cc:finishing-a-development-branch - Complete development after all tasks