Skill Documentation

A skill's documentation is its description, instructions, and examples. Written for Claude (who reads it to decide invocation and behavior) and for humans (who maintain it and decide whether to use it).

This page covers what good skill documentation looks like.

What needs documenting

Description

The frontmatter description is the most-read piece. Brief; specific; matches the user's mental model of when this skill is needed.

```yaml

description: Reviews code for adherence to project guidelines, style guides, and best practices. Use proactively after writing or modifying code.

```

Specific (code review); contextualized (after writing/modifying); proactive trigger (when to use without being asked).

Instructions

The body of SKILL.md. Tells Claude what to do.

Structure:

- Purpose / when to use

- Workflow / steps

- Examples

- Common pitfalls

Length: long enough to be specific; short enough to be applicable.

Examples

Real input/output examples. Usually the most-useful piece.

```markdown

Example: User asks "review this PR"

Steps:

1. git diff main..HEAD

2. Identify changes

3. Apply review checklist

4. Report findings

Output:

- Style: 2 issues

- Logic: 1 issue

- ...

```

Concrete examples disambiguate better than abstract description.

When NOT to use

Some skills should NOT be invoked in certain cases. Document these:

```markdown

SKIP when:

- The user just wants to commit (no review needed)

- The change is trivial (one-line typo fix)

- The file is auto-generated

```

Documentation for humans

In addition to Claude-facing documentation, skills often need human docs:

Installation

How to install/enable the skill. Path; configuration; dependencies.

What it does

Brief explanation for users browsing skills.

Examples of use

When would I use this? Sample interactions.

Limitations

What doesn't this skill handle? Where's it not the right tool?

Maintenance

Who maintains it; how to report issues; how to contribute.

Patterns that age well

Short primary description

The frontmatter description is the most-read piece. One or two sentences.

Hierarchical detail

SKILL.md has the essentials. References folder has depth. Claude reads SKILL.md always; references when relevant.

```

my-skill/

├── SKILL.md (overview, key points)

└── references/

├── api-spec.md (read when API details needed)

└── examples.md (read for examples)

```

This keeps SKILL.md scannable.

Concrete language

"Use parameterized queries" beats "ensure security best practices."

Structured sections

Headings, bullet points, code blocks. Skim-friendly.

Living examples

Examples that match real usage. Update when usage changes.

Versioning

For skills shared widely:

```yaml

---

name: my-skill

description: ...

version: 2.1.0

---

```

Helps users know if a behavior change is intentional.

What ages poorly

Marketing language

"Powerful, intelligent, comprehensive..." Useless.

Vague advice

"Follow best practices." What practices?

Self-referential

"This skill is awesome." Tells nothing about behavior.

Outdated examples

Code samples for an API that's changed. Misleading.

Too much theory

Page on what skills are; user wants to know what this specific skill does.

Specific patterns

Trigger documentation

Make triggers explicit:

```markdown

When to use

USE when:

- User asks for [specific request]

- Code shows [specific pattern]

- Workflow includes [specific step]

DON'T USE when:

- [explicit exclusion]

- [another exclusion]

```

Workflow steps

For multi-step skills:

```markdown

Workflow

1. **Identify scope**: what's being changed?

2. **Plan**: write design doc

3. **Implement**: TDD

4. **Verify**: tests pass; build succeeds

5. **Review**: invoke code-review skill

Each step has its own subsection if needed.

```

Common pitfalls

A "Common Failure Patterns" section. Helps Claude avoid known issues.

Examples gallery

Multiple examples covering different scenarios:

```markdown

Examples

Simple case

[example]

Complex case

[example]

Edge case: when X

[example]

```

Cross-references

Link to related skills:

```markdown

See Also

- `brainstorming` — invoke before this for new features

- `writing-plans` — invoke before implementation

- `requesting-code-review` — invoke after this

```

Scaling documentation

For organizations with many skills:

Skill catalog

Central index of all skills. What each does; how to use.

Conventions

Standardized format for SKILL.md across the organization. Consistency helps Claude apply them similarly.

Reviews

Skill changes should be reviewed like code. Skills affect Claude's behavior; reviews catch issues.

Versioning and changelog

Track changes. Especially important for skills used in production workflows.

Common failure patterns

- **Description that doesn't match what users say.** Skill not invoked.

- **No examples.** Behavior unclear.

- **Too much abstract description.** Not actionable.

- **No human-facing documentation.** Users can't discover; can't troubleshoot.

- **Outdated content.** Misleading.

- **No versioning.** Changes affect users without notice.

Further Reading

- [CustomSkillsArchitecture](CustomSkillsArchitecture) — Skill basics

- [SkillComposition](SkillComposition) — Composition needs documentation

- [SkillDebugging](SkillDebugging) — Diagnostic adjacent

- [TechnicalWritingGuide](TechnicalWritingGuide) — General writing principles

- [AgenticAi Hub](AgenticAiHub) — Cluster index