dmx

The harness for AI-native engineering teams.

Read the docs →

Most teams building with AI run into the same problems:

• Workflow lives in chat history. No process, nothing that persists, nothing you can hand off.
• Every developer uses AI differently. Different tools, different prompts, different output.
• Results are unpredictable. Brilliant one session, wrong the next.
• No shared context. Every session starts from scratch.

dmx fixes the process, not the model. It runs as an MCP server inside Cursor, Claude Code, GitHub Copilot, and Antigravity, and turns your engineering workflow into loops: ordered skills your agent runs, validators that check the result, and a human gate before anything moves forward. It implements the AI SDLC, an open framework for spec-first, phase-by-phase AI development.

How it works

Every piece of work runs through five loops, from first spec to open PR:

spec  →  plan  →  dev  →  validate  →  release

Each loop pauses after every skill so you can review. Run /dmx/loop-continue to move on. Validators run deterministically, outside the model: a required check that fails stops the loop and tells you why. When a loop passes, the next one starts on its own.

Loops are YAML in your repo. Override any default in .dmx/loops/, add your own, and review changes in PRs like any other code. Loops →

Quick start

1. Add dmx to your IDE. There's nothing to install: uvx fetches dmx on demand. Every IDE uses the same config:

{
  "mcpServers": {
    "dmx": {
      "command": "uvx",
      "args": ["--from", "deepmodel-dmx@latest", "dmx", "serve"]
    }
  }
}

Save it to the file for your IDE, then restart the IDE:

Commit the project file and everyone on the team gets dmx. The MCP setup guide covers the Claude Code CLI across all projects, Windows paths, deploying with Jamf or Intune, and other IDEs.

2. Initialize your repo. On your integration branch, run:

/dmx/init

Pick the sdlc workflow and your ticketing system (GitHub Issues, Jira, or none). Then open a new chat so the rules take effect.

3. Commit and push what /dmx/init wrote. The spec loop branches from what's on origin.

4. Start your first loop:

/dmx/run-loop spec

Add rate limiting to the public inference endpoint.

Answer the spec's questions, then /dmx/loop-continue at each gate. When the PR merges, /dmx/close-ticket closes the ticket and deletes the branch.

The Quick Start walks through every step.

What you get

Validators with policy. Required checks block; optional checks warn. Write your own in validators/ as plain Python. Validators →

A memory bank. .dmx/ holds project context, the current spec and plan, and loop state, committed to the repo. Every session and every developer starts from the same understanding. Memory bank →

Shared config for the whole organization. Define loops, skills, and validators once in a git repo and lock them into every project with /dmx/update-shared-sources; dmx fetches them into a git-ignored cache. Layer team config over an org baseline; each repo can still override what it needs. Shared sources →

Skill discovery. Ask your agent "which skills can update helm?" and it finds matching skills from your repo and every shared source. Ask for the task and it runs the right one. Custom skills →

Every skill on its own, too. Each step is also a /dmx/* command (/dmx/plan, /dmx/implement-next-phase, /dmx/validate, /dmx/create-pr, …) for when you want to drive by hand. Command reference →

Upgrading

Pin a version in your MCP config (deepmodel-dmx==0.6.0) or use @latest, restart your IDE, then run /dmx/upgrade once in each repo, on a branch, and commit what it changes as one PR. 0.6 moves each ticket's files into its job folder and locks shared sources instead of copying them; /dmx/upgrade migrates both. See the 0.6.0 upgrade notes. Upgrading dmx →

Roadmap

• Full lifecycle loops: spec, plan, build, validate, release
• Validators, human gates, and persistent loop state
• .dmx/ memory bank, committed to the repo
• Org-wide and team shared sources, with skill discovery
• Team server: a hosted MCP endpoint with shared loops and rules across the team
• Gateway: model governance, cost visibility, and autonomous background execution

Learn more

• Documentation: concepts, loops, configuration, and reference
• Changelog
• AI SDLC: the open framework dmx implements
• When Is a Loop Ready to Run Without You?: the thinking behind dmx

Contributing

Contributions are welcome. See CONTRIBUTING.md for development setup and the Contributor License Agreement. To report a vulnerability, see SECURITY.md.

License

AGPL-3.0