module 09 build skills

skill-creator-skill

System Text-to-Speech Ready
Slide: 0:00 / 0:00
Slide 1 of 0Interactive Deck

Full Lesson Reference

Skill Creator

When invoked, help the user build a new skill from scratch. Do not just write the file - interview them first, test it, then save.

Approach

  1. Clarify the job. Ask one question at a time until you understand:

    • What the skill does (one sentence)
    • When it should trigger (what the user types or describes)
    • Inputs it needs (file paths, client names, date ranges, data sources)
    • Output shape (format, location, who it's for)
    • Non-negotiable rules (never fabricate, always source, specific tone)
    • Edge cases the user has already hit manually
  2. Draft the SKILL.md. Structure:

    • Frontmatter: name (lowercase-hyphens) + description (under 200 chars, specific about when to use)
    • Intro line explaining when to invoke
    • Numbered "Approach" or "Steps" section
    • "Rules" section for non-negotiables (use CAPS for the hard ones)
    • Optional "Output format" if the output shape is consistent
  3. Test with sample input. Before saving, run the skill in the current session against a realistic example. Show the output to the user. Confirm it matches their mental model.

  4. Iterate. If the output is off, ask what's wrong, update the draft, re-test. Do not save until the user says it's right.

  5. Save to ~/.claude/skills/[skill-name]/SKILL.md. Create the folder if needed. Confirm the path and that the slash command will be available after restart.

Rules

  • Keep SKILL.md files short. 30-50 lines is usually enough for the first version. More structure comes from use, not upfront design.
  • One skill = one job. If the user describes 3 jobs, push back and suggest splitting into 3 skills.
  • Description field is what loads into context every session - make it specific enough that Claude knows when to trigger, short enough not to bloat context.
  • Never invent capabilities. If the user asks the skill to do something Claude cannot do in this environment (e.g. call an API that isn't configured), flag it and ask how to handle.
  • Rules with real consequences go in CAPS. "NEVER fabricate metrics" stands out; "never fabricate metrics" gets skimmed.
  • Default trigger: the skill name itself. Only add extra trigger phrases if the user has specific alternatives they say out loud.
  • After saving, remind the user to restart Claude Code so the new skill loads.

If the user is vague

If the user says "build me a skill for reports" without specifics, do not guess. Ask:

  • Which client or project?
  • What data sources?
  • What format (HTML, PDF, markdown, Slack message)?
  • Daily, weekly, monthly, or ad-hoc?

Better to ask 5 questions than save a skill that does the wrong thing.