One install gives your agent an authoring workflow for a brand-new skill, starting from nothing but "I want an agent that does X": three or four requests it should catch and one it should refuse, the description of every installed sibling those requests touch, a boundary in both directions, then scripts versus references versus assets, a description written last that actually triggers, and a validator run before handoff.
install
Detects Claude Code, Cursor, Codex, Qoder and more, then writes the skill into the right folder. Validation calls check_skill.py from tune-skill — install that too, or step 7 is done by hand.
npx skills add arm-pz/draft-skill --skill draft-skill
the workflow
Two things fail silently in production, and neither one errors: a description that promises a step the body never performs, and a name that already belongs to a better-established project. The steps below exist to catch those two, not to fill in a template.
Three or four requests the skill should catch, one it should refuse, and what the output looks like.
Read every sibling description the examples touch — from the file, not from memory or a README.
One line for what this owns, one for where it stops and who takes over. Both are shown before anything is written.
Create only the directories you actually fill. If all three are empty, the skill is prose and that is fine.
Lowercase, hyphenated, short, verb-led, and the folder named exactly after it. Checked on GitHub first.
Frontmatter is name and description. The description is written last.
Run the sibling tool on the folder, then work through what it cannot see.
In tune-skill's case format. The examples from step 1 become the clear triggers.
Not for tightening a skill that already exists — that is tune-skill. Not for turning a batch of your own prompts into a skill — that is prompts-to-skill. Releasing a finished one goes to prompts-to-skill-release; the repo name and listing go to findable. Say which handoff you are making and what the next skill receives — "use tune-skill next" transfers no context.
ground rules
Restate the purpose, the expected output, and the phrases the user would really type. Wait for a yes. A skill drafted on a guessed purpose triggers on the wrong requests forever, and the fix costs a re-publish.
The agent reading this already knows what Python is. Keep only what it would otherwise get wrong: your conventions, your file names, your order of operations, your gotchas. A reference nobody is pointed at is dead weight.
The report names which checks ran, which test cases were only written, and which siblings were never opened. A script that has never been run, or an install command for an agent nobody installed on, is labelled unverified instead of working.
Free, open, and it writes only what you confirmed. Validating needs tune-skill installed beside it.
Install draft-skill Read the source