The Claude Skill Creator

---
name: skill-creator
version: 2.3.0-generic
description: >
  Use when anyone needs to create, rebuild, audit, evaluate, or chain Claude skills.
  Fires on "build a skill," "rebuild this skill," "is this skill any good," "create a
  skill for," "I need a skill that," or any request to create, review, scope, or connect
  skills. Works through skill anatomy using the Nathaniel Method, maps how each skill
  chains with others, checks against the 5 Skill Killers, and produces a complete skill folder.
---
# The Claude Skill Creator — the Nathaniel Method
How to build skills for any team, any workflow, any tool. Inspired by Nathaniel Whittemore's
(NLW) Skills Master Class on The AI Daily Brief podcast. If you are creating, rebuilding,
auditing, or connecting skills, start here.
> This is a starting point, not a finished skill. Make it yours. Swap in your own trigger
> phrases, your own files and paths, your own brand and voice rules, and your own team's
> folders before you run it. A skill copied without adaptation is a 70%-right skill.
## Before You Start
Point the skill at your own context, not someone else's.
- Your repo's `CLAUDE.md` or equivalent — structure, format rules, team roles
- Your "what good looks like" file — a couple of reference skills to model
- Your brand, voice, and banned-word rules, if you have them
- Your testing or evaluation checklist
## Two Skill Types — Know Which You're Building
**Capability Uplift** enables functions the model can't do well on its own. Research with
confidence scoring, multi-source fact-checking, structured analysis. These may become
obsolete as models improve. Build them, but check their shelf life quarterly.
**Encoded Preference** sequences existing capabilities according to YOUR workflow. Morning
briefings, companion guides, branded content pipelines. These get MORE valuable over time
because they encode how your team actually works. Put most of your effort here.
## The Scoping Rule
One clear job per skill. If you cannot describe what the skill does in one sentence, it's
probably two skills.
## Step 1 — Name and Description
Name is lowercase, hyphens, max 64 chars. Gerund form when possible (analyzing-data,
preparing-meetings).
Description is the most critical line in the entire skill. This is the TRIGGER — it determines
whether the skill fires when it should and stays quiet when it shouldn't.
Write it for the model asking "when should I fire?" Not for a human browsing a catalog.
Format
- Third person (this gets injected into system prompts — "I can help you" breaks things)
- Start with "Use when the user says..." followed by exact trigger phrases
- Include edge-case triggers people actually say ("before I send this," "is this solid")
- End with one sentence describing what the skill does
- Under 250 characters
- Be explicit rather than quiet — models skip past quiet descriptions
Draft the description FIRST. Get the trigger right before writing anything else.
Test it mentally — say the trigger phrase — would it fire? Say three similar sentences —
would it fire when it shouldn't?
## Step 2 — Context Required
List every file the agent should read before running. Don't assume the agent remembers
anything from prior sessions. Use full paths.
"About the skill" goes inside the folder — rubrics, templates, examples, output skeletons.
"About the org" points externally — your CLAUDE.md, brand rules, stakeholder lists, team context.
If the skill needs calendar data, database records, meeting transcripts, or chat history,
say so explicitly. Name the source and the tool that accesses it.
## Step 3 — Instructions
Numbered steps. Not prose.
Set degrees of freedom for each step
- TIGHT for fragile operations (brand enforcement, data normalization, pipeline sequencing)
- LOOSE for creative tasks (drafting, brainstorming, naming)
Challenge every paragraph with "Does the model already know this?" If yes, cut it. Don't waste
tokens teaching the model things it already knows.
Don't add identity/role sections ("Act as a senior analyst..."). That's legacy prompting.
Instead, explain what YOUR approach does differently and why.
## Step 4 — Output Format
Show a literal template or example. Headers, structure, length constraints, formatting. Do not
describe what the output should look like in words. Show it.
If the output is an HTML artifact, show the structure with placeholder content.
If the output is a table, show the headers.
If the output feeds another skill, show exactly what that skill expects as input.
## Step 5 — Works With (Chain Metadata)
Every skill declares its relationship to other skills. This is how a library becomes an
ecosystem instead of a pile of utilities.
Four buckets
**Chains upstream from** — skills whose output this skill can ingest. Flag each as MANDATORY or
OPTIONAL. If optional, note what changes when it's present vs. absent.
**Chains downstream to** — skills that can consume this skill's output. Name them and describe
what format they expect.
**Pairs well with** — skills commonly used in the same session that don't have an artifact
dependency. Think companion tools.
**Standalone mode** — what this skill delivers when run with no upstream or downstream
connections. Every skill must work on its own, even if chains make it better.
If a skill has no chain connections, the section still appears — explicitly noting "runs
standalone, no chain connections." Absence is data too, not an omission.
## Step 6 — Gotchas
This is the HIGHEST-SIGNAL content in any skill. Document every failure pattern observed.
Format as "I know you'll want to [wrong thing] — don't. [Right thing instead]."
If the skill is new and has no failure history, write the gotchas you can predict from
experience, then add the section header "Add to this list as failures surface."
Gotchas belong IN the skill, not in memory files. Memory files don't run at execution time.
## Step 7 — Constraints
What NOT to do. Sharp and specific to THIS skill. Not generic "be accurate" rules — constraints
that prevent the specific things that go wrong in THIS workflow.
## Step 8 — Check Against the 5 Skill Killers
Run every skill through this before it ships.
1. **Vague description** — Too quiet, too broad, wrong person. Fix with specific,
   third-person "Use when..." trigger language that names exact phrases.
2. **Over-defined process** — Railroading instead of guiding. Fix by setting degrees of freedom.
   Tight where it matters, loose everywhere else.
3. **Stating the obvious** — Wasting tokens on things the model already knows. Challenge every
   paragraph. If it's general knowledge, cut it.
4. **Missing gotcha section** — Not capturing failure patterns. The gotcha section IS the skill's
   long-term value. Start it on day one and keep adding.
5. **Monolithic blob** — Everything crammed into one file. Keep SKILL.md under 500 lines. Move
   reference material, examples, and templates to separate files in the skill folder.
## Step 9 — Folder Structure
Every skill is a folder. Minimum contents are SKILL.md plus whatever supporting files the skill
needs.
```
skill-name/
├── SKILL.md              (core instructions, under 500 lines)
├── examples.md           (good vs bad output — show both)
├── template.md           (output skeleton the skill fills in)
└── reference.md          (background material, rubrics, context)
```
Nested skills go in a `skills/` subfolder inside the parent folder.
Progressive disclosure matters
- Description (~100 tokens) is always loaded — it's how the system decides whether to fire
- SKILL.md body loads only when the skill triggers
- Folder contents load only when the skill references them
This means the description must work hard. The body should assume the model committed to running
this skill. Supporting files should contain detail the body references but doesn't repeat.
## Step 10 — Team Placement and Ownership
Skills live in shared repos. Every skill you build may be used by someone other than the person
who requested it.
**Shared skills** are used by anyone on the team. Write them so they work without the skill
creator in the room. Include enough context that any team member can run them cold.
**Personal skills** are tuned to one person's voice, process, and judgment calls. They may
reference team systems but reflect individual workflow.
**Ownership has two layers**
- The **skill creator** is the person who built it and maintains the gotcha section as failures
  surface
- The **repo owner** is the person who controls what gets committed, distributed, and deprecated
These may or may not be the same person. Make both roles clear in the SKILL.md if they differ.
## Step 11 — Versioning and Change Tracking
Every skill gets a `version` field in its frontmatter. Start at `1.0.0`.
**When to bump**
- **Major** (1.0 → 2.0) — structural changes to steps, output format, or scope. The skill
  behaves differently than before.
- **Minor** (1.0 → 1.1) — new gotchas, tweaked instructions, added context files. The skill works
  the same way but smarter.
- **Patch** (1.0.0 → 1.0.1) — typos, clarifications that don't change behavior.
Keep a consistent date format across your library. Put a changelog at the bottom of SKILL.md, one
line per change, most recent on top.
```markdown
## Changelog
| Date | Version | What Changed |
|------|---------|-------------|
| ... | 2.0.0 | Rebuilt. Added check-ins, closing question, versioning. |
| ... | 1.0.0 | Initial skill. |
```
**Git is the approval record.** The commit is the sign-off. If the skill creator and repo owner
are different people, the PR is the approval conversation.
## Step 12 — Brand and Voice Enforcement
Every skill that produces content must pass through your brand and voice enforcement rules BEFORE
the user sees the output. The user should never be the one catching violations.
If your team has a banned word list, run the skill's output against it. If you have structural
rules (heading formats, list patterns, sentence constructions), check those too. If you have voice
or tone guidelines, verify the output matches.
Build this into the skill itself. Add a step that says "Run brand enforcement before presenting
output." Don't rely on the skill creator to remember — make the skill do it automatically.
General rules that apply to all skills
- No identity/role sections ("Act as a...")
- Every content-producing skill should point to brand enforcement externally rather than
  duplicating brand rules inside individual skills
- External-facing output should include whatever footer, copyright, or contact info your org requires
- Run enforcement BEFORE presenting, not after. Dirty drafts should never reach the user.
## Step 12.5 — Generate a User Guide
A give-out-ready skill ships a user guide — a human-readable page that explains what the skill does,
how to trigger it, what it returns, and how to make it their own. Build it from your own branded
template so it looks like it belongs to your organization.
What the guide must do
- Explain the skill in plain language for someone who has never run it.
- Tell the reader to make the prompt theirs — adapt the triggers, files, brand rules, and voice to
  their own team before running it.
- Embed the full SKILL.md so the guide and the skill travel together.
- Carry your own footer, contact, and attribution.
## Step 13 — The Litmus Test
After the skill runs for the first time, ask yourself: did you have to edit the output?
If you found yourself restructuring, correcting tone, fixing format, or adding things the skill
should have included — the skill itself needs improvement. Go back and fix the instructions, output
template, or gotchas.
Well-built skills produce directly-usable output. If you're always editing after, the skill is
incomplete.
## Step 14 — Mid-Session Check-Ins
Every skill should pause 2-3 times during a session to ask the user diagnostic questions. These
catch skill drift before it compounds.
**After the first run**
- Are you editing the output right now? What are you changing?
- Is there information missing that you expected to see?
- Did the format match what you had in your head?
**After 2-3 more runs**
- Are you still editing, or is the output closer to usable?
- Have you noticed a pattern in what you keep fixing? (That pattern is a gotcha waiting to be added.)
- Is the skill triggering when you expect it to? Too often? Not enough?
**Before wrapping up**
- Did anything surprise you about how the skill behaved?
- Is there a failure pattern we should add to the gotcha section right now while it's fresh?
- Anything the skill assumed that it shouldn't have?
Build these check-ins into the skill's steps. They're how gotchas get captured and skills get better.
## Step 15 — The Closing Question
Every skill should end every session with this question
**"What else can I take off your plate?"**
This is not a courtesy. It surfaces adjacent work the user hasn't thought to delegate yet. The best
skills don't just finish their task — they open the door to the next one.
## Step 16 — Decisions Log
Before closing any skill build session, produce a DECISIONS LOG block. Every decision made during
the build — name chosen, trigger phrases locked, output format settled, version confirmed — gets one
line, ready to paste into wherever you track project decisions.
Skills accumulate decisions that get relitigated across sessions because nobody wrote them down. The
decisions log stops that.
## Gotchas
I know you'll want to run this skill exactly as written — don't. Make it yours first. Swap the
triggers, files, brand rules, and voice for your own.
I know you'll want to write a long preamble explaining what the skill is for — don't. The
description in frontmatter does that job.
I know you'll want to add an identity section ("Act as a senior analyst...") — don't. That's legacy
prompting. Explain what your approach does differently instead.
I know you'll want to describe the output format in words — don't. Show the literal template.
I know you'll want to scope a big workflow as one skill — don't. Apply the scoping rule. One clear
job per skill. Chain them if you need a pipeline.
I know you'll want to adopt a marketplace skill or copy someone else's wholesale — don't. Build your
own, or adapt deliberately. Quality varies, security is real, and creating from scratch teaches craft
faster than adapting someone else's 70%-right skill.
I know you'll want to duplicate brand enforcement rules inside each skill — don't. Point to one
canonical source.
I know you'll want to save lessons learned to a memory file instead of updating the skill's gotcha
section — don't. Gotchas belong IN the skill. That's where they get used.
I know you'll want to skip the mid-session check-ins because the skill seems to be working — don't.
That's exactly when hidden drift accumulates.
## Re-Evaluation Triggers
| When | What to Check |
|------|--------------|
| New model drops | Gotcha section might be solving problems the new model doesn't have. Capability Uplift skills may be obsolete. |
| Tool change | Moving between tools? Skills are portable but behaviors differ. Validate. |
| Results degrade | Before blaming the model — did YOUR context go stale? Check referenced files. |
| Before scaling | About to share with the full team or beyond? Run proper evals first. |
| Quarterly | Even if nothing seems broken. Review all skills against current workflows. |
## Constraints
- Make the skill yours before running it — adapt triggers, files, brand, and voice
- Keep SKILL.md under 500 lines — if you're over, split into supporting files
- Don't build skills that duplicate what another skill already does — check your library first
- Don't create skills for one-time tasks — skills encode repeatable workflows
- Every content-producing skill must include a brand enforcement step that runs BEFORE output is shown
- Every skill must declare Works With — even skills that run standalone note "no chain connections"
- Every skill must include mid-session check-in questions (Step 14)
- Every skill must end with "What else can I take off your plate?" (Step 15)
- Security warning for any skill that uses external tools or third-party connections — treat skill
  installation like installing a browser extension
## Credit
Inspired by Nathaniel Whittemore (NLW) — host of The AI Daily Brief podcast and founder of
Superintelligent — and his Skills Master Class. This method is our adaptation of the ideas he taught.
## Changelog
| Date | Version | What Changed |
|------|---------|-------------|
| 07.09.26 | 2.3.0-generic | Generic give-out version. Stripped organization-specific paths, templates, and brand blocks; added the "make it yours" rule throughout and explicit credit to Nathaniel Whittemore. |