Skip to content

Skills

A skill is a folder in your vault containing a SKILL.md: some frontmatter, and a body of instructions. That’s the whole format.

Skills live under Agents/Skills/<name>/SKILL.md. They are ordinary notes — you can write one in Obsidian without leaving the app.

Skills are not an add-on layered over the agent’s built-in abilities. They are how the agent gets its abilities. A skill’s frontmatter can carry an allowed-tools line, and a built-in tool is bound only when some enabled skill attaches it.

Turn off the skill, and the agent loses the tool.

---
name: edit-notes
description: Create, update, delete, and move notes. All writes are staged...
allowed-tools: manage_notes
---
## Write Operations
- All write operations are staged for user approval...

Four ship with the plugin and are seeded into your vault on first run:

Skill Attaches Covers
explore-vault search_notes, list_directory, read_content, grep_notes, get_all_tags, get_properties, execute_javascript Finding and reading notes — verify tags and properties before querying, and what to do when a search comes back weak
edit-notes manage_notes Creating and editing notes, and the staging policy
web fetch_url, web_search Reaching the public internet, vault-first
manage-skills manage_skills Authoring and revising skills

They are ordinary notes once seeded — edit them freely. If a plugin update changes a default you had customized, you get a notice rather than a silent overwrite. Deleting a bundled core skill is refused: it would simply reappear on the next startup.

Some skills are written against another Obsidian plugin’s API — Dataview, Tasks, TaskNotes, Obsidian Charts, Canvas, and Bases — and are seeded only when that plugin is present.

They are ordinary skills once seeded, but enabling one also grants the agent a tool that runs code against that plugin, so they’re opt-in per plugin. See Integrations.

Every enabled skill’s description is in the system prompt. Its body is not. The agent reads the descriptions, decides a skill is relevant, and pulls the full instructions in with load_skill.

This is what makes a large skill library affordable — twenty skills cost you twenty one-line descriptions per turn, not twenty full bodies.

Write descriptions accordingly. The description is the only thing the agent sees when deciding whether to load a skill, so it should say when to load it, not just what the skill is about.

Because a tool can be attached by more than one skill, per-tool switches are not per-skill. They live in one agent-level Tools modal, reachable from the Agent editor’s General section, which lists every built-in tool flat and shows which skill(s) attach it.

A tool is bound when an enabled skill attaches it and the per-tool override hasn’t vetoed it. The override is the way to keep a skill’s guidance while denying it one specific tool.

With the manage-skills skill enabled, the agent can author new skills, revise skills attached to it, and delete skills it created.

This is how a discovery becomes permanent: once the agent works out how some API actually behaves, it folds the concrete methods and arguments into a skill so the next run skips the rediscovery.

Unlike note edits, skill operations apply immediately — there is no review queue. Creating a skill is the same action as attaching it.

Create Agents/Skills/<name>/SKILL.md with name and description in the frontmatter, and your instructions in the body. It’s discovered on the next scan — any directory containing a SKILL.md is a skill. There are no reserved names.

A user skill with no allowed-tools line attaches no tools; it is pure guidance, which is often exactly what you want. Keep skills narrow and the instructions concrete, and write down only what you’d actually want the agent to remember doing again.