Executing Plans

Iron Law: One task → Checkpoint → STOP → User reviews → Next task. No batching. No "just one more."

When to Use

• Epic Task exists with subtasks ready to execute
• Resuming implementation after a previous checkpoint
• Need to implement features iteratively with human oversight
• After gambit:writing-plans or gambit:brainstorming creates tasks

Don't use when:

• No epic exists → use gambit:brainstorming or gambit:writing-plans
• Debugging a bug → use gambit:debugging
• Single quick fix → just do it

The Process

0. Resumption Check (Every Invocation)

Run TaskList and analyze:

• Fresh start: All tasks "pending", none "in_progress" → Step 1
• Resume in-progress: Found task with status="in_progress" → Step 2
• Start next: Previous completed, next "pending" with empty blockedBy → Step 1 then 2
• All done: All subtasks "completed" → Step 5 (final validation)

Do NOT ask "where did we leave off?" — Task state tells you exactly where to resume.

1. Load Epic Context

Before executing ANY task, read the epic with TaskGet.

Extract and keep in mind:

• Requirements (IMMUTABLE — never water these down)
• Success criteria (validation checklist)
• Anti-patterns (FORBIDDEN shortcuts)
• Approaches Considered (what was already REJECTED and why)

Why: Requirements prevent rationalizing shortcuts when implementation gets hard.

2. Execute Current Ready Task

Find and claim:

1. TaskList → identify ready task (status="pending", blockedBy=[])
2. TaskUpdate → mark in_progress
3. TaskGet → load full task details

Execute the steps in the task description:

Task descriptions contain bite-sized steps. For each:

1. Follow TDD cycle: write test → watch it FAIL → write minimal code → watch it PASS → refactor → commit
   • Iron law: no production code without a failing test first. Wrote code before the test? Delete it. Start over. Don't keep it as "reference."
   • If test passes immediately, STOP — test doesn't catch the new behavior. Fix the test.
   • GREEN means minimal: no features the test doesn't exercise, no error handling it doesn't check.
2. Run verifications exactly as specified
3. Commit working changes

Pre-completion verification (FRESH evidence required):

• All steps in description completed?
• Tests passing? Run the FULL test command NOW — previous runs don't count after code changes
• Read complete output, check pass/fail counts and exit code
• Changes committed?
• State claim WITH evidence: "Tests pass. [Ran: X, Output: Y/Y passed, exit 0]"

Mark complete with TaskUpdate only after ALL steps verified with fresh evidence.

When Hitting Obstacles

CRITICAL: Check epic BEFORE switching approaches.

1. Re-read epic with TaskGet — check "Approaches Considered" and "Anti-patterns"
2. If alternative was already REJECTED, note original rejection reason
3. Only switch if rejection reason no longer applies AND user approves

Never water down requirements to "make it easier."

When Discoveries Require New Work

If implementation reveals unexpected work:

1. Create new task with TaskCreate — full detail, no placeholders
2. Set dependency with TaskUpdate addBlockedBy
3. Ensure it's bite-sized (2-5 min), has explicit paths, testable criteria
4. Document in checkpoint summary that new task was added

3. Create Next Task

After completing a task, create the NEXT task based on what you learned. This is how executing-plans differs from writing-plans: tasks are created iteratively as reality unfolds, not all upfront.

Review what you learned:

1. What did we discover during implementation?
2. What existing functionality, blockers, or limitations appeared?
3. Are we still moving toward epic success criteria?
4. What's the logical next step?

Three cases:

A) Clear next step → Create task with TaskCreate, set dependencies, proceed to checkpoint

B) Planned next task now redundant:

• Discovery makes it unnecessary
• Document why in checkpoint
• Mark completed with note: "SKIPPED: [reason]"
• Create the actual next task if one exists

C) Need to adjust approach:

• Document learnings in checkpoint
• Let user decide how to adapt

Task quality check (same as writing-plans):

• Scoped: 2-5 minutes of work
• Self-contained: Can execute without asking questions
• Explicit: All file paths specified
• Testable: Has verification command with expected output

4. STOP Checkpoint (Mandatory)

Present this summary, then STOP:

## Checkpoint

### What Was Done
- [Summary of implementation]
- [Key decisions made]

### Learnings
- [Discoveries during implementation]
- [Anything that affects future tasks]

### Task Status
[TaskList output — completed, in-progress, pending]

### Epic Progress
- [X/Y success criteria met]
- [What remains]

### Next Task
- [Title and brief description]
- [Why this is the right next step based on learnings]

### To Continue
Run `/gambit:executing-plans` to execute the next task.

Why STOP is mandatory:

• User can review implementation quality
• User can clear context if conversation is long
• User can adjust direction based on learnings
• Prevents runaway execution without oversight

5. Epic Review

When all subtasks completed:

1. TaskList — verify all subtasks show "completed"
2. TaskGet on epic — review each success criterion
3. Run full verification suite

Then invoke review directly using the Skill tool:

Skill skill="gambit:review"

Do not tell the user to run it manually — invoke it and follow its process immediately. Review validates architecture, security, completeness, dead code, test quality, and code quality across the entire epic before allowing finishing-branch.

Examples

Handling Obstacles Correctly

When blocked, check epic BEFORE switching approaches:

1. Hit obstacle: OAuth library doesn't support PKCE
2. Re-read epic → "Approaches Considered" shows:
   "Implicit flow - REJECTED BECAUSE: security risk"
3. PKCE is different from implicit flow → safe to explore
4. Ask user before switching: "Library X doesn't support PKCE.
   Should I try library Y, or use a different approach?"

Wrong: "PKCE doesn't work, let me just use implicit flow" (REJECTED approach)

Creating Next Task Based on Learnings

After completing "Set up OAuth config", you discover the framework has built-in session middleware:

TaskCreate
  subject: "Integrate with existing session middleware"
  description: |
    ## Goal
    Use framework's built-in session middleware instead of custom implementation.

    ## Implementation
    1. Study existing middleware: src/middleware/session.ts:15-40
    2. Write test: auth token stored in session correctly
    3. Integrate OAuth token storage with existing session
    4. Verify: session persists across requests

    ## Success Criteria
    - [ ] OAuth tokens stored via existing session middleware
    - [ ] No duplicate session logic
    - [ ] Tests passing
  activeForm: "Integrating session middleware"

This task wouldn't have been correct if planned upfront — it reflects what you actually found.

Critical Rules

1. ONE task then STOP — no batching, no "just one more"
2. Epic requirements IMMUTABLE — tasks adapt, requirements don't
3. Check epic before switching approaches — rejected approaches stay rejected unless conditions changed
4. Create next task from learnings — not from upfront assumptions
5. Evidence before completion — run tests, show output, then mark done
6. Never water down requirements — if blocked, ask user, don't simplify

Common rationalizations (all mean STOP, follow the process):

Verification Checklist

Before completing each task:

• All steps in description executed
• Tests passing (verified by running them)
• Changes committed
• TaskUpdate status="completed" only after truly done

After completing each task:

• Reviewed learnings against epic (TaskGet)
• Created next task based on learnings (or documented why not)
• Presented checkpoint summary
• STOPPED execution
• Waiting for user to run /gambit:executing-plans again

Before closing epic:

• ALL subtasks show "completed" in TaskList
• ALL success criteria verified with evidence
• ALL anti-patterns avoided
• Invoked gambit:review directly via Skill tool
• Review approved → finishing-branch invoked automatically

Integration

Called by:

• User via /gambit:executing-plans
• After gambit:writing-plans or gambit:brainstorming creates tasks

Calls:

• gambit:test-driven-development during implementation
• gambit:verification before claiming task complete
• gambit:review (invoked directly when all tasks complete — reviews then calls finishing-branch)