my-skill-name

## Overview Describe the skill's purpose in 2–4 sentences. Name the problem, the trigger, and the outcome. No fluff. ## Mental model <!-- Optional but recommended for any skill with >3 rules. The framing concept that makes the rules read as a system, not a list. Skip if the skill is purely mechanical. --> The core principle that governs all the rules below: ... ## Rules <!-- The bulk of the skill. Tables for decisions, bullet lists for sequential rules, prose only when WHY is non-obvious. Never paragraph-after-paragraph. --> ### Core rules - Rule 1: ... - Rule 2: ... - Rule 3: ... ### Decision guide | Situation | Action | |-----------|--------| | Case A | Do X | | Case B | Do Y | ### Workflow (if applicable) 1. Step one — description 2. Step two — description 3. Step three — description ## Examples <!-- Bad → Good is the strongest format. Show the AI tell, then the fix. --> ### Example 1: Bad → Good ❌ Bad: ``` [the wrong way] ``` ✅ Good: ``` [the right way] ``` What changed: <one-line explanation> ### Example 2: Edge case <!-- Describe what makes this tricky and how to handle it. --> ## Checklist <!-- Recency: this is the last actionable thing the model sees, so it acts as a final gate. Verifiable items only — "does X have Y" not "make sure quality is high". --> - [ ] <verifiable check> - [ ] <verifiable check> - [ ] <verifiable check> ## Composition / References <!-- Within-domain skill pairings (do NOT name agents from other domains). External authoritative sources, spec links. --> - Pairs with `<sibling-skill-in-same-domain>` when ... - [Official documentation](https://example.com/docs) - [Specification](https://example.com/spec) <!-- Optional directories alongside this SKILL.md: validate — executable script: validates LLM output quality (exit 0 = valid) scripts/ — executable scripts the skill references references/ — supplementary documentation (REFERENCE.md, FORMS.md, etc.) assets/ — templates, config files, other resources -->