Skill Creator — Skill Smith
"Build your own skills"
When to use
- "Make me a skill for " — anything you've done three times deserves a SKILL.md
- "Turn this workflow into a skill" after a session that went well
- "Add a new employee to " in this repo
- "My skill never triggers" / "the wrong skill fires" — description surgery
- Standardizing a process so the whole team runs it the same way
Workflow
- Interview for the job-to-be-done: the task, three real phrasings the user would type to ask for it, available inputs, the artifact that means "done", and what must never happen.
- Choose the slug: lowercase, hyphenated, specific (
api-changelog, not helper); check skills/ for collisions.
- Write the description before the body — it is the trigger. Third person, capability first, then "Use when ..." quoting the phrasings from step 1. Hard limit 500 characters.
- Write the body in this repo's format:
# Name — Role, quoted tagline, ## When to use, ## Workflow (5–9 executable steps), ## Output format (code-block template), ## Quality bar (checkboxes), ## Example.
- Save to
skills/<slug>/SKILL.md — directory name must equal frontmatter name, exactly.
- Trigger-test with five paraphrased asks: a synonym rewrite, a vague version, a jargon version, an adjacent-but-different task (must NOT fire), and the exact phrase. Judge each against the description alone.
- Iterate the description until at least 4/5 positives fire and the negative stays quiet — widen with user vocabulary, narrow with distinguishing nouns.
- Dry-run the workflow once end to end; rewrite any step that needed unstated context.
Frontmatter contract
---
name: <slug> # must equal the directory name, lowercase-hyphenated
description: <capability + "Use when ..." with real user phrases; third person; under 500 chars>
---
Body sections, in order: title with role, tagline quote, When to use, Workflow, Output format, Quality bar, Example.
Trigger-miss failure modes
- Describes implementation, not the job — "uses Playwright" instead of "browser-tests your app". Users ask for jobs.
- Zero quoted user phrases — the matcher has nothing to catch.
- Too generic — collides with sibling skills and the wrong employee shows up.
- Over 500 characters — the tail gets diluted exactly where your triggers live.
- First-person or imperative voice — reads like instructions, not a capability index.
Output format
skills/<slug>/SKILL.md (created)
Trigger test:
| Ask (paraphrase) | Should fire | Fired |
|---|---|---|
| <synonym rewrite> | yes | yes |
| <vague version> | yes | yes |
| <jargon version> | yes | yes |
| <adjacent task> | no | no |
| <exact phrase> | yes | yes |
Score: 5/5 — shipped
Quality bar
Example
Ask: "Turn our release-notes ritual into a skill."
Produced: skills/release-notes/SKILL.md — description quoting "write the release notes", "what changed this sprint", and "draft the changelog"; a 7-step workflow from git log to published notes; trigger test 5/5, with the adjacent ask "write API docs" correctly staying quiet.
1---2name: skill-creator3description: Authors new SKILL.md employees for this repo — interviews for the job-to-be-done, picks a slug, writes a trigger-rich description under 500 chars, fills the standard body sections, then tests triggering against five paraphrased asks and iterates. Use when the user says "make me a skill for X", "turn this workflow into a skill", "add a new employee to the team", or "my skill never triggers".4---56# Skill Creator — Skill Smith78> "Build your own skills"910## When to use1112- "Make me a skill for <recurring task>" — anything you've done three times deserves a SKILL.md13- "Turn this workflow into a skill" after a session that went well14- "Add a new employee to <department>" in this repo15- "My skill never triggers" / "the wrong skill fires" — description surgery16- Standardizing a process so the whole team runs it the same way1718## Workflow19201. Interview for the job-to-be-done: the task, three real phrasings the user would type to ask for it, available inputs, the artifact that means "done", and what must never happen.212. Choose the slug: lowercase, hyphenated, specific (`api-changelog`, not `helper`); check `skills/` for collisions.223. Write the description before the body — it is the trigger. Third person, capability first, then "Use when ..." quoting the phrasings from step 1. Hard limit 500 characters.234. Write the body in this repo's format: `# Name — Role`, quoted tagline, `## When to use`, `## Workflow` (5–9 executable steps), `## Output format` (code-block template), `## Quality bar` (checkboxes), `## Example`.245. Save to `skills/<slug>/SKILL.md` — directory name must equal frontmatter `name`, exactly.256. Trigger-test with five paraphrased asks: a synonym rewrite, a vague version, a jargon version, an adjacent-but-different task (must NOT fire), and the exact phrase. Judge each against the description alone.267. Iterate the description until at least 4/5 positives fire and the negative stays quiet — widen with user vocabulary, narrow with distinguishing nouns.278. Dry-run the workflow once end to end; rewrite any step that needed unstated context.2829## Frontmatter contract3031```32---33name: <slug> # must equal the directory name, lowercase-hyphenated34description: <capability + "Use when ..." with real user phrases; third person; under 500 chars>35---36```3738Body sections, in order: title with role, tagline quote, When to use, Workflow, Output format, Quality bar, Example.3940## Trigger-miss failure modes4142- Describes implementation, not the job — "uses Playwright" instead of "browser-tests your app". Users ask for jobs.43- Zero quoted user phrases — the matcher has nothing to catch.44- Too generic — collides with sibling skills and the wrong employee shows up.45- Over 500 characters — the tail gets diluted exactly where your triggers live.46- First-person or imperative voice — reads like instructions, not a capability index.4748## Output format4950```51skills/<slug>/SKILL.md (created)5253Trigger test:54| Ask (paraphrase) | Should fire | Fired |55|---|---|---|56| <synonym rewrite> | yes | yes |57| <vague version> | yes | yes |58| <jargon version> | yes | yes |59| <adjacent task> | no | no |60| <exact phrase> | yes | yes |6162Score: 5/5 — shipped63```6465## Quality bar6667- [ ] `name` equals the directory slug, exactly68- [ ] Description is third person, under 500 chars, and quotes real user phrasings69- [ ] Workflow steps are executable with zero unstated context70- [ ] Output format is a copy-paste template, not a description of one71- [ ] Trigger test scores at least 4/5 and the adjacent negative stays quiet72- [ ] Example shows one real ask and the artifact it produced7374## Example7576Ask: "Turn our release-notes ritual into a skill."7778Produced: `skills/release-notes/SKILL.md` — description quoting "write the release notes", "what changed this sprint", and "draft the changelog"; a 7-step workflow from `git log` to published notes; trigger test 5/5, with the adjacent ask "write API docs" correctly staying quiet.