Execution Stage

Input: $ARGUMENTS

Step 1: Break the Decision Into Tasks

Decompose the committed decision into concrete, doable tasks.

DECISION: [what was decided — one line]

TASK BREAKDOWN:
1. [Task 1]: [specific action] — estimated effort: [small/medium/large]
2. [Task 2]: [specific action] — estimated effort: [small/medium/large]
3. [Task 3]: [specific action] — estimated effort: [small/medium/large]
4. [Task 4]: [specific action] — estimated effort: [small/medium/large]
5. [Task 5]: [specific action] — estimated effort: [small/medium/large]

Rules:

Each task should be completable in one sitting
If a task feels too big, split it further
Use verbs: “write,” “build,” “contact,” “test” — not “think about” or “consider”

Step 2: Sequence the Tasks

Order tasks by dependencies, not by preference.

SEQUENCE:

Phase 1 — Foundation:
  [ ] [task] — blocks: [what depends on this]
  [ ] [task] — blocks: [what depends on this]

Phase 2 — Build:
  [ ] [task] — requires: [what must be done first]
  [ ] [task] — requires: [what must be done first]

Phase 3 — Finish:
  [ ] [task] — requires: [what must be done first]

PARALLEL WORK: [tasks that can happen simultaneously]

Rule: If no task has dependencies, the sequence doesn’t matter — start with the easiest one for momentum.

Step 3: Assign Resources

Identify what each task needs to get done.

RESOURCE MAP:

| Task | Who | Tools/Materials | Time | Blockers |
|------|-----|----------------|------|----------|
| [task 1] | [person/role] | [what's needed] | [estimate] | [any blockers] |
| [task 2] | [person/role] | [what's needed] | [estimate] | [any blockers] |
| [task 3] | [person/role] | [what's needed] | [estimate] | [any blockers] |

SKIP: If this is a solo project with no resource constraints, skip.

Step 4: Set Milestones

Define checkpoints to track progress and catch problems early.

MILESTONES:

| Milestone | Target Date | Success Criteria | Risk |
|-----------|-------------|-----------------|------|
| [milestone 1] | [date/timeframe] | [how to know it's done] | [what could go wrong] |
| [milestone 2] | [date/timeframe] | [how to know it's done] | [what could go wrong] |
| [milestone 3] | [date/timeframe] | [how to know it's done] | [what could go wrong] |

FINAL DELIVERABLE: [what "done" looks like for the whole effort]

Rule: Each milestone should be verifiable — you can point to evidence that it’s complete.

Step 5: Identify the First Action

The most important output of an execution plan is the very first thing to do.

FIRST ACTION:
- What: [the single next physical action]
- When: [right now / today / by tomorrow]
- How long: [estimated time to complete]
- Why this first: [why this is the right starting point]
- Done when: [specific completion criteria]

Rules:

The first action should be small enough to start immediately
It should be concrete enough that there’s no ambiguity about what to do
It should create momentum — once started, the next action becomes obvious

Step 6: Begin

Bias toward action. The plan is good enough.

EXECUTION READINESS:

- Plan complete enough to start: [yes — if no, what's missing?]
- First action clear: [yes/no]
- Biggest risk: [what's most likely to go wrong]
- Mitigation: [how to handle the biggest risk]
- Perfectionism check: Are you delaying because the plan isn't perfect? [yes/no]
  → If yes: Start anyway. Adjust as you go.

STATUS: READY TO EXECUTE
FIRST ACTION: [repeat the first action here]

Integration

Use with:

/dcst -> Make the decision before planning execution
/rfst -> Reflect after execution is complete
/to -> For more detailed task organization
/de -> For more comprehensive project decomposition

exst - Execution Stage