Skip to main content

Team Setup

Setting up dmx for a team is mostly about getting .dmx/ committed to your repository and making sure everyone connects their IDE to dmx.

Step 1: Initialise the repo once​

One person runs /dmx/init in the repository. This creates the .dmx/ directory with the project config and scaffolded memory bank.

Commit the .dmx/ directory:

git add .dmx/
git commit -m "chore: initialise dmx memory bank"
git push

Every developer who pulls this commit gets the project context automatically. No further setup per developer beyond connecting their IDE.

Step 2: Each developer connects their IDE​

Each team member configures their IDE to use dmx as an MCP server. See MCP Setup for the config.

The command is the same for everyone:

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

No per-developer configuration. No secrets to share. dmx reads project config from .dmx/config.md in the repo.

Step 3: Commit .dmx/ files as you work​

As developers work on features, spec.md, tasks.md, and the core memory files (systemPatterns.md, techContext.md, productContext.md, activeContext.md) are updated. These should be committed alongside code changes.

Include .dmx/ in your standard commit workflow. The memory bank is project state, not developer scratch. It belongs in the repo.

What to gitignore​

A minimal .gitignore for .dmx/:

# Ignore job execution records (can get large)
.dmx/jobs/

# Ignore the active loop pointer (resolves on checkout)
.dmx/loop-state.json

Some teams prefer to commit .dmx/jobs/ for full auditability. It's optional. The value is in the context files and loop configs, not the execution records.

Sharing loop configs​

Custom loop configs in .dmx/loops/ are committed to the repo and shared across the team. Every developer runs the same loops with the same validators.

To change a loop config:

  1. Edit .dmx/loops/{name}.yaml
  2. Commit and open a PR
  3. The change is reviewed like any other code change

This is the principle that makes loops reliable for teams: loop configs are versioned artifacts, not personal preferences.

Sharing custom skills​

If you've written custom skills (beyond the bundled set), point DMX_SKILLS_DIR at a directory in the repo:

{
  "mcpServers": {
    "dmx": {
      "command": "uvx",
      "args": ["--from", "deepmodel-dmx", "dmx", "serve"],
      "env": {
        "DMX_SKILLS_DIR": "/absolute/path/to/your/repo/.dmx/skills"
      }
    }
  }
}

Everyone uses DMX_SKILLS_DIR pointing to the repo. Custom skills are versioned and shared.

Sharing custom validators​

Custom validators in validators/ at the repo root are already shared. They're in the repo. No additional configuration needed; dmx looks there first.

your-project/
├── validators/
│   ├── run_tests.py        # Team's custom test runner
│   └── security_scan.py    # Team's security validator
└── .dmx/
    └── loops/
        └── dev.yaml        # References the custom validators

Handling merge conflicts in .dmx/​

Because spec.md and tasks.md are branch-level files, they rarely conflict. The context files (techContext.md, systemPatterns.md) can conflict if two developers are updating them simultaneously.

Resolve context file conflicts like documentation conflicts: read both versions, keep the most current and accurate content, commit the merge.

loop-state.json should be gitignored. If it's committed, accept any incoming version on merge. It always resolves to the correct state on the next loop run.

Onboarding new developers​

A new developer on the team:

  1. Clones the repo (gets .dmx/ with full project context)
  2. Configures their IDE to use dmx (MCP Setup)
  3. Runs their first /dmx/create-ticket or picks up an in-progress job

No onboarding document needed for dmx itself. The memory bank is the onboarding document.