Building a Skill for something you actually repeat

You are not being taught to be a developer. You are being taught to notice when a thing you do repeatedly is worth writing down, and then to write it down in a format something else can read.

1The recognition test

Run this against last week. Three questions, in order.

1. Did I paste the same instructions into a chat more than twice? That's the whole signal. Not "was it complicated" — did it repeat.

2. Would I be annoyed if someone else did it differently? If yes, you have a standard, and a standard is a skill waiting to be written. If you genuinely don't mind how it's done, don't write one.

3. Can I describe it without describing this particular client? If the procedure only makes sense for one brand, it isn't a skill — it's an intake, and Module 3 already has a place for it.

Three yeses means build one. Two means wait until it happens again.

What this looks like for a UGC creator

Real candidates, in rough order of how often they come up:

• A pre-delivery checklist. Captions read, brand names spelled right, aspect ratio, disclosure present, filename convention.
• How you write a quote. Module 0A's rate calculator as a procedure rather than a document you reopen.
• Your own house rules on top of a client's. Hook length you never exceed, formats you don't shoot, claims you won't make regardless of permission.
• How you onboard a new client. The six scoping questions, the BV-01, the Project setup, in the order you do them.
• A format template you've adapted twice for the same client. Module 2's template README says it directly: once a template has been adapted for a client twice, it has become that client's template.

2The shape of the file

Minimum viable skill — a folder, a file, and frontmatter:

---
name: pre-delivery-check
description: Use before sending any finished video to a client. Checks
  captions, brand names, aspect ratio, disclosure and filename.
---

# pre-delivery-check

Run every item. Report anything that fails; do not fix silently.

1. Read every caption aloud. Brand names and numbers are where machine
   captions fail — check those twice.
2. Confirm aspect ratio and length against BV-4 in the client's intake.
3. Confirm the disclosure the client requires is present, in the form
   they asked for.
4. Filename follows: client-format-version.
5. Confirm claim-guard has run and its report is filed.

If any item fails, say which and stop. Do not send.

That is a complete, useful skill. Nothing is missing.

The frontmatter, and the cap that catches people

name — on the claude.ai upload path this is required and capped at 64 characters. In Claude Code it's optional and defaults to the folder name.

description — this is the important one, because Claude reads it to decide when to apply the skill. On the claude.ai path it is capped at 200 characters.

Everything else is optional. You do not need it to start.

3Learn the pattern from a real one

The two Skills that came with Module 2 are worth opening, not as templates to copy wholesale but because the pattern in them is deliberate. Both were generalised from skills running on a real product.

1. They open with why they exist, grounded in a real failure. claim-guard opens with two actual incidents — a number corrected everywhere except the one place that mattered, and a build that failed loudly rather than substituting silently. Not because the story is charming, but because a rule whose origin you understand is a rule you apply correctly in a case it didn't anticipate.

2. One bolded rule, near the top. Both have a single sentence that everything else elaborates. "The client's completed intake is the source of voice and guardrails, not the brief." If you can't write that sentence for your skill, the skill isn't clear yet.

3. A source-of-truth table with a "Never trust" column. This is the highest- value structure in either file. Saying what not to rely on is more useful than saying what to rely on, because the wrong source is usually the convenient one.

4. An explicit "What NOT to do." Every failure mode you've already hit, written down. This is where most of the value accumulates over time — you add a line each time something goes wrong.

5. A closing checklist. Numbered, concrete, answerable yes or no. It's what you'd actually run.

And one honest note about those two files

The documentation advises keeping a skill's body concise, because once a skill loads its content stays in context and every line is a recurring cost.

Module 2's two Skills are long — well over a thousand words each. That's a deliberate trade for teaching material, since they're doing double duty as worked examples. Yours should start much shorter. The checklist above is about 120 words and it's a real skill.

Write the short version. Add to it only when something goes wrong that the file didn't cover.

4Getting help writing one

You do not have to write it cold, and this is the obvious place to use the thing this guide is about:

Help me turn a repeated workflow into a Skill.

THE WORKFLOW — what I currently do by hand
  [DESCRIBE IT AS STEPS, IN THE ORDER YOU DO THEM]

WHEN I DO IT
  [THE TRIGGER — "before sending anything to a client"]

WHAT I WANT IT TO REFUSE TO DO
  [ANYTHING IT SHOULD STOP AT RATHER THAN GUESS]

WHAT GOES WRONG WHEN I DO THIS BADLY
  [REAL FAILURES YOU'VE HAD — these become the "what not to do"]

Write a SKILL.md. Constraints:
  - description under 200 characters, phrased as WHEN to use it
  - body under 300 words for a first version
  - include a "what not to do" section built from my failures above
  - end with a numbered checklist I could actually run
  - plain instructions, no narration about why

Then tell me what you left out and why.

"Then tell me what you left out" is the line that earns its place — a first skill is almost always missing the case you didn't think to mention.

5Installing and testing it

On claude.ai: put SKILL.md in a folder named for the skill, zip the folder, upload at Customize → Skills, enable it.

In Claude Code: save it to ~/.claude/skills/<name>/SKILL.md for all your work, or .claude/skills/<name>/SKILL.md for one project. Edits are picked up without restarting.

Then test it, and test it the way it'll actually be used:

1. Invoke it directly — type / and its name. Does it do the thing?
2. Then don't. Start a chat that should trigger it and see whether it fires on its own. If it doesn't, the problem is almost always the description, not the body.
3. Run it on a case it wasn't written for. This is where you find out whether you wrote a procedure or a script.

6Maintaining it

The part nobody mentions. A skill is a living file, same as the intake and the tool landscape.

• Add a line every time something goes wrong that the skill didn't catch. That's how the "what not to do" section gets good, and it's why the real ones read like they were written by someone who'd been burned.
• Delete lines you never use. Every line is a recurring cost.
• Re-read it when a client complains. The complaint is usually about something the file doesn't say.
• Don't fold a client into it. When a rule turns out to be one brand's rather than yours, move it to their BV-01.

7Next

Module 5.5 hands you a Skill someone else wrote: the portfolio builder. Six questions in, a finished website out.

You now know what that is — a folder, a text file, a description that tells Claude when to fire, and instructions someone wrote down once. It's the same thing you just built, aimed at a different job.