Frequently Asked Questions
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/ and is committed to that branch. Two developers running loops simultaneously on different branches don't interfere with each other.
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 created, the update-memory skill promotes anything worth keeping to the durable files and resets the active context. 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 opens the PR, transitions the ticket to review, and updates the memory bank. 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.
Does this work in a monorepo?
dmx initializes at the repository root and works across the full codebase — there's one .dmx/ memory bank per repo, not one per service or package. For teams working in large monorepos, scope each ticket explicitly in the spec: name the services and directories in scope so the AI's work stays bounded to the relevant area, and keep systemPatterns.md organized by service if the codebase has several distinct ones.