FAQ
How does this fit a team where PMs create tickets in Jira?
The PM's ticket and the development spec are different things. A Jira ticket captures requirements: what the feature should do, acceptance criteria, business context. A spec captures the development contract: technical approach, scope boundary, answered clarifying questions, definition of done. dmx produces the latter.
A developer picks up a Jira ticket, reads the requirements, and runs the spec loop using the ticket content as input. The AI asks the clarifying questions the PM couldn't answer: technical approach, edge cases, what happens when things go wrong. The spec that comes out lives in the codebase, on the branch, alongside the code it describes.
The PM's Jira ticket stays in Jira. The development spec lives in .dmx/spec.md. Both exist. Neither replaces the other.
How is this different from cursor rules or AGENTS.md?
Cursor rules and AGENTS.md are prompts. They tell the AI how to behave in a codebase. The AI still has to follow them, and it doesn't always. Variance in prompt-following is the problem you're trying to solve. You can't fix inconsistency with more instructions.
dmx is a harness. Validators don't rely on the AI's intent. Tests either pass or they don't. The spec either has all Q&A answered or the loop doesn't advance. The workflow is enforced as a sequence of loops, not as instructions the AI can skip. The dev loop doesn't start until the spec loop completes and the human gate is approved.
State also persists across sessions. Close your IDE, come back the next day, run /dmx/loop-continue. The loop resumes from exactly where it paused. A rules file resets every session.
dmx reads your rules files. The patterns you've defined in .cursor/rules/ or CLAUDE.md are part of the context the AI works from. They're complementary, not competing.
What happens when multiple developers are working in the same repo?
Each developer works on their own branch. Loop state lives in .dmx/jobs/{job_id}/, keyed off the ticket/branch, and is committed to that branch. Two developers running loops simultaneously on different branches don't interfere with each other — there's no shared, mutable state that a loop run on one branch could overwrite for another.
Four files make up the durable memory bank: projectbrief.md, productContext.md, systemPatterns.md, and techContext.md. They are updated infrequently and deliberately, when something worth preserving is discovered. These merge cleanly because changes are additive and targeted.
activeContext.md is branch-scoped by convention. It accumulates notes and open learnings during a feature branch. Before the PR is opened, create-pr promotes anything worth keeping to the durable files, clears what it promoted from the inbox, and commits the result. On merge, the feature branch's version wins. Main's active context stays nearly empty between merges.
Where does dmx stop and CI start?
dmx stops at the PR. The release loop syncs the memory bank, opens the PR, and transitions the ticket to review. After the merge, /dmx/close-ticket closes out the ticket and deletes the branch. Everything after that is handled by your existing infrastructure: CI pipelines, required reviewer approvals, merge, and deploy.
This boundary is intentional. dmx is a development harness. Your CI pipeline is infrastructure. dmx raises the quality of what goes into the PR. CI is the environment-level safety net. Both are necessary. Neither replaces the other.
Does dmx replace our PR review process?
No. dmx ensures the developer's work is correct before the PR opens: spec agreed, tests passing, validators clean, scope matching the spec. Human review still happens at the PR. Reviewers see the spec alongside the code. They know exactly what was intended, what was scoped out, and what checks have already run.
Your existing branch protection rules, CODEOWNERS assignments, and required approval counts all apply normally. dmx works inside your repo's governance, not around it.