# Installing the agent skills

> myna skills install writes Myna's change-set, schema, and publishing rules where coding agents will read them.

Connecting an agent to the [MCP server](/mcp/setup) gives it the tools. It does not give it the rules those tools exist to enforce — that a write is a draft, that validation precedes a preview, that publishing is a separate authorization. An agent that can call `myna_publish_change_set` and has never been told any of that will publish, reasonably, because nothing said otherwise.

So the rules ship as skills, and the CLI puts them where the agent will read them:

```bash
$ myna skills install
✓ /home/me/.agents/skills/myna-change-sets/SKILL.md
✓ /home/me/.agents/skills/myna-schema/SKILL.md
✓ /home/me/.agents/skills/myna-publishing/SKILL.md
✓ /home/me/.claude/skills/myna-change-sets/SKILL.md
✓ /home/me/.claude/skills/myna-schema/SKILL.md
✓ /home/me/.claude/skills/myna-publishing/SKILL.md

6 skill file(s) written.
```

## What gets installed

| Skill | Covers |
|---|---|
| `myna-change-sets` | The write workflow — create a change set, stage drafts on it, validate the whole set, take one preview, stop. Plus `expectedRevisionId`, what `STALE_REVISION` means, and when to rebase. |
| `myna-schema` | Schemas as code: `schema diff` → `push`, what makes a diff destructive, which direction to resolve drift in, and why a content rule belongs in schema `policy` rather than in a build script. |
| `myna-publishing` | When an agent may publish and when it may not, the publish gates, and how a revert generates a reviewable change set rather than writing to published state. |

`myna skills list` prints the same table from whatever version of the CLI you have installed.

## Where they go

By default, into the user-level skill directories on this machine: the vendor-neutral `~/.agents/skills`, plus `~/.claude/skills` when it already exists. A directory that does not exist is not created — the CLI is detecting installed tools, not installing them.

```bash
$ myna skills install --scope project     # <project root>/.claude/skills
$ myna skills install --target ./skills   # anywhere else (repeatable)
$ myna skills install --print             # show the plan, write nothing
```

## Upgrading

A skill file that exists and matches the bundled version is reported unchanged. One that exists and *differs* is left alone and reported, because a skill somebody edited is a skill somebody meant, and silently reverting it on every CLI upgrade would make editing it pointless. Pass `--force` to take the bundled version anyway:

```bash
$ myna skills install
– /home/me/.agents/skills/myna-schema/SKILL.md

1 file(s) differ from the bundled version and were left alone. Pass --force to update them.
```

## They are not a security boundary

Skills describe the intended workflow to a cooperating agent. They do not enforce it, and nothing about Myna's safety depends on an agent having read them. Publishing still requires the `content:publish` scope and an explicit confirmation, destructive tools still require `confirm: true`, and the [publish gates](/concepts/change-sets) still apply. The right way to stop an agent from publishing is to withhold the scope — see [API key scopes](/platform/scopes). The skills are there so a well-behaved agent does not have to guess.