Executing Plans

Overview

Load plan, review critically, execute tasks in batches, report for review between batches.

Core principle: Batch execution with checkpoints for architect review.

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

The Process

Step 0: Verify Isolation Context

Before loading plan:

1. •

   Check current git context:

   bash

   git branch --show-current
   git worktree list
   

2. •

   If on main/master without worktree: Use AskUserQuestion:

   code

   Question: "You're on the main branch. Plans should execute in isolated worktrees to protect main."
   Header: "Isolation"
   Options:
   - "Set up worktree": Create isolated workspace first (recommended)
   - "Continue on main": I understand the risk, proceed anyway
   

3. •

   If "Set up worktree": Use workflow:git-worktrees skill first

4. •

   If "Continue on main": Proceed with warning logged

5. •

   If already in worktree or feature branch: Proceed normally

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: Create TodoWrite with:
   • •All tasks from the plan
   • •MANDATORY FINAL TODO: "Complete development (finish-branch)" - this ensures finish-branch is invoked after all tasks complete

Step 2: Execute Batch

Default: First 3 tasks

For each task, check its Complexity tag and execute accordingly:

TRIVIAL Tasks (delete, rename, typo, config)

1. •Mark as in_progress
2. •Execute the change directly (no TDD - nothing to test)
3. •Verify with git diff that change is correct
4. •Mark as completed
5. •Skip code review - parent agent verifies git diff directly

Rationale: TDD/review overhead exceeds task value for trivial changes.

SIMPLE Tasks (small refactor, single-file)

1. •Mark as in_progress
2. •If modifying production code: Use core:tdd skill (write test first)
3. •If config/docs only: Skip TDD
4. •Run verifications as specified
5. •Mark as completed
6. •Lightweight review: Check git diff, no subagent needed

MODERATE Tasks (features, bug fixes)

1. •Mark as in_progress
2. •Use core:tdd skill - Write failing test FIRST, then implement
3. •Follow each step exactly
4. •Run verifications as specified
5. •Use core:verification skill - Verify tests pass
6. •Mark as completed
7. •Dispatch code-reviewer (Sonnet model)

COMPLEX Tasks (multi-file, architectural)

1. •Mark as in_progress
2. •Use core:tdd skill - Write failing test FIRST, then implement
3. •Follow each step exactly
4. •Run verifications as specified
5. •Use core:verification skill - Verify tests pass
6. •Mark as completed
7. •Dispatch code-reviewer (Opus model for thorough review)

IMPORTANT: Match execution overhead to task complexity. TRIVIAL tasks should complete in 2-3 tool uses, not 11.

Step 3: Code Review After Batch

Review strategy based on batch complexity:

Batches with TRIVIAL/SIMPLE tasks only

• •Parent agent reviews git diff directly
• •Verify changes match plan requirements
• •No subagent dispatch needed

git diff --stat [BASE_SHA]..[HEAD_SHA]
git diff [BASE_SHA]..[HEAD_SHA]

Check: Does the diff match what was requested? Any unintended changes?

Batches with MODERATE/COMPLEX tasks

Dispatch code-reviewer subagent:

Use template at plugins/methodology/review/templates/code-reviewer-dispatch.md.

Task tool (review:code-reviewer):
  description: "Review Batch [N] implementation"
  prompt: |
    Review the implementation against requirements.

    ## Context
    - **What Was Implemented:** [Summary of tasks completed in this batch]
    - **Requirements/Plan:** Tasks [N-M] from [plan-file]
    - **Description:** Batch [N] - [brief summary of work]

    ## Git Range
    - **Base:** [commit before batch started]
    - **Head:** [current commit after batch]

    First run: git diff --stat [BASE_SHA]..[HEAD_SHA]
    Then review against plugins/methodology/review/references/code-review-standards.md

Code reviewer returns: Strengths, Issues (Critical/Important/Minor), Assessment

Mixed batches

Review at the level of the most complex task in the batch.

If Critical or Important issues found:

1. •Address issues before proceeding
2. •Re-run verification after fixes
3. •Do NOT proceed to user feedback until resolved

If only Minor issues:

• •Note for later
• •Proceed to Step 4

Step 4: Report and Request Feedback

After code review passes:

• •Show what was implemented
• •Show verification output
• •Show code review summary (issues found and resolved)
• •Use the AskUserQuestion tool (do NOT output as plain text):

Question: "Batch [N] complete. How should I proceed?" Header: "Next step" Options:

• •Continue: Proceed to next batch
• •Review changes: Show diffs or re-explain what was done
• •Make adjustments: Apply corrections before continuing multiSelect: false

Wait for user response before proceeding.

Step 5: Continue

Based on feedback:

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

Step 6: Complete Development

After all plan tasks complete and verified:

1. •Mark the "Complete development (finish-branch)" todo as in_progress
2. •Announce: "I'm using the finish-branch skill to complete this work."
3. •REQUIRED: Use Skill("workflow:finish-branch")
4. •Follow that skill to verify tests, present options, execute choice
5. •Mark the "Complete development (finish-branch)" todo as completed

This step is NOT optional. The mandatory final todo ensures this step is visible throughout execution.

When to Stop and Ask for Help

STOP executing immediately when:

• •Hit a blocker mid-batch (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
• •Between batches: use AskUserQuestion to get explicit feedback
• •Stop when blocked, don't guess

Integration

Required skills for task execution:

• •tdd - REQUIRED: Use core:tdd for each task (write test first)
• •verification - REQUIRED: Use core:verification before marking tasks complete

Required workflow skills:

• •git-worktrees - Use workflow:git-worktrees for isolation when on main/master (see Step 0)
• •code-review - Use review:code-review after each batch (see Step 3)
• •finish-branch - REQUIRED: Use workflow:finish-branch after all tasks (see Step 6)

Alternative workflow:

• •subagent-dev - Use for same-session execution with fresh subagents per task