Executing Plans

Announce: "Using executing-plans skill to implement this plan."

Invariant Principles

1. •Plan Fidelity: Follow plan steps exactly. Plans encode architect decisions; deviation creates drift. If plan seems wrong, ask - don't silently reinterpret.
2. •Evidence Over Claims: Every task completion requires verification output. Never mark complete without proof. "I ran the tests" without showing output is not evidence.
3. •Blocking Over Guessing: Uncertainty must halt execution. Wrong guesses compound; asking costs one exchange.
4. •Review Before Proceed: No task advances past unaddressed review findings. Spec compliance precedes code quality.
5. •Context Completeness: Subagents receive full task text, never file references. Fresh contexts lack your accumulated knowledge.

Inputs

Outputs

Mode Selection

Use batch when: Architect wants review between batches, tasks tightly coupled, plan needs active discussion.

Use subagent when: Tasks mostly independent, faster iteration desired, want automated spec+quality review.

Autonomous Mode

Check for "Mode: AUTONOMOUS" or explicit autonomous instruction.

Skip: Plan concerns (log for later), "ready for feedback" checkpoints, completion confirmations.

Auto-decide: Batch size (default 3), implementation details (document choice), applying review fixes.

When subagent asks scope question in autonomous mode, MUST use AskUserQuestion:

AskUserQuestion({
  questions: [{
    question: "Implementer asks: 'Should this also handle X case?' This affects scope.",
    header: "Scope",
    options: [
      { label: "Yes, include X", description: "Expand scope" },
      { label: "No, exclude X (Recommended)", description: "Keep minimal per YAGNI" },
      { label: "Defer to future task", description: "Note for later" }
    ]
  }]
})

Batch Mode Process

Phase 1: Load and Review Plan

1. •Read plan file
2. •Review critically - identify questions/concerns
3. •If concerns:
   javascript

   AskUserQuestion({
     questions: [{
       question: "Found [N] concerns with the plan. How should we proceed?",
       header: "Plan Review",
       options: [
         { label: "Discuss concerns", description: "Review each before starting" },
         { label: "Proceed anyway (Recommended if minor)", description: "Address as they arise" },
         { label: "Update plan first", description: "Revise to address concerns" }
       ]
     }]
   })
   

4. •If no concerns: Create TodoWrite and proceed

Phase 2: Execute Batch

Default first 3 tasks. Per task:

1. •Mark as in_progress
2. •Follow each step exactly (plan has bite-sized steps)
3. •Run verifications as specified
4. •Mark as completed with evidence

Phase 3: Report

When batch complete:

• •Show what was implemented
• •Show verification output
• •Say: "Ready for feedback."

Phase 4: Continue

Based on feedback:

• •Apply changes if needed
• •Execute next batch
• •Repeat until complete

Phase 5: Complete Development

• •Announce: "Using finishing-a-development-branch skill to complete this work."
• •REQUIRED: Invoke finishing-a-development-branch skill

Subagent Mode Process

Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.

Phase 1: Extract Tasks

Read plan once. Extract all tasks with full text and context. Create TodoWrite.

Phase 2: Per-Task Execution Loop

For each task:

1. •Dispatch implementer subagent (use ./implementer-prompt.md)
2. •Answer questions if implementer asks any - answer clearly and completely
3. •Implementer implements, tests, commits, self-reviews
4. •Dispatch spec reviewer (./spec-reviewer-prompt.md)
   • •If issues found: implementer fixes, re-review
   • •Loop until spec compliant
5. •Dispatch code quality reviewer (./code-quality-reviewer-prompt.md)
   • •If issues found: implementer fixes, re-review
   • •Loop until approved
6. •Mark task complete in TodoWrite

Phase 3: Final Review

Dispatch final code reviewer for entire implementation.

Phase 4: Complete Development

• •Announce: "Using finishing-a-development-branch skill to complete this work."
• •REQUIRED: Invoke finishing-a-development-branch skill

Stop Conditions

Ask for clarification rather than guessing. The cost of asking is one exchange. The cost of guessing wrong is cascade failure. </CRITICAL>

Anti-Patterns

Handling Subagent Questions

• •Answer clearly and completely before letting them proceed
• •Provide additional context if task references things they don't know
• •If question affects scope: use AskUserQuestion (see circuit breakers)
• •Don't rush implementation; incomplete answers cause rework

Handling Review Issues

• •Implementer (same subagent) fixes issues
• •Reviewer reviews again (never skip re-review)
• •Loop until approved
• •If 3+ cycles: escalate to user

Handling Subagent Failure

• •Dispatch fix subagent with specific instructions
• •Don't fix manually (context pollution)
• •Provide failure context and expected behavior

Self-Check

Before marking execution complete:

• • Every task has verification output shown (tests, build, runtime)
• • No tasks marked complete without evidence
• • All review issues addressed (spec and code quality)
• • Plan followed exactly or deviations explicitly approved
• • finishing-a-development-branch invoked

When to Revisit Earlier Steps

Return to Phase 1 (Load Plan) when:

• •User updates plan based on your feedback
• •Fundamental approach needs rethinking
• •Critical gap discovered mid-execution

Don't force through blockers - stop and ask.

Integration

Required workflow skills:

• •writing-plans - Creates the plan this skill executes
• •requesting-code-review - Code review template for reviewer subagents
• •finishing-a-development-branch - Complete development after all tasks

Subagents should use:

• •test-driven-development - Subagents follow TDD for each task

<FINAL_EMPHASIS> Plans are contracts. Evidence is required. Guessing is forbidden. Your reputation depends on executing faithfully, stopping when uncertain, and never marking complete without proof. </FINAL_EMPHASIS>