Release Loop

The Release Loop syncs the memory bank, opens the PR, and transitions the ticket to review. It is the final loop in the default chain.

What it doesCopy Anchor Link

The loop runs a single skill, create-pr, which:

1. Syncs the memory bank: promotes durable learnings from activeContext.md, spec.md, and tasks.md into the core memory files so future sessions benefit, and commits the result
2. Opens the PR: pushes the branch, opens a GitHub pull request with the correct title format and a drafted description, and transitions the ticket to In Review

How to start itCopy Anchor Link

The Release Loop fires automatically when the Validate Loop completes. You can also run it manually:

/dmx/run-loop release

SkillsCopy Anchor Link

create-pr opens a GitHub PR with:

• A title formatted to your project's PR conventions, read from the memory bank
• A body generated by draft-pr-description, called automatically if no description is provided
• The correct base branch, defaulting to branch_base from your config
• The ticket transitioned to In Review

Before opening the PR, create-pr runs a full memory bank sync: it reviews what happened during the job and promotes durable learnings (architecture decisions made, patterns established, gotchas discovered) into the core memory files, then commits them so they're part of the PR. This is what makes the memory bank compound over time.

Earlier versions of the Release Loop also ran update-memory after create-pr. That step was removed: create-pr already does the sync, and anything update-memory changed after the PR was open was left uncommitted and never made it into the PR. You can still run /dmx/update-memory on its own at any time for a deeper reconciliation.

The human gateCopy Anchor Link

human_gate: true gates every skill — with one skill in the loop, this loop pauses once, after create-pr. Check the PR, then continue to run the check_pr_ready validators:

/dmx/loop-continue

Validator: check_pr_readyCopy Anchor Link

memory_updated fails if anything under .dmx/ is left uncommitted (other than .dmx/jobs/, the loop runtime's own state). See check_pr_ready for details.

Before create-pr commits the memory bank, it marks the loop's run complete, so the commit going into the PR doesn't contain a job file stuck at running. The validator results are filled in when you continue.

When the loop finishes, the runtime commits its final job state under .dmx/jobs/ and the session-note breadcrumb it adds to activeContext.md, so the loop's outcome isn't lost when the branch is later deleted. It pushes that commit only when it's the only unpushed commit on a branch with an open PR; otherwise it warns you to push it yourself.

Loop configCopy Anchor Link

name: release
skills:
  - create-pr
trigger:
  type: on_complete
goal_state: "PR created, ticket transitioned to review, memory bank updated"
validators:
  - tool: check_pr_ready
    checks:
      - name: pr_exists
        required: true
      - name: ticket_transitioned
        required: true
      - name: memory_updated
        required: false
on_optional_failure: warn
failure_handling: pause
human_gate: true
on_complete:
  on_success:
    trigger_loop: null

After the PR is mergedCopy Anchor Link

Once your PR is reviewed and merged, close out the ticket:

/dmx/close-ticket

This confirms the PR was actually merged, transitions the ticket to Done, adds the PR link as a comment, and deletes the branch locally and remotely. If it can't find a merged PR for the branch, it warns you and leaves the ticket alone: no transition, no comment. A ticket that's already closed (for example, a GitHub issue auto-closed by Closes #N) is treated as done, not as an error.

Running /dmx/loop-continue after the merge doesn't close anything: the Release Loop ends once the PR exists.

For library or package releases that need a tagged GitHub release, use the release skills directly:

/dmx/draft-release-note v0.3.0
/dmx/release-merge v0.3.0
/dmx/create-release v0.3.0

draft-release-note commits and pushes .dmx/releases/{version}.md once it's written, so release-merge picks it up in the release PR. Run it from your integration branch, since that's where the notes are pushed.

These are standalone skills. If you publish packages regularly, add them to a custom release loop.