Spec Loop

The Spec Loop is the entry point for every piece of work. It takes a task description, creates a ticket and branch, and produces a complete spec before any code is written.

What it does

1. Creates a ticket in your configured ticketing system (Jira, GitHub Issues, or a local .dmx/ ticket)
2. Creates a branch with the correct naming convention
3. Scaffolds spec.md pre-filled with project context from the memory bank
4. Asks clarifying questions in the Q&A section of the spec
5. Waits for you to answer them
6. Validates completeness before the Plan Loop starts

How to start it

Start the loop directly with your task description:

/dmx/run-loop spec

your task description here

This runs the loop's one skill, create-ticket, which creates the ticket, branch, and spec from that description, then pauses for review.

The task description goes to the loop, not to a separate create-ticket command — running /dmx/create-ticket manually beforehand would create a second, duplicate ticket when the loop then runs create-ticket itself.

The human gate

After create-ticket runs and the spec is scaffolded, the loop pauses. You fill in the spec: answer the Q&A, complete the Technical Approach section, define the Scope.

When you're ready:

/dmx/loop-continue

The Spec Loop validator runs. If it passes, the loop chains to the Plan Loop.

Validator: check_spec_complete

Four required checks:

Check	What it verifies
spec_exists	.dmx/spec.md exists and is non-empty
qa_answered	All Q&A answers are filled in, not placeholder text
technical_approach_filled	The Technical Approach section has meaningful content
scope_defined	A Scope section exists and is not empty

If any check fails, the loop pauses with a clear message. Fix the spec and run /dmx/loop-continue to retry.

Loop config

name: spec
skills:
  - create-ticket
trigger:
  type: manual
goal_state: "Ticket created, branch checked out, spec.md complete with all Q&A answered"
validators:
  - tool: check_spec_complete
    checks:
      - name: spec_exists
        required: true
      - name: qa_answered
        required: true
      - name: technical_approach_filled
        required: true
      - name: scope_defined
        required: true
on_optional_failure: warn
failure_handling: pause
human_gate: true
on_complete:
  on_success:
    trigger_loop: plan

Starting from uncommitted work

If you've already started working before creating a ticket, use /dmx/derive-ticket instead:

/dmx/derive-ticket

This reads your uncommitted changes, infers what you're building, creates a ticket retroactively, names the branch correctly, and scaffolds a derived spec.

Tips

Write a good task description. The create-ticket skill uses it to infer ticket type, generate the branch name, and pre-fill spec sections. A specific description produces a better spec to work from.

Don't rush the Q&A. The spec Q&A is where ambiguity gets surfaced. Answer the questions even when they seem obvious. The answers become context for every subsequent loop.

The Technical Approach section matters. The spec adherence validator in the Dev Loop checks implementation against the spec's Technical Approach. A vague approach section produces a vague check.