---
id: "framework-skill-anatomy"
type: "framework"
source_timestamps: ["00:01:14"]
tags: ["prompt-engineering", "file-structure", "skill-design"]
related: ["concept-claude-skills", "claim-description-importance"]
steps: ["Frontmatter: Define the skill name and the trigger description (how Claude knows when to fire it).", "Instructions: Detail the workflow, the rules the AI must follow, and the exact output format in plain English.", "Examples: Provide optional sample inputs and outputs to lock in the desired voice and format (few-shot prompting)."]
---
# Anatomy of a Claude Skill

## The three-part structure

Every functional [[concept-claude-skills]] file follows the same anatomy. Get any layer wrong and the Skill either won't fire, won't follow rules, or won't sound like you.

### 1. Frontmatter (routing layer)

Contains the **skill name** and the **trigger description**.

- The description is the routing key — Claude reads it to decide whether to fire this Skill for the current request.
- This is the single most leveraged element in the file — see [[claim-description-importance]] and [[contrarian-description-over-instructions]].
- Phrase the description in the natural language a user would actually type.

### 2. Instructions (execution layer)

The core prompt logic. Must explicitly cover:

- **Step-by-step workflow** — what to do, in order.
- **Negative constraints** — what NOT to do (no emojis, no clichés, no hedging language, etc.).
- **Output format** — exact structure (markdown table, numbered list, JSON, etc.).

### 3. Examples (calibration layer)

Optional but high-leverage. A few input/output pairs (few-shot prompting) tune the model's tone, formatting, and edge-case behavior before it sees real input.

## Worked examples in this vault

- [[framework-six-hook-patterns]] — calibration layer hardcoded as six explicit pattern buckets.
- [[action-build-thumbnail-skill]] — instruction layer encodes brand typography rules + [[concept-face-lock]] language.

## Caveat (from enrichment)

Modern tool-routing schemes typically consider tool names, parameter schemas, examples, and sometimes historical usage in addition to descriptions — so a balanced build invests in **all three layers**, not just the frontmatter.