Skills hold procedures you have written down: a release checklist, the way you file an expense, how you want a changelog worded.
A skill is a prompt, not a tool. That is the whole design. Your agent cannot read a skill's body and cannot choose one on your behalf. You invoke it, and MCP clients surface prompts as user-selected for exactly this reason.
Why not a tool
A tool is something a model picks when it judges the moment right. A procedure is something a person picks because they have decided this is the job.
If an agent could read every skill, it could shop the catalogue for its own instructions, which is a
different system from the one you wrote a checklist for. So reading a skill's body sits in the
author bundle, not the read one, and a profile granted invoke-only is offered no management tool at
all.
What your agent can do
| Invoke | Author |
|---|---|
| any skill, as a prompt | skills.manage.list, skills.manage.get, skills.manage.write, skills.manage.remove |
To keep an agent able to run your procedures but never to write one:
$ lanes link policy deny 'skills.manage.*' --profile personal --workspace localFrom the CLI
$ lanes link skills list --profile personal --workspace local
$ lanes link skills show release-checklist --profile personal --workspace local
$ lanes link skills add ./release-checklist.md --profile personal --workspace local
$ lanes link skills remove release-checklist --profile personal --workspace localA skill is a Markdown file with YAML frontmatter, and {{argument}} in the body is substituted when
it is invoked.
Reconnect after adding one
A skill moves no counter. Adding a tool changes the advertised tool count, and that count is how you normally tell an agent is stale; a prompt changes nothing anyone can see.
So after lanes link skills add, reconnect your agent on the same reasoning you would for a new
connection, without waiting for a number to change.
They belong to one profile
A skill you wrote under work is not available under personal. Nothing crosses.