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 →

Components for monorepos. Declare each service or package in .dmx/components/<id>/component.yaml with a description and the paths it owns, or let /dmx/init find them in your pnpm, npm, yarn, go.work, uv, or Cargo workspace. /dmx/add-component services/fraud adds any other folder, such as a Go service in a single-module repo. Every loop message names the ticket's components, and in a repo with components the agent reads only the memory that applies to them. run_tests runs the tests of each component the branch changed, plus every component that depends_on it, with default commands for Go, Node, Python, and Rust; set test in component.yaml for anything else, and test_command in config.md for changes outside every component. A component can keep its own skills, validators, and loops in its folder: skills and loops are named <id>/<name>, such as /dmx/run-loop ledger/backfill, and only that component's tickets use them; validators listed under validators in component.yaml add checks to the named loops, never replacing the repo-wide ones. Teams own their component folders through CODEOWNERS:

# .github/CODEOWNERS
/.dmx/                          @acme/platform
/.dmx/components/ledger/        @acme/ledger
/.dmx/components/payments*/     @acme/payments
/.dmx/jobs/

.dmx/jobs/ has no owner, so a ticket's own spec and plan never need platform approval. A repo without .dmx/components/ works as before.

Components can file tickets in their own Jira project or GitHub repo: list the allowed ones in config.md (jira_projects: [LEDG, PAY] or github_issue_repos: [acme/mono, acme/ledger-issues]) and set ticket in a component.yaml; dmx asks before using a destination it chose.

dmx check (or /dmx/check) validates the whole setup, such as unknown depends_on ids, paths that match no files, components without a test command, out-of-date locks, and missing CODEOWNERS lines, and shows what the current branch will load, check, and run. It never changes a file and exits 1 on an error, so it can run in CI.

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. A component can declare its own sources in .dmx/components/<id>/shared-sources.yaml, locked in its folder, so its team bumps them without platform approval; add /.dmx/components/*/shared-sources.lock @acme/platform to CODEOWNERS if platform should review every component bump instead. 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.7.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. Coming from 0.5, /dmx/upgrade also moves each ticket's files into its job folder and locks shared sources instead of copying them (see the 0.6.0 upgrade notes). 0.7 adds opt-in components for monorepos (see the 0.7.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