Skill creator

Skill cloverink/shipwright/skills/skill-creator

Meta-skill that teaches how to create effective Claude Code skills. Covers anatomy, progressive disclosure, validation, and packaging.From its SKILL.md

Install

npx -y skills add cloverink/shipwright --skill skill-creator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, 790 tokens by cl100k_base, as published. Nobody here has run it

/skill-creator

A skill for creating skills. Use this when building new skills or improving existing ones.

Skill Anatomy

my-skill/
├── SKILL.md              # Main skill file (YAML frontmatter + instructions)
├── references/           # Supporting docs loaded on demand
│   ├── patterns.md
│   └── examples.md
└── scripts/              # Optional automation scripts
    └── validate.sh

SKILL.md Structure

---
name: my-skill
description: One-line description used for skill discovery and relevance matching
model: opus               # Optional: opus, sonnet, or haiku
---

# /my-skill

[Core instructions — what to do, how to do it, when to stop]

Design Principles

1. Progressive Disclosure

Don't dump everything into SKILL.md. Layer information:

Layer	Where	When loaded
Discovery	`name` + `description` in frontmatter	Always (~20 tokens)
Core instructions	SKILL.md body	When skill is invoked (~500-2000 tokens)
Deep reference	`references/*.md`	On demand, when needed

2. Degrees of Freedom

Match the skill's rigidity to its purpose:

Rigid skills (debugging, TDD): Follow exactly. Steps are a discipline, not suggestions.
Flexible skills (design, architecture): Adapt principles to context. Steps are guidelines.

State which type your skill is. Ambiguity leads to shortcuts.

3. Actionable Instructions

Write instructions that Claude can execute, not descriptions of what a human would do.

# Bad — describes, doesn't instruct
"The review process involves examining code for quality issues."

# Good — actionable
"Read every changed file end-to-end. For each file, check:
1. Type safety — no `any`, explicit return types
2. Security — no secrets, input validation
List issues as [severity] [file:line] description."

4. Exit Conditions

Every skill must define when it's done:

# Bad — no exit condition
"Review the code and fix issues."

# Good — clear exit
"Review → fix → re-review. Exit when score > 9 or after 3 rounds."

Creation Process

Define the trigger — when should this skill activate? Be specific.
Write the happy path — what does the skill do when everything works?
Add failure modes — what happens when things go wrong? When does it stop and ask the user?
Add configuration points — mark project-specific values with  comments.
Test with real tasks — invoke the skill on actual work. Does it produce good results?
Iterate — skills improve with use. Update based on what works.

Validation Checklist

Before publishing a skill:

Frontmatter has name and description
Description is specific enough for relevance matching
Instructions are actionable (Claude can execute them)
Exit conditions are defined
Configuration points are marked
No hardcoded project-specific values in the main instructions
Tested on at least one real task

Packaging for Distribution

If publishing skills for others to use:

Add skill path to .claude-plugin/plugin.json
Mark all project-specific values with  and document defaults
Include a references/ folder for deep-dive docs
Add the skill to the README with a one-line description

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most skill authoring skills give in 790 tokens

Counted across 408 of the 422 authors here whose files we hold, read 2026-09-06

Keep SKILL.md under 500 linesin 118 of 408, across 104 files
Write skill instructions in imperative formin 44 of 408, across 37 files
Move detailed reference material into references filesin 41 of 408, across 34 files
Run init_skill.py to initialize new skillsin 40 of 408, across 33 files
Draft assertions while test runs are in progressin 32 of 408, across 25 files
Keep description under 1024 charactersin 31 of 408, across 18 files
Run package_skill.py once the skill is completein 29 of 408, across 23 files
Spawn with-skill and baseline runs in the same turnin 28 of 408, across 21 files
Test added scripts by actually running themin 27 of 408, across 21 files
Follow the creation steps in orderin 24 of 408, across 17 files
Generate the eval viewer before evaluating outputs yourselfin 24 of 408, across 17 files
Write the description in third personin 24 of 408, across 18 files

Said here and by no other author read

Layer skill content across frontmatter, body, and references
State whether the skill is rigid or flexible
Define exit conditions for every skill
Define a specific activation trigger
Write the happy path
Add failure modes and stop conditions

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.