Module 2 · section 10 · 1,035 words · ~5 min read

The generation skills

docDoc type

draftStatus

RequiredFact-check

neverLast verified

Two Skills ship with Module 2. They are generalised versions of two skills that already run in production on another product — the originals are hardcoded to one brand's voice rules and one database's source of truth. These read your brand's intake instead.

Skill	What it does	Reads
`script-from-intake`	Turns a completed intake + a chosen format into a real script	Your BV-01 intake, `../templates/`
`claim-guard`	Checks a draft against your own barred claims, off-limits words, and recorded experience	Your BV-01 intake, your experience block

Explain-on-first-use: a Skill is a folder containing a SKILL.md file — a set of standing instructions that gets loaded automatically when the work matches its description. You are not writing code. You are writing down how you want a job done, once, so you never explain it again. Module 5 covers building your own.

1Installing them

Copy both folders into .claude/skills/ in whatever folder you keep your work in:

Plain text11 lines

your-work-folder/
  .claude/
    skills/
      script-from-intake/
        SKILL.md
      claim-guard/
        SKILL.md
  clients/
    sable-kitchenware/
      intake.md            ← your completed BV-01
      experience.md        ← what you actually did with the product

That's the whole install. There is nothing to run.

2Making them yours

These are deliberately generic. Two customisation moves, in order of value:

1. Point them at your folder layout. Both skills look for an intake file and an experience file. If you keep yours somewhere else, edit the paths near the top of each SKILL.md. That's a one-line change and it's the only edit most people need.

2. Add your own standing rules. If you always work in a particular way — you never write hooks over seven words, you always shoot vertical, you refuse comparative claims regardless of what the brand allows — add them under ## Standing rules in script-from-intake/SKILL.md. Rules you write there apply to every client, on top of whatever each client's intake says.

Do not hardcode a specific client's guardrails into the skill. That's what the intake is for, and a skill with one client baked into it stops being reusable the moment you have two.

3The division of labour

script-from-intake writes. claim-guard checks. They are separate on purpose, and the separation matters:

A generator that also marks its own homework will pass itself. Every time.
You will want to run claim-guard on drafts the generator never touched — something you wrote by hand, something a client sent you, an old script being reused for a new campaign.
When a check fails, you want to know whether the generator ignored a rule or whether the rule was never in the intake. Two skills make that legible; one doesn't.

Run them in that order, every time. script-from-intake ends by telling you to.

4What they will refuse to do

Both skills stop rather than guess. Specifically:

script-from-intake will not invent your experience. If your experience file is empty or thin, it asks rather than filling the gap with plausible detail. This is the single most important behaviour in either skill and it is not configurable.
claim-guard will not clear a draft it could not fully check. If the intake has no barred-claims list, it says the draft is unchecked rather than clean. Those are different findings and it will not blur them.

If either behaviour feels obstructive, that's the feature. Both come directly from Module 4's standard, and both exist because the alternative is a script that reads beautifully and says something your client is contractually barred from saying.

When it refuses: fill the gap, never delete the constraint

This is the failure mode you are most likely to hit, and it will not feel like a failure at the time. It will feel like being sensible.

The skill stops. You are on a deadline. The constraint that stopped it is sitting right there in a file you control — a line in the intake, a rule in the brief, a NOT RECORDED block. Deleting it takes four seconds and the skill runs immediately afterwards. Nothing warns you. The output looks fine.

It ran because you removed the thing that was checking it.

What to do instead, by refusal type:

It refused because	The fix
The experience file is empty or thin	Spend thirty seconds filling it. Before / what changed / what's still not great. That's it
You want an unboxing of something you've owned for weeks	Either you have day-0 notes or you don't. If you don't, the format is unavailable — offer first-impressions instead. This is a conversation with the brand, not an edit to a file
A claim isn't in the experience file	Get the line, or cut the claim. Both are fine. Retro-fitting the file to justify a line you already wrote is not — see demo run 01, where exactly that was declined
A barred claim is blocking the best hook	The client barred it. Write a different hook

Demo run 03 is the whole lesson in one example: that unboxing was nearly refused, and the only reason it wasn't is that the creator had written five lines down on the day the box arrived. Not because they were disciplined — because it took thirty seconds. The alternative was not "unbox it anyway from memory". The alternative was not having that format available, which is a real cost and still the correct outcome.

The general rule: if you are editing a guardrail file in order to make a generation succeed, stop. That is the one edit that is always wrong. Guardrail files get edited when the client's rules change or when something new actually happened — never when a draft is inconvenient.

5Demo run

demo-runs/ contains four complete runs against a labelled demo brand — intake in, prompt shown, output as generated, claim-guard report attached. The illustrations in ../templates/ are drawn from those runs.

Read demo-runs/README.md first: it is explicit about which parts of those runs are real and which are invented, because that distinction is the whole point of Module 4.

Your word for it — nothing is tracked automatically.

Source: content/module-2/skills/README.md