script-from-intake

---
name: script-from-intake
description: Use when drafting or redrafting a UGC script or hook set for a client you hold a completed brand-voice and guardrails intake for — testimonial, demo/review, unboxing or problem-solution.
---

# script-from-intake

## When this applies, in full

The description field is capped at 200 characters on the claude.ai upload path,
so the detail lives here instead.

**Use this skill when:**

- Writing a new script or hook set for a client with a completed BV-01 intake
- Adapting an existing script for a different format, or for a different client
- Reworking a script after client notes

**What it does that a general request doesn't:** it reads the client's intake as
the source of voice and guardrails rather than inferring tone from the brief, it
loads the matching format template for beat structure, and **it refuses to invent
creator experience that isn't on file.**

**It always hands off to `claim-guard` before anything ships.**


Every brand you write for has a different set of things it will not say. Most
creators hold those rules in their head, which works for one client and fails
silently at three — the failure being that you write a perfectly good line
containing a word this particular client banned four months ago in an email you
half remember.

This skill reads the rules instead of remembering them.

**The rule: the client's completed intake is the source of voice and guardrails,
not the brief, not the last script you wrote for them, and not your sense of how
they sound. If a constraint isn't in the intake, it isn't a constraint — and if
the intake is empty where it matters, stop and ask rather than filling the gap.**

## Where things live

Edit these paths if your folders differ. This is the only edit most people need.

| Input | Default location | Required? |
|---|---|---|
| Client intake (BV-01) | `clients/<client>/intake.md` | **Yes** — do not proceed without it |
| Creator experience | `clients/<client>/experience.md` | **Yes** for testimonial and demo/review |
| Format templates | `content/module-2/templates/` | Yes |
| Your standing rules | `## Standing rules` below | Optional |

## The intake fields this skill actually uses

Mapped to Form BV-01's sections. If a field is blank, that is information — see
"When the intake is thin".

| BV-01 field | How it's used |
|---|---|
| **BV-1** — brands to be mistaken for | Register calibration. Read as a target, never quoted or referenced in output |
| **BV-1** — brands never to sound like | The stronger signal of the two. If output drifts toward one of these, rewrite |
| **BV-1** — "at a party" | The most useful single field. Governs sentence length, whether the brand explains itself, whether it hedges |
| **BV-2** — who it's for | Goes into the brief verbatim as the audience line. Never summarise it into a demographic |
| **BV-2** — already believes | What the hook can assume without stating |
| **BV-2** — trying to change | What the piece has to earn. Usually the job of the proof or resolution beat |
| **BV-3** — barred claims | **Hard constraints.** No output may contain or imply these. Not stylistic |
| **BV-3** — off-limits words | Literal string bans, passed into the brief and re-checked after |
| **BV-3** — disclosure | Read but not written into the script body — see "Disclosure collisions" |
| **BV-4** — format / length / platform | Overrides the template's default duration. The client's number wins |
| **BV-4** — approval owner, revisions, turnaround | Reported alongside output, not used in generation |

## How to run it

**1. Read the intake first, in full, before reading the brief.**
Order matters. Reading the brief first anchors you to the brand's own marketing
language, which is exactly the register the intake usually exists to prevent.

**2. Identify the format, and check it's the right one.**
Each template opens with a *When it's the wrong format* section. Read it. If the
brief asks for a testimonial and the experience file shows the creator has had
the product two days, say so before writing — that conversation is cheaper now
than after the shoot.

**3. Load the template.** From `content/module-2/templates/`:

| Format | File |
|---|---|
| Testimonial | `01-testimonial.md` |
| Demo / review | `02-demo-review.md` |
| Unboxing | `03-unboxing.md` |
| Problem–solution | `04-problem-solution.md` |

Use the template's brief block as the structure. Fill every `[SQUARE BRACKET]`
from the intake and the experience file. **Do not fill one from inference.**

**4. Generate the hook set before the script.** Ten opening lines, per the
template's constraints. Then pick, then build the full beat structure around the
chosen line. Generating a finished script first and reverse-engineering a hook
out of it produces worse hooks — the script's momentum drags the opening toward
explanation.

**5. Check your own output before handing it on.** The template's *What to
reject* list, then a literal scan for every off-limits string. Then hand off to
`claim-guard` — see below.

**Scan the whole output, not just the spoken lines.** A script has at least four
text surfaces and a claim can sit in any of them:

| Surface | Example of what hides there |
|---|---|
| Spoken narration | The obvious one |
| **Bracketed stage directions** | `[no narration — about ninety seconds of cooking]` — a duration is a factual claim wherever it sits |
| On-screen text and captions | Conditions, figures, brand names |
| Beat/shot descriptions | *"identical shot"*, *"held three seconds"* — timings and equivalences |

This list exists because the generator's self-check leaked a timing claim through
a stage direction on a real run (demo run 02). Narration-only scanning is not
scanning.

**6. Report what you couldn't do.** Any field you left blank, any constraint you
couldn't satisfy, any collision between the intake and the template. Silence here
is the failure mode this skill exists to prevent.

## The refusal: never invent experience

Testimonial and demo/review both make claims about things the creator did. Those
claims come from the experience file and **nowhere else**.

If the experience file says *"eggs released, first try, cold pan"*, you may write
that. You may not write *"and it cleaned up in seconds"* because it is plausible,
adjacent, and would improve the script. It didn't happen as far as the file
knows, and the file is what you have.

**If the experience file is missing, empty, or contains only opinion** ("it's
great", "I like it"), stop. Ask for three things:

1. What was used before, and what was specifically wrong with it
2. The one concrete thing that changed — sensory, checkable, in a sentence
3. Anything that's still not great

That is a thirty-second conversation and it is the difference between a
testimonial and a fabrication. This behaviour is not configurable.

Unboxing has its own version of this rule: a first encounter can only be written
from a genuine first encounter. If the creator has been using the product for a
month, the format is unavailable, not adaptable.

## Disclosure collisions — expect one

> **This resolution is unverified practitioner judgment, not a researched
> convention.** The rule below is how *we* resolved a collision that turns up in
> three of the four templates. It has not been checked against any regulator's
> guidance, any platform's current policy, or any working creator's practice, and
> three templates now depend on it. It is tracked for legal review as **C6** in
> `../../_meta/fact-check.md`, alongside the open disclosure-norms item it is a
> specific application of. Treat it as a sensible default, not as a cleared one,
> and do not cite it to a client as though it were settled.

BV-4 frequently requires a spoken disclosure inside the first few seconds. Three
of the four templates have structural rules about what the opening does.
**These collide, routinely.**

When they do:

- **The client's contractual requirement wins.** Every time. It is not a style
  preference.
- **Disclosure is not the same as naming the product.** The testimonial rule
  "don't name the product in the opening line" is about not opening with an ad.
  A spoken partnership disclosure can sit ahead of the hook as its own beat
  without breaking that, and usually should.
- **Say the collision out loud in your output.** Don't resolve it silently. The
  creator needs to know the template was overridden and why, because the next
  client's rules will be different.
- **Never solve it by dropping the disclosure**, and never solve it by burying
  the disclosure in an on-screen caption when the intake asked for it spoken.

## When the intake is thin

A blank field is a finding, not a blocker — except where noted.

| Blank field | What to do |
|---|---|
| Off-limits words | Generate, but tell the creator the output is **unconstrained on vocabulary**, and that the AI-tell list in `01-prompting-for-hooks.md` is the fallback, not a substitute |
| Barred claims | **Do not ship.** Generate a draft if asked, and mark it plainly as un-clearable until BV-3 is filled. `claim-guard` will refuse to clear it too |
| Audience | Stop. Ask. This one field does more work than the rest combined, and inventing it produces the generic output the whole module is about avoiding |
| Disclosure | Generate, and flag that disclosure is unconfirmed. Note the date the intake was last confirmed — if it's more than a couple of months old, say so |
| Deliverable specifics | Use the template's default range and say you did |

## Standing rules

Add your own here. These apply to every client, on top of whatever each intake
says. Client rules win where they conflict; these fill gaps.

```
(none yet — add yours)
```

Examples of what belongs here: a maximum hook length you never exceed, a refusal
to write comparative claims regardless of client permission, a house preference
for present tense.

Examples of what does **not** belong here: anything specific to one client. That
goes in their intake.

## What NOT to do

- **Don't quote the "mistaken for" brands in output.** They calibrate register.
  A script that name-drops them is a script about other brands.
- **Don't soften a barred claim into an implication.** "Nothing sticks, ever" and
  "you'll never scrape again" are the same claim wearing different clothes if
  the intake bars permanence claims.
- **Don't treat the off-limits list as a synonym exercise.** If a client bans
  *game-changer*, reaching for *total shift* honours the letter and breaks the
  intent. The list exists because the register is wrong, not the word.
- **Don't generate one option.** Ten hooks, minimum. One output invites
  acceptance; ten invite judgement.
- **Don't rewrite the intake to fit the script.** If the intake makes the brief
  impossible, that's a conversation with the client, not an edit to their file.

## Before you hand anything over

1. Every `[SQUARE BRACKET]` filled from the intake or experience file — none from inference?
2. Ten hooks generated, one chosen, and you can say why?
3. Every claim in the script traceable to the experience file?
4. Literal scan run for every off-limits string, including inside compound words?
5. Any disclosure collision stated out loud rather than silently resolved?
6. Any blank intake field reported, with what you did about it?
7. **`claim-guard` run, and its report attached?** A script that hasn't been
   through it is a draft, not a deliverable.
8. Provenance line attached — what generated it, when, from which intake, and
   what a human changed afterwards.