Master
Office Skills

Each Skill is built on a SKILL.md file structured in two parts:
The frontmatter (YAML header between ---): contains metadata — name, description, trigger (when the Skill fires automatically) and allowed-tools (accessible tools).
The body: natural language instructions that Claude will execute.
Frontmatter example:
---
name: audit-budget
description: Audits Excel budget files for hardcodes and formula errors. Use when working with .xlsx budget files.
trigger: when the user asks to audit a budget or mentions budget review
---

The trigger field in the frontmatter allows Claude to automatically fire the Skill when certain conditions are met — without the user typing /.
Examples: "when the user mentions cleaning data", "when an Excel file with sales data is opened".
A well-written trigger reduces friction: users don't even need to know the Skill's name.

The progressive disclosure technique structures Skill instructions in layers: essential instructions first, advanced details later. Claude only reads the deeper layers when they become relevant. This reduces token cost and avoids overloading the context for simple cases.

Context is a shared resource. Anthropic recommends keeping the SKILL.md body under 500 lines and moving long content (APIs, examples, reference data) into separate files loaded on demand. Claude only reads them when they become relevant — zero token cost until then.

The documentation defines three levels based on error risk:
High freedom → general text instructions (multiple valid approaches)
Medium freedom → pseudocode or parameterised scripts (preferred pattern, some variation allowed)
Low freedom → exact script to run as-is (fragile operation, critical sequence)
Analogy: narrow bridge with cliffs = precise instructions; open field = general direction.

A Skill that works well on a powerful model (Claude Opus or Sonnet) may be insufficient on a lighter model (Haiku) which needs more context, and over-explained for Opus which already knows. Systematically test with each model intended for production before deploying. The latest models are the Claude 5 family (Opus 5, Sonnet 5) and Haiku 4.5.

Anthropic recommends the gerund form for Skill names: analyzing-spreadsheets, processing-pdfs, generating-reports.
Technical rules: lowercase, digits and hyphens only · max 64 characters · no reserved words (anthropic, claude) · no XML tags.
Avoid vague names: helper, utils, data.

The description is injected into Claude's system prompt. It must describe what the Skill does and when to use it, always in the third person.
✓ "Analyzes Excel spreadsheets and generates pivot reports. Use when working with .xlsx files."
✗ "I can help you analyze your Excel files."
A vague description ("Helps with documents") prevents Claude from selecting the right Skill among 100+ available.

Beyond manual sharing (copy-pasting the prompt), Anthropic offers a plugin mechanism to distribute Skills at scale. A plugin bundles multiple Skills and can be installed with one click by team members. In Enterprise contexts, plugins can be deployed centrally via the admin console.

For critical or batch operations (form filling, data migration, bulk edits), plan a do → validate → fix → repeat cycle. Example: generate a JSON plan → validate with a script → apply changes → verify the output. This pattern catches errors before they propagate.

The documentation recommends a dual-role approach:
Claude A (expert) → helps draft and refine the Skill
Claude B (agent) → fresh instance that uses the Skill on real tasks
Observing how Claude B navigates the Skill reveals blind spots the author can't see. Repeat the observe → refine → test cycle until stable.