← ClaudeAtlas

better-skill-creatorlisted

Use this skill for anything to do with authoring, fixing, or measuring Claude skills. Reach for it whenever someone wants to turn a repeated workflow, house format, template, or set of team conventions into something Claude applies automatically every time, even when they never use the word 'skill' and only describe the outcome they want. Also use it when a SKILL.md already exists and misbehaves: it never fires, it fires on the wrong things, the frontmatter will not validate, it has grown too long to follow, or its outputs are inconsistent. Use it to word a description so triggering is reliable, to run evals comparing a skill against a no-skill baseline to find out whether it actually helps, to decide whether something should be a skill at all, and to package one so teammates can install it. Consult it even when the SKILL.md is sitting right there and the format looks simple enough to answer from memory.
OpenCnid/better-skill-creator · ★ 1 · AI & Automation · score 75
Install: claude install-skill OpenCnid/better-skill-creator
# Better Skill Creator Build a skill, find out whether it actually helps, and improve it on the evidence. The loop: 1. Work out what the skill should do, and whether it should be a skill at all 2. Draft it, and validate the draft immediately 3. Run it against real test prompts — with the skill and without — so you have a comparison 4. Put the results in front of the person and get their read 5. Improve it on what you both learned 6. Repeat until it stops getting better 7. Tune the description so it actually triggers, then package it Your job is to work out where in that loop this person already is, and start there. Someone saying "I want a skill for X" needs step 1. Someone arriving with a draft needs step 3. Someone saying "it never fires" needs step 7 and nothing else. And if they say "skip the evals, just work with me on it" — do that. The loop is a default, not a gate. ## Read this before you trust a number The costliest failure here is not a crash but a measurement that looks fine and means nothing — a benchmark computed from zero discovered runs, a trigger score from probes that never executed, a token column derived from character counts. The tooling refuses instead of guessing: zero runs exits non-zero, unmeasured values render `—` and never `0`, an errored probe is recorded as an error and not as a clean negative. So **if a number looks surprising, check it came from data before acting on it**, and when you report results say what was measured and what wasn't.