Skills

Prompts get unwieldy when you pack every instruction into the system message. Skills solve this. They are lazy-loaded instruction packages that keep your initial context window small while providing deep expertise on demand.

How Skills Work

Skills are text documents parsed as Markdown, with a name, description, and body of instructions. At prompt render time, Output builds a summary of available skills and adds it to the system message. The LLM decides which skills are relevant for the task and loads them when necessary.

Providing Skills

List skill paths in the prompt YAML frontmatter. Paths can be individual files of any extension or directories, resolved relative to the prompt file. Explicit files are loaded regardless of extension; directory scans load only .md files. A skills/ folder next to the prompt is not loaded unless you list it.

prompts/
├── writing_assistant@v1.prompt
└── skills/
    ├── clarity_guidelines.md
    ├── response_format.md
    └── structure_guide.md

writing_assistant@v1.prompt

---
provider: anthropic
model: claude-sonnet-4-20250514
maxTokens: 2048
maxSteps: 5
skills:
  - ./skills
  - ../shared_skills/tone_guide.md
---

<system>
You are an expert technical writing assistant.
Use load_skill to get the full instructions for any skill before applying it.
</system>

<user>
Review the following {{ content_type }} content focusing on {{ focus }}.

Content:
{{ content }}
</user>

List skill paths in the prompt YAML frontmatter. Skills add a load_skill tool, so set maxSteps in the same frontmatter when the default of 10 is wrong. Omit skills (or set skills: []) when a prompt should load none. That is the default: a sibling skills/ folder used by other prompts in the same directory is not inherited.

Skill File Format

Skill files are parsed as Markdown documents with an optional YAML frontmatter block:

clarity_guidelines.md

---
name: clarity_guidelines
description: Rules for writing clear, readable technical content
---

# Clarity Guidelines

When reviewing or writing technical content for clarity:

1. **Sentence length**: Keep sentences under 25 words when possible.
   Break complex ideas into multiple sentences.

2. **Active voice**: Prefer active voice ("The function returns X")
   over passive ("X is returned by the function").

3. **Jargon**: Define technical terms on first use.
   Avoid unnecessary acronyms without explanation.

4. **Concrete examples**: Every abstract concept should have
   a concrete example.

When applying this skill, flag any violations you find
and suggest improvements.

Field	Required	Default	Description
`name`	No	Filename without a trailing `.md`; other extensions are retained	Identifier the LLM uses with `load_skill`
`description`	No	Same as `name`	When to use this skill (shown in system message)
Body	Yes	-	Full instructions returned by `load_skill`

If you omit the frontmatter entirely, the filename without a trailing .md is used as both the name and description. Other extensions are retained, so tone.txt defaults to name: "tone.txt" and description: "tone.txt". Write good descriptions. They’re what the LLM uses to decide whether to load a skill. “Rules for writing clear, readable technical content” is better than “clarity_guidelines”.

Start Here

Workflows

Steps

Prompts

Clients

Costs

Evaluators

Production Readiness

Deployment

Integrate with Your App

Packages

Releases

How Skills Work

Providing Skills

Skill File Format

​How Skills Work

​Providing Skills

​Skill File Format

How Skills Work

Providing Skills

Skill File Format