Skills, MCP and hooks

Four kinds of extension, each a plain file you can keep in your own folder or commit with the project. A plugin bundles any of them into one install.

Skills#

A skill is a folder with a SKILL.md file: a short header with its name and a description of when to use it, then the instructions. DCode reads the descriptions and loads a skill when a task fits it, so its instructions take up room only when they are needed.

---name: release-notesdescription: Write release notes from the commits since the last tag. Use when asked for release notes or a changelog entry.---1. Find the last tag with git describe --tags --abbrev=0.2. Group the commits since then into Added, Changed and Fixed.3. Write one plain sentence per change, newest first.

The header takes name and description (up to 1,024 characters), and may add when_to_use, license and metadata. SKILL.md is read up to 100,000 bytes.

Where skills live#

Plugins add skills of their own. Each skill is a folder inside one of these, for example .dcode/skills/release-notes/SKILL.md.

Use a skill#

• Ask for the task in your own words, and DCode loads the skill that fits.
• In the desktop app, name an enabled skill in your message as $skill-name.
• In the CLI, /skill lists the skills of the folder, and /skill <name> [task] makes the next prompt load that skill first. From the shell, dcode skills list and dcode skills inspect <name>.

In the desktop app, Settings, Skills lists your workspace and personal skills and the plugin skills, with a switch for each. New skill starts one, Import brings in skills you already have in other tools on this computer, and deleting a skill removes its folder from disk for good.

Custom slash commands#

A command is a Markdown file whose text is the prompt it sends. Its name is the file's name: review-pr.md is /review-pr, and a file in a subfolder, git/commit.md, is /git:commit.

---description: Review a pull request branch for bugs and missing testsargument-hint: <branch>---Review the changes on $1 against main. List each problem with its file and line, then the tests that are missing.

• $ARGUMENTS is replaced by everything you type after the command, and $1, $2 by single words of it. With neither, what you type is added at the end of the prompt.
• The header takes description, argument-hint (shown as the command's input hint) and skills (skills to load with it).
• Commands live in ~/.dcode/commands or ~/.agents/commands (yours) and in .dcode/commands or .agents/commands of the project, found the same way as skills.

Type the command in the message box of the desktop app or the CLI. Settings, Commands lists your commands and the plugin commands, with New command and Open user commands folder. From the shell, dcode commands list and dcode commands inspect <name>.

MCP servers#

An MCP server gives DCode new tools: a database, an issue tracker, an internal API. A server runs on your computer as a command, or is reached at an address.

In the desktop app#

Open Settings, MCP servers. Add MCP server sets one up, and Import brings in servers you already use in other tools on this computer. The list shows your configured servers and the ones your plugins add.

In the CLI#

# a server that runs on your computer, for this projectdcode mcp add db --scope project --env DATABASE_URL=postgres://localhost/dev -- npx -y my-db-mcp-server# a remote server that asks you to sign indcode mcp add tracker --url https://mcp.example.com/mcp --oauthdcode mcp listdcode mcp remove tracker

Servers for you are saved in ~/.dcode/cli/config.json and servers for the project in .dcode/config.json, under mcp.servers:

{  "mcp": {    "servers": {      "db": { "type": "stdio", "command": "npx", "args": ["-y", "my-db-mcp-server"], "env": { "DATABASE_URL": "postgres://localhost/dev" } },      "tracker": { "type": "http", "url": "https://mcp.example.com/mcp", "oauth": { "type": "authorization_code" } }    }  }}

• A new server loads in your next session; in a running one, /mcp connect <name>. /mcp lists the servers and their state, and /mcp disconnect <name> turns one off for the session.
• With --oauth, DCode asks you to sign in to the server the first time it connects.
• For one run only, pass --mcp-config with {"mcpServers": {...}} as JSON text or a file.
• A server's tools are named mcp__<server>__<tool>, which is how you allow them in a rule, for example --allowed-tools "mcp__tracker__*". In Plan mode, MCP tools that cannot destroy anything still run.

Hooks#

A hook runs your own command when something happens in a session: to check a command before it runs, format a file after an edit, or add context when a session starts.

Set up a hook#

In the desktop app, open Settings, Hooks, and choose New hook: the event, the runner (Shell command, or Process with its arguments one per line), a matcher such as Bash or Edit (blank matches everything for the event), the command, and a timeout in seconds. Changes apply to new sessions. In a file, hooks go in the hooks section of ~/.dcode/cli/config.json or of the project's .dcode/config.json:

{  "hooks": {    "events": {      "PreToolUse": [        { "matcher": "Bash", "hooks": [{ "type": "command", "command": "node scripts/check-command.mjs", "timeout": 10 }] }      ]    }  }}

How a hook answers#

The hook gets the event as JSON on its standard input.

• Exit code 0: the session goes on. The hook may print a JSON answer on standard output.
• Exit code 2: block. What the hook wrote to standard error is the reason. For PreToolUse, the tool call is refused.
• Any other exit code: the hook failed, and DCode reports it.

Project hooks need your trust#

Hooks run commands on your computer, so hooks that come with a project do not run until you trust them, and a hook that changes needs your trust again. The desktop app asks you to review new or changed hooks and offers Trust. In the CLI, dcode hooks trust review shows what is waiting and dcode hooks trust grant trusts it (dcode hooks trust); /config hooks shows how many hooks you have and in which files.

Related#

• Plugins
• Agents
• dcode mcp