Plan Loop

The Plan Loop takes the approved spec and generates a phased implementation plan. No code is written here. The output is a structured tasks.md that the Dev Loop executes.

What it does

1. Reads spec.md from the memory bank
2. Validates Q&A completeness before planning against it
3. Generates tasks.md, a phased task list with enough granularity for phase-by-phase implementation
4. Opens the file for review before any code is written

How to start it

The Plan Loop fires automatically when the Spec Loop completes. You can also run it manually:

/dmx/run-loop plan

The human gate

After plan runs and tasks.md is ready, the loop pauses. Review the plan. Check whether the phases are in the right order, whether the granularity is right, and whether the plan matches your intent from the spec. Edit tasks.md directly if you want to adjust anything.

When you're satisfied:

/dmx/loop-continue

The Plan Loop validator runs, then the loop chains to the Dev Loop.

Validator: check_plan_complete

Three required checks:

Check	What it verifies
tasks_file_exists	.dmx/tasks.md exists and is non-empty
phases_defined	At least one phase is defined
tasks_have_descriptions	Tasks have descriptions, not empty checkboxes

Loop config

name: plan
skills:
  - plan
trigger:
  type: on_complete
goal_state: "tasks.md created with all phases and tasks defined, no ambiguity remaining"
validators:
  - tool: check_plan_complete
    checks:
      - name: tasks_file_exists
        required: true
      - name: phases_defined
        required: true
      - name: tasks_have_descriptions
        required: true
on_optional_failure: warn
failure_handling: pause
human_gate: true
on_complete:
  on_success:
    trigger_loop: dev

What makes a good plan

The plan skill structures tasks.md as phases with tasks under each. Each phase should be independently implementable and testable, because the Dev Loop implements one full phase at a time.

Good phase boundaries: data model changes, service layer, API layer, integration. A plan with one giant phase is hard for the Dev Loop to execute and hard for you to review. A plan with fifteen micro-phases creates unnecessary back-and-forth. Three to six phases is about right.

Tips

Edit the plan before continuing. The human gate is your opportunity to reshape the approach. Move tasks between phases, split a phase that's too broad, merge two that should be atomic. The Dev Loop executes exactly what's in tasks.md.

Check for missing phases. If the spec scope was vague, the plan may miss things. Read the plan against the spec's acceptance criteria before proceeding.