skill-creator

Skill Creator

Turn a capability idea into a committable SKILL.md that meets the paid-quality bar. The costly mistake this prevents: writing a competent essay about the topic instead of an operating procedure - a skill that reads well and changes nothing about the model's output.

The bar

The skill you write ships only if all of these hold:

• It fires on exactly the right requests and never on the wrong ones. The description front-loads concrete triggers a router can act on with no ambiguity.
• It does not collide with any existing skill. Before writing, check the catalog for trigger overlap and carve clean boundaries into both descriptions.
• Its body carries the full anatomy (skill-author is the canonical standard): framing, ordered procedure, input elicitation, concrete thresholds, at least one worked artifact, an explicit deliverable, a Do NOT section, and a quality bar.
• It is token-disciplined. The description loads every session; the body loads on trigger. Every line is paid for by every installer, every session.
• It is correct and self-contained - real tools, real paths, real practitioner numbers; no hallucinated capabilities; no context it hasn't established.

Operating procedure

1. Find the trigger first. Before any body text, answer: what exact request should make this fire? Name concrete signals - task verbs, named artifacts, file types, the phrases a user would actually type. If you cannot name them precisely, the skill is not ready to write; press for the real use case.

2. Check for collisions. Search the catalog (browse_skills) for skills whose triggers could fire on the same request. Carve the boundary and write it into both descriptions as negative scope. A new skill that steals a neighbor's territory is a defect.

3. Gather the domain substance. Collect the frameworks, thresholds, and templates the skill will encode - from the requester, or from established practitioner methods you name. A skill with no numbers and no artifact is an essay; if the substance is not available yet, say what is missing rather than padding around it.

4. Write the description - trigger first. WHAT + WHEN + NOT (skill-description-writer is the canonical standard): open with when to activate, quoting real user phrasing; state what it produces; append "Do NOT use for X - use <slug> instead" wherever a misfire into a named neighbor is plausible.

5. Write the body in anatomy order. Framing paragraph (outcome + the mistake prevented), numbered procedure with dependency reasoning, input elicitation with defaults, thresholds with real numbers, worked artifact (filled example, good/bad pair, FILL-field template, or runnable calculator with expected output shown - fenced code blocks are correct here), Deliverable, Do NOT with the why, quality bar, and an escalation boundary where the domain touches legal, medical, or financial ground.

6. Set name and slug. Name in Title Case; slug in kebab-case matching the dominant noun. Match the house voice of the existing catalog so the set reads as one author.

7. Self-check, then hand to skill-auditor. Re-read the description cold: fires on the right request, silent on a near-miss? Re-read the body: could a practitioner execute without a clarifying question? Is there an artifact they could copy out and use as-is? Then state the skill is ready for a skill-auditor pass before publishing.

Deliverable

A single committable SKILL.md - valid frontmatter (name, description) plus the full-anatomy body - at the correct slug/SKILL.md path. No commentary baked into the file.

Do NOT

• Do not write the body before the trigger is nailed. A vague trigger produces a skill that never fires or always fires, however good the body.
• Do not ship an essay. If the body has no procedure, no numbers, and no artifact, it does not clear the bar - get the substance or say what is missing.
• Do not pad: no preamble, no hedging, no restating what the model already knows. If a line does not change behavior, cut it.
• Do not ship territory collisions; fix the boundary in both descriptions before delivering.
• Do not put dates, versions, or "latest" anywhere in the file.
• Do not grade existing skills here - that is skill-auditor's job; hand off rather than absorbing its scope.