packages/web/src/content/docs/skills.mdx
Agent skills let OpenCode discover reusable instructions from your repo or home directory.
Skills are loaded on-demand via the native skill tool—agents see available skills and can load the full content when needed.
Create one folder per skill name and put a SKILL.md inside it.
OpenCode searches these locations:
.opencode/skills/<name>/SKILL.md~/.config/opencode/skills/<name>/SKILL.md.claude/skills/<name>/SKILL.md~/.claude/skills/<name>/SKILL.md.agents/skills/<name>/SKILL.md~/.agents/skills/<name>/SKILL.mdFor project-local paths, OpenCode walks up from your current working directory until it reaches the git worktree.
It loads any matching skills/*/SKILL.md in .opencode/ and any matching .claude/skills/*/SKILL.md or .agents/skills/*/SKILL.md along the way.
Global definitions are also loaded from ~/.config/opencode/skills/*/SKILL.md, ~/.claude/skills/*/SKILL.md, and ~/.agents/skills/*/SKILL.md.
Each SKILL.md must start with YAML frontmatter.
Only these fields are recognized:
name (required)description (required)license (optional)compatibility (optional)metadata (optional, string-to-string map)Unknown frontmatter fields are ignored.
name must:
---SKILL.mdEquivalent regex:
^[a-z0-9]+(-[a-z0-9]+)*$
description must be 1-1024 characters.
Keep it specific enough for the agent to choose correctly.
Create .opencode/skills/git-release/SKILL.md like this:
---
name: git-release
description: Create consistent releases and changelogs
license: MIT
compatibility: opencode
metadata:
audience: maintainers
workflow: github
---
## What I do
- Draft release notes from merged PRs
- Propose a version bump
- Provide a copy-pasteable `gh release create` command
## When to use me
Use this when you are preparing a tagged release.
Ask clarifying questions if the target versioning scheme is unclear.
OpenCode lists available skills in the skill tool description.
Each entry includes the skill name and description:
<available_skills>
<skill>
<name>git-release</name>
<description>Create consistent releases and changelogs</description>
</skill>
</available_skills>
The agent loads a skill by calling the tool:
skill({ name: "git-release" })
Control which skills agents can access using pattern-based permissions in opencode.json:
{
"permission": {
"skill": {
"*": "allow",
"pr-review": "allow",
"internal-*": "deny",
"experimental-*": "ask"
}
}
}
| Permission | Behavior |
|---|---|
allow | Skill loads immediately |
deny | Skill hidden from agent, access rejected |
ask | User prompted for approval before loading |
Patterns support wildcards: internal-* matches internal-docs, internal-tools, etc.
Give specific agents different permissions than the global defaults.
For custom agents (in agent frontmatter):
---
permission:
skill:
"documents-*": "allow"
---
For built-in agents (in opencode.json):
{
"agent": {
"plan": {
"permission": {
"skill": {
"internal-*": "allow"
}
}
}
}
}
Completely disable skills for agents that shouldn't use them:
For custom agents:
---
tools:
skill: false
---
For built-in agents:
{
"agent": {
"plan": {
"tools": {
"skill": false
}
}
}
}
When disabled, the <available_skills> section is omitted entirely.
If a skill does not show up:
SKILL.md is spelled in all capsname and descriptiondeny are hidden from agents