Executing Plans

Overview

This skill turns an approved plan document into working code through disciplined, batch-based execution. Each step is implemented with TDD, verified before proceeding, and reviewed at checkpoints. It provides the structural framework for moving from plan to production code with consistent quality gates.

Announce at start: "I'm using the executing-plans skill to implement the approved plan at [plan path]."

Trigger Conditions

An approved plan document exists and is ready for implementation
/execute command invoked with a plan reference
Resuming a partially completed plan execution
Transition from planning skill after plan approval

Phase 1: Read the Plan

Goal: Thoroughly understand the plan before writing any code.

Read the entire plan document from start to finish
Identify all implementation steps and count them
Map dependencies between steps (what must be done first)
Note any ambiguities or open questions
Confirm understanding with the user before proceeding

Plan Comprehension Checklist

Check	Question
Goal clarity	Can you explain the plan's goal in one sentence?
Step count	How many implementation steps are there?
Dependencies	Which steps depend on which?
Ambiguities	Are there any unclear or underspecified steps?
Verification	Does every step have a verification method?

STOP — Do NOT proceed to Phase 2 until:

You can explain the plan's goal in one sentence
You can list all implementation steps
Dependencies are mapped
Any ambiguities are noted and resolved with user
User has confirmed you may proceed

Phase 2: Create Task Batch

Goal: Break the plan into small, executable task batches.

Batch Size Decision Table

Task Complexity	Batch Size	Examples
Simple (config, boilerplate)	Up to 5 tasks	ENV vars, imports, type definitions
Standard (features, logic)	3 tasks	Endpoints, services, components
Complex (integrations, security)	2 tasks	OAuth flows, payment processing
Critical (data migration, auth)	1 task	Database migrations, credential handling

Task Requirements (STIC)

Criterion	Description
Specific	Clear definition of what to implement
Testable	Can be verified with automated tests
Independent	Minimal coupling to other tasks in the batch (where possible)
Compact	Completable in a focused session (2-5 minutes)

Task Template

Task: [concise description]
Plan Step: [reference to plan section]
Files to Create/Modify: [list of exact file paths]
Acceptance Criteria:
  - [specific, testable criterion 1]
  - [specific, testable criterion 2]
Dependencies: [other tasks that must be done first, or "none"]
Verification: [exact command to run]

STOP — Do NOT proceed to Phase 3 until:

Tasks created for the current batch
Each task has clear acceptance criteria
Dependencies are satisfied (previous tasks complete)
Tasks ordered by dependency (independent tasks first)

Phase 3: Execute Tasks

Goal: Execute each task one at a time using TDD.

Per-Task Workflow

1. ANNOUNCE which task you are starting
2. IMPLEMENT using test-driven-development skill:
   a. Write failing test (RED)
   b. Write minimal code to pass (GREEN)
   c. Refactor (REFACTOR)
   d. Repeat RED-GREEN-REFACTOR for each behavior
3. VERIFY using verification-before-completion skill:
   a. Run full test suite (not just new tests)
   b. Run lint, type-check, build as applicable
   c. Confirm all checks pass
4. MARK task as complete
5. PROCEED to next task

Execution Rules

Rule	Rationale
One task at a time	Do not start task 2 until task 1 is verified
Follow TDD strictly	No production code without a failing test
Do not deviate from the plan	If plan needs changes, stop and discuss with user
Do not skip verification	Every task must pass verification before marking complete
Report progress	Announce start and completion of each task

Task Outcome Decision Table

Outcome	Action	Next Step
Verification passes	Mark complete	Next task
Test failure, obvious fix	Fix and re-verify	Same task
Test failure, unclear cause	Invoke `systematic-debugging`	Same task after fix
Plan step is ambiguous	Stop and ask user	Wait for clarification
Plan step is not feasible	Report blocker	Wait for direction
Unexpected dependency found	Report and reorder	Adjust batch

STOP — Do NOT proceed to next task until:

Current task's acceptance criteria are met
All tests pass (new and existing)
Verification-before-completion has been executed
Task marked as complete

Phase 4: Batch Checkpoint

Goal: After completing all tasks in a batch, perform a full checkpoint review.

Checkpoint Steps

Run full test suite — all tests, not just those from the current batch
Run all verification commands — lint, type-check, build, format
Review what was implemented — summarize completed tasks and outcomes
Assess progress against the plan — how far through are we?
Identify any issues or risks that came up during execution
Report to user and ask for direction

Checkpoint Report Template

BATCH CHECKPOINT
================
Batch: [N] of [estimated total]
Tasks Completed: [list]

Verification Results:
  Tests:      [X passed, Y failed, Z skipped]
  Build:      [pass/fail]
  Lint:       [pass/fail, N warnings]
  Type-check: [pass/fail]

Progress: [N of M plan steps complete] ([percentage]%)

Issues Encountered:
  - [issue 1 and how it was resolved]

Risks or Concerns:
  - [risk 1]

Next Batch Preview:
  - [task 1]
  - [task 2]
  - [task 3]

Awaiting direction: Continue with next batch / Adjust plan / Other?

STOP — Do NOT proceed to next batch until:

Full test suite passes
All verification commands pass
Checkpoint report presented to user
User has confirmed to continue

Phase 5: Continue, Adjust, or Complete

Goal: Act on user direction after each checkpoint.

Direction Decision Table

User Direction	Action	Next Phase
"Continue"	Create next batch of tasks	Phase 2
"Adjust plan"	Discuss changes, update plan document	Phase 2 (with updated plan)
"Stop here"	Summarize progress, note remaining work	Completion
"Skip ahead to [step]"	Verify dependencies are met, then jump	Phase 2 (at new step)
"Go back and redo [task]"	Revert if needed, re-execute with corrections	Phase 3

Never proceed to the next batch without explicit user approval.

Critical Blocker Handling

When you encounter something that prevents task completion, do NOT work around it. Stop and escalate.

Blocker Classification

Type	Examples	Action
Ambiguous spec	Plan step could mean multiple things	Present interpretations, ask user
Missing dependency	Required API or library unavailable	Report with alternatives
Contradiction	Step conflicts with another part of the plan	Identify both sides, ask user
Security concern	Planned approach has vulnerability	Report risk, propose safer alternative
Feasibility	Step cannot be implemented as described	Explain why, propose alternatives

Blocker Report Format

CRITICAL BLOCKER
================
Task: [which task is blocked]
Blocker: [clear description of the problem]
Impact: [what cannot proceed until this is resolved]
Options:
  A. [option with tradeoffs]
  B. [option with tradeoffs]
  C. [skip this step and continue]

Awaiting direction before proceeding.

Do NOT guess what the user intended. Do NOT implement a workaround without approval. Do NOT skip the blocked task silently. DO present options with clear tradeoffs. DO continue with non-blocked tasks if possible (but flag the skip).

Subagent Dispatch Option

For larger plans, individual tasks can be dispatched to subagents for parallel execution.

When to Suggest Subagent Dispatch

Condition	Threshold
Independent tasks in plan	10+ tasks with few dependencies
Task specification quality	Each task has clear acceptance criteria
Speed requirement	User has indicated urgency
Task interdependency	Low coupling between tasks

When conditions are met, suggest switching to the subagent-driven-development skill for the remaining work.

Anti-Patterns / Common Mistakes

Anti-Pattern	Why It Fails	Correct Approach
Implementing entire plan at once	No checkpoints, no quality gates	Batch-based execution with checkpoints
Skipping TDD because "it's simple"	Bugs accumulate, regressions appear	Every task uses TDD, no exceptions
Working around blockers silently	User unaware, wrong assumptions baked in	Stop and escalate blockers
Proceeding without approval after batch	Direction may have changed	Always checkpoint and wait
Deviating from the plan	Unauthorized changes, scope creep	Discuss changes before implementing
Running only new tests	Regressions go undetected	Full test suite at checkpoints
Marking tasks complete without verification	False progress, accumulated bugs	Verification is mandatory
Batches larger than 5 tasks	Hard to review, too much risk per batch	Keep batches small
Skipping checkpoint report	User loses visibility into progress	Always present full checkpoint
Not committing at batch boundaries	Huge diffs, hard to revert	Commit after each batch

Anti-Rationalization Guards

If you catch yourself thinking:

"I know what comes next, I'll skip the checkpoint..." — No. Report and wait.
"This verification is redundant..." — Run it anyway. Fresh evidence only.
"The plan is close enough, I'll adjust as I go..." — Discuss adjustments first.

Subagent Dispatch Opportunities

Task Pattern	Dispatch To	When
Independent plan steps with no shared state	Parallel subagents via `Agent` tool	When dependency analysis shows no blockers between steps
Code review of completed step	`code-reviewer` agent	After each major plan step completion
Test execution for completed features	Background `Bash` task	When tests can run independently of ongoing work

Follow the dispatching-parallel-agents skill protocol when dispatching.

Integration Points

Skill	Relationship	When
`planning`	Upstream — provides approved plan document	Plan is the input to this skill
`test-driven-development`	Per-task — TDD cycle for every code task	Phase 3 execution
`verification-before-completion`	Per-task — verification gate	Before marking any task complete
`systematic-debugging`	On failure — investigate unexpected failures	When task encounters errors
`code-review`	At checkpoints — review code quality	Phase 4 batch review
`subagent-driven-development`	Alternative — parallel execution path	For large independent task sets
`resilient-execution`	On failure — retry with alternatives	When task approaches fail
`task-management`	Complementary — provides task tracking	Can be used together

Concrete Examples

Example: Batch Creation from Plan

Plan: "Add user authentication with JWT"

Batch 1 (3 tasks):
  Task 1: Write failing test for JWT token generation
    Files: tests/auth/jwt.test.ts
    Verification: npm test -- --grep "JWT generation" → FAIL (expected)

  Task 2: Implement JWT token generation
    Files: src/auth/jwt.ts
    Verification: npm test -- --grep "JWT generation" → PASS

  Task 3: Write failing test for auth middleware
    Files: tests/middleware/auth.test.ts
    Verification: npm test -- --grep "auth middleware" → FAIL (expected)

[CHECKPOINT after batch 1]

Batch 2 (3 tasks):
  Task 4: Implement auth middleware
  Task 5: Write failing test for login endpoint
  Task 6: Implement login endpoint

[CHECKPOINT after batch 2]

Completion Criteria

The plan execution is complete when:

All plan steps have been implemented as tasks
All tasks have passed verification
Full test suite passes
Final checkpoint report presented to user
User confirms the plan is complete

Skill Type

RIGID — Follow this process exactly. Batches, checkpoints, and verification gates are non-negotiable. No task is complete without verification. No batch proceeds without user approval.