Custom Skills

dmx ships the skills for the core workflow as /dmx/* commands. Your repo and your organization's shared sources can add their own: a Helm chart upgrade, a preview deploy, a release checklist. Developers don't need to know they exist. They ask their agent, and the agent finds the right one.

Where custom skills liveCopy Anchor Link

dmx finds custom skills in two places, in this order:

1. Your repo: .dmx/skills/
2. Shared sources: .dmx/vendor/{name}/skills/ for each source in .dmx/shared-sources.yaml, in declared order

The first place that has a skill wins. A skill is either a flat {name}.md file or a {name}/SKILL.md folder, the format Claude Code and agentskills.io use. Its file or folder name is its name.

your-project/
└── .dmx/
    ├── skills/
    │   └── deploy-preview.md          # this repo's own skill
    └── vendor/
        └── platform/
            └── skills/
                └── helm_update/       # from the org's platform source
                    ├── SKILL.md
                    └── scripts/

Ask what's availableCopy Anchor Link

Ask in plain language:

what skills do we have for helm updates?

The agent lists every custom skill that matches, with its name, where it comes from, and what it does. It also lists any built-in /dmx/* commands that fit, marked as slash commands:

helm_update (platform): Upgrade a service's Helm chart version and roll it out —
staging first, then production.

deploy_helm_preview (platform): Deploy a temporary Helm preview environment for a
feature branch.

No bundled /dmx/* command covers Helm updates.

A question about what exists only lists. Nothing runs.

Ask for the taskCopy Anchor Link

Ask for the work itself:

update the helm chart for the billing service

When one skill clearly matches, the agent loads it and follows its instructions. When several match, it lists them and asks which one you want.

Built-in commands still run as typed. A request that is already a /dmx/* command runs that command.

During a loopCopy Anchor Link

While a loop is running, the loop decides which skill runs next. You can still ask what skills exist, and the agent will list them, but it won't run a custom skill outside the loop.

To make a custom skill part of a loop, add its name to the loop's skills list. See Loop Configuration.

Write a description that gets foundCopy Anchor Link

The agent matches your request against each skill's name and the description in its frontmatter. The description is what it shows you, too. Make it say what the skill does and when to use it:

---
name: helm_update
description: Upgrade a service's Helm chart version and roll it out — staging first, then production.
---

A skill with no description is still listed by name, but it's much harder to find with a plain-language request.

Overriding a built-in skillCopy Anchor Link

A custom skill with the same name as a built-in one, such as .dmx/skills/commit.md, replaces it when a loop runs that skill. The agent's skill list marks these as overrides, so you can see which built-in behavior your repo or organization has changed.

Under the hoodCopy Anchor Link

The agent uses two MCP tools:

• list_skills returns one line per custom skill: name (source): description. The source is app repo or the shared source's name. A skill hidden by a higher-priority copy with the same name isn't listed.
• get_skill_definition loads a skill's instructions by name.

list_skills isn't the dmx list-skills command-line command, which prints the skills bundled with dmx.

Skill discovery needs the dmx 0.5.0 rule files in your repo. If your repo was set up with an earlier version, run /dmx/upgrade once.