Skills, MCP, agents

Ways to give Nemocode more: instructions it can follow, tools it can call, helpers it can delegate to, and work it starts by itself.

Project instructions

Put an AGENTS.md in your repository and Nemocode reads it: your conventions, the commands that build and test, what to never touch. It is the one file that shapes every mission in that project.

For rules about the project memory instead of the code, use pum.md — see the curator.

To use Nemocode's memory from Claude Code, Codex, opencode or Claude Desktop instead, see Other coding agents.

One window for three things

/skills, /mcp and /hooks open the same window with three tabs; ← → switch between them and Esc closes it. Each command can also be typed with arguments, as shown below, and then does the job right away.

Skills

A skill is a packaged set of instructions for a recurring job — a deploy sequence, a review checklist, a house style for migrations. Nemocode ships with a set and you can add your own. A skill is a folder with a SKILL.md that has a description and the instructions. Nemocode sees the descriptions and picks the one that fits; you can also call one as a command: /deploy staging runs the skill deploy with the text after it. Installed skills appear in the command list, marked skill.

/skills                                  # what is installed
/skills install <git-url or folder>      # a repository, or a folder on disk
/skills install <source> --project       # for this project only
/skills install <source> --force         # replace one that is already there
/skills remove <name>                    # add --project for a project skill
/skills import                            # bring over what you have in Claude Code's folder

Without --project a skill is personal: available in every project of yours. A skill of the same name in a project wins over a personal one, which wins over one that ships with Nemocode.

MCP servers

MCP is the standard way to give a model tools. If a service you use has an MCP server, Nemocode can call it.

/mcp                             # what is connected
/mcp add jira npx -y @acme/jira-mcp --env TOKEN=…
/mcp add jira … --project        # only for this project
/mcp test jira                   # does it answer, and with which tools
/mcp remove jira

In the window, a adds a server (type the same line without /mcp add), t tests the selected one and d removes it. If the program is not found on your PATH, Nemocode says so when you add it — a server that cannot start is silent otherwise. Tools from a server appear next to Nemocode's own, named mcp__server__tool.

• Only servers that run as a program on your machine (the stdio kind) are supported. A server that does not start, or does not answer within 20 seconds, is skipped; the mission goes on without its tools.
• The server is started for each call and ended afterwards. A call that takes longer than 120 seconds is abandoned. Images in an answer are replaced by a note.
• The servers are kept in mcp.json, either for the project or for you. If the project has any server, only the project's list is used; the two are not merged. Values you give with --env are stored in that file as written.
• MCP tools are refused in Read only and Plan. In the other modes they run without an approval prompt, and allow, ask and deny rules do not apply to them, so add only servers you trust. A hook on PreToolUse does see them.

Hooks

A hook runs a command of yours at a point in Nemocode's work: before or after a tool runs (PreToolUse, PostToolUse), when you send a message (UserPromptSubmit), when a mission ends (Stop) and with the first message of a session (SessionStart). A matcher limits a hook to tools whose name fits. Use them to enforce something the agent cannot talk its way out of: a formatter, a linter, a rule that a protected file is never touched.

/hooks    # which ones are active

There is a project list and a global one; the project list wins as soon as it has any hook. Hooks run outside the agent's sandbox, with your rights — so only you can add them: in the Hooks tab, a, e or d opens the hook list, where a adds one (scope, event, matcher, command) and d removes one. The agent has no way to write a hook.

Subagents

Nemocode splits work by itself. A broad search runs as a separate reader so the main conversation stays small; an independent part of a build can run as its own agent. You see each one start and finish, and every one can have its own model under Settings ▸ Models. While they run, ← in an empty input field opens a list where you can watch one, pause it or stop it.

You can also write your own agent for a project or for yourself: /agents lists them; a creates one — a name, a description of when to use it, the instructions it follows, and whether it is personal or belongs to the project — and d deletes one. The main agent can hand read-only research questions to it, and Enter makes the current session run as that agent instead of the default one. Agents that come from plugins are shown but read-only. Details are on Automation.

Scheduled work

A job can start a mission later or repeatedly — a nightly review, a daily dependency check. /schedule lists them; a creates one for the current session (a task, when — in 20 minutes, at 18:27 — and optionally how often: every 30 minutes, hourly, daily; empty means once), d cancels one. You see them on the dashboard together with what they produced.

Connectors

/connectors connects a repository whose issues and comments start missions. Give it the repository, the authors allowed to trigger it (nobody else can; an empty list means nobody), an optional trigger word, and the name of the environment variable that holds the access token. p polls now, d removes the connector.