SkillSKILL.mdModule 2 · 1,729 words
claim-guard
Use before any UGC script, caption, hook or cut goes to a client or ships. Traces every claim to the client's barred-claims list, off-limits words, or the creator's recorded experience.
1When 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:
- A draft is finished and about to go to a client for approval
- Reviewing a script someone else wrote
- Reusing an old script for a new campaign
- Preparing anything that makes a claim about a product, states a result, or speaks in a brand's voice
Run it on hand-written drafts too, not only generated ones. They fail these checks at roughly the same rate, and the one you wrote yourself is the one you will read least carefully.
What it checks against: that client's own barred-claims list, their off-limits vocabulary, and the creator's recorded experience — not a general sense of what sounds safe.
A claim in a script is only as good as the last time it was checked against something outside the script. Not against your memory of the brief. Not against the version of this script you wrote for a different client. Against the file.
This is the general version of a check that exists on another product to catch stale numbers in marketing copy. Two incidents built that one, and both generalise almost exactly to UGC work.
The rule: every claim gets traced to a source before it ships — the client's barred list, the client's off-limits list, or the creator's own recorded experience. A claim with no source is not "probably fine," it is unsourced, and unsourced is a finding.
2The two incidents this generalises from
1. A number that was corrected everywhere except the one place that mattered. A count changed. The sweep updated the site, the press kit, the one-pagers — and missed one asset, which shipped stale and wasn't caught for four days. Worse, when it was found, the corrected file couldn't actually reach the platform it was published on until the next release cycle.
The UGC version: a client bans a claim mid-campaign. You update the script, the captions, and the pinned comment — and the claim is still spoken aloud in a cut that's already rendered, already approved, already scheduled. Lesson: fixing the script is not the same as fixing the deliverable. A check isn't finished until you have confirmed which artefacts already carry the claim and whether each can still be changed.
2. A build that deliberately failed rather than silently substituting. One campaign pulled its content from a live source and was written to fail loudly if the source moved, rather than quietly filling the gap.
The UGC version: if the experience file doesn't support a line, the correct behaviour is to stop and say so, not to soften the line until it's defensible. Lesson: make the gap loud. A hedged version of an unsupported claim is still an unsupported claim, and it's harder to spot on the second read.
3What to check, and against what
| Check | Source of truth | Never trust |
|---|---|---|
| Barred claims | BV-3 barred-claims list in the client's intake | The brief. Briefs describe what the brand wants said; the intake records what it may not say. These are different documents and only one is a constraint |
| Off-limits vocabulary | BV-3 off-limits list, matched literally | Your ear. The list exists precisely because the words sound fine |
| Experience claims | The creator's experience file | The script's own internal consistency. A script can be perfectly coherent and entirely unsupported |
| Comparative claims | BV-3 barred list, plus the client's contract if you have it | The absence of a rule. If comparison isn't addressed in the intake, it's unconfirmed, not permitted |
| Disclosure presence | BV-4 disclosure field and its confirmation date | A confirmation older than the current campaign. Requirements move; a date is part of the fact |
4Scan scope — define this before you start
Every pass below runs against all of the following, not just the spoken line. A claim is a claim wherever it is written down, and the surfaces that get skipped are the ones that don't look like dialogue.
| In scope | Why it matters |
|---|---|
| Spoken narration | The obvious one |
| Bracketed stage directions | [about ninety seconds of cooking] is a duration claim. It was missed once on a real run for exactly this reason — see demo run 02 |
| Beat and shot descriptions | "identical shot", "held three seconds", "next morning" — these assert timings, equivalences and sequences |
| On-screen text and captions | Conditions, figures, brand names, disclosure supers |
| Cover frame / thumbnail text | Frequently written last, checked never |
| Pinned comment and post caption | Read by clients; often carries the claim the script avoided |
| File and asset names | pan-90sec-final.mp4 has survived into a client folder before now |
If a surface doesn't exist yet — the caption isn't written, the cover frame
isn't chosen — say so. That is UNCHECKED for that surface, not clean.
5The check, run in this order
Order is deliberate — the cheap literal checks come first so a draft that fails them doesn't consume judgement.
1. Literal vocabulary scan. Every off-limits string, case-insensitive, including inside compound and hyphenated words, across every surface in the scope table above. Report each hit with the line it appears in and which surface it was on. Do not paraphrase the hit — quote it.
2. Barred-claim scan, literal then semantic. First the exact phrases. Then the harder pass: does any line assert or imply a barred claim in different words? A ban on permanence claims is broken by "you'll never scrape again" just as surely as by the banned phrase itself. State which pass caught each hit.
3. Claim-to-experience trace. List every factual claim the script makes about the product or the creator's use of it, from every surface in the scope table. Against each, write the line from the experience file that supports it. Any claim with no supporting line is a finding, and the finding is unsupported, not wrong — you don't know it's wrong, you know it isn't sourced.
Numbers deserve their own sweep. Durations, counts, temperatures, prices and frequencies are claims even when they read as production notes, and they are the category most likely to be sitting in a bracket rather than in a sentence.
4. Derived-claim check. A claim built out of two other claims needs both checked. "It's the only pan I use now" contains a frequency claim and an exclusivity claim. "Twice as fast" needs both the new figure and the baseline.
5. Disclosure check. Is the disclosure the intake requires actually present, in the form it requires — spoken if spoken was asked for, visible if visible? Then check the confirmation date on the intake field. If it's stale, the disclosure is unverified even when it's present.
6. Sibling check. Per incident 1: if this script came from a template, an older script, or a batch, the same claim is probably in the others. Name the likely siblings. Say whether you checked them or only flagged them.
6Reporting
Report findings in three buckets. Do not merge them — they carry different consequences and a merged list gets triaged as one thing.
| Bucket | Meaning | What happens next |
|---|---|---|
| BLOCKED | Barred claim, present or implied. Or a required disclosure absent | Does not go to the client. Fix, re-run |
| UNSUPPORTED | A claim with no line in the experience file behind it | Either get the line, or cut the claim. Creator's call, but not silently |
| FLAGGED | Off-limits vocabulary, stale disclosure date, unconfirmed comparative | Fix or accept explicitly. Accepting is allowed; accepting without noticing is not |
For each finding give: the exact line, which check caught it, and which source it failed against. "This feels risky" is not a finding.
7When you can't fully check
Do not report a draft as clean when you couldn't check it. Those are different outcomes and the difference is the whole point of this skill.
- No barred-claims list in the intake → report
UNCHECKED — no barred-claims list on file. Not "no issues found." - No experience file → every product claim in the script is UNSUPPORTED by definition. Say that plainly; don't wave it through because the claims sound reasonable.
- Disclosure confirmation date missing or old → FLAGGED, with the date if there is one.
An honest "I could check three of five things, here are the two I couldn't" is a useful report. A clean bill of health that quietly skipped the checks it lacked inputs for is worse than no check at all, because it will be trusted.
8What NOT to do
- Don't fix and move on silently. State what the draft claimed and what the source says. The creator needs to learn the pattern, not receive a laundered script.
- Don't treat a rewrite as a resolution. Softening an unsupported claim until it's vague makes it harder to catch next time. Cut it or source it.
- Don't check only the spoken line. See the scope table. Captions, stage directions, on-screen text, the pinned comment and the cover frame all carry claims, and clients read all of them.
- Don't assume a rule that isn't written down. If the intake doesn't bar comparison, don't report comparison as BLOCKED. Report it FLAGGED and unconfirmed, and tell the creator to ask.
- Don't run this only on generated drafts. Hand-written scripts fail these checks at roughly the same rate. The one you wrote yourself is the one you'll read least carefully.
9Closing the loop
A check is finished when you can answer all five:
- Which claims did you trace, and to what?
- Which could you not trace, and why?
- Which artefacts other than this script carry the same claims?
- Of those, which can still be changed and which have already shipped?
- What is the report's bucket breakdown — BLOCKED / UNSUPPORTED / FLAGGED?
If question 4 has an "already shipped" in it, say so in the first line of the report, not the last.
.claude/skills/claim-guard/SKILL.md194 lines · 10.1 KB--- name: claim-guard description: Use before any UGC script, caption, hook or cut goes to a client or ships. Traces every claim to the client's barred-claims list, off-limits words, or the creator's recorded experience. --- # claim-guard ## 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:** - A draft is finished and about to go to a client for approval - Reviewing a script someone else wrote - Reusing an old script for a new campaign - Preparing anything that makes a claim about a product, states a result, or speaks in a brand's voice **Run it on hand-written drafts too, not only generated ones.** They fail these checks at roughly the same rate, and the one you wrote yourself is the one you will read least carefully. **What it checks against:** that client's own barred-claims list, their off-limits vocabulary, and the creator's recorded experience — not a general sense of what sounds safe. A claim in a script is only as good as the last time it was checked against something outside the script. Not against your memory of the brief. Not against the version of this script you wrote for a different client. Against the file. This is the general version of a check that exists on another product to catch stale numbers in marketing copy. Two incidents built that one, and both generalise almost exactly to UGC work. **The rule: every claim gets traced to a source before it ships — the client's barred list, the client's off-limits list, or the creator's own recorded experience. A claim with no source is not "probably fine," it is unsourced, and unsourced is a finding.** ## The two incidents this generalises from **1. A number that was corrected everywhere except the one place that mattered.** A count changed. The sweep updated the site, the press kit, the one-pagers — and missed one asset, which shipped stale and wasn't caught for four days. Worse, when it was found, the corrected file couldn't actually reach the platform it was published on until the next release cycle. *The UGC version:* a client bans a claim mid-campaign. You update the script, the captions, and the pinned comment — and the claim is still spoken aloud in a cut that's already rendered, already approved, already scheduled. **Lesson: fixing the script is not the same as fixing the deliverable.** A check isn't finished until you have confirmed which artefacts already carry the claim and whether each can still be changed. **2. A build that deliberately failed rather than silently substituting.** One campaign pulled its content from a live source and was written to fail loudly if the source moved, rather than quietly filling the gap. *The UGC version:* if the experience file doesn't support a line, the correct behaviour is to stop and say so, not to soften the line until it's defensible. **Lesson: make the gap loud.** A hedged version of an unsupported claim is still an unsupported claim, and it's harder to spot on the second read. ## What to check, and against what | Check | Source of truth | Never trust | |---|---|---| | **Barred claims** | BV-3 barred-claims list in the client's intake | The brief. Briefs describe what the brand wants said; the intake records what it may not say. These are different documents and only one is a constraint | | **Off-limits vocabulary** | BV-3 off-limits list, matched literally | Your ear. The list exists precisely because the words sound fine | | **Experience claims** | The creator's experience file | The script's own internal consistency. A script can be perfectly coherent and entirely unsupported | | **Comparative claims** | BV-3 barred list, plus the client's contract if you have it | The absence of a rule. If comparison isn't addressed in the intake, it's unconfirmed, not permitted | | **Disclosure presence** | BV-4 disclosure field **and its confirmation date** | A confirmation older than the current campaign. Requirements move; a date is part of the fact | ## Scan scope — define this before you start Every pass below runs against **all** of the following, not just the spoken line. A claim is a claim wherever it is written down, and the surfaces that get skipped are the ones that don't look like dialogue. | In scope | Why it matters | |---|---| | Spoken narration | The obvious one | | **Bracketed stage directions** | `[about ninety seconds of cooking]` is a duration claim. It was missed once on a real run for exactly this reason — see demo run 02 | | Beat and shot descriptions | *"identical shot"*, *"held three seconds"*, *"next morning"* — these assert timings, equivalences and sequences | | On-screen text and captions | Conditions, figures, brand names, disclosure supers | | Cover frame / thumbnail text | Frequently written last, checked never | | Pinned comment and post caption | Read by clients; often carries the claim the script avoided | | File and asset names | `pan-90sec-final.mp4` has survived into a client folder before now | **If a surface doesn't exist yet** — the caption isn't written, the cover frame isn't chosen — say so. That is `UNCHECKED` for that surface, not clean. ## The check, run in this order Order is deliberate — the cheap literal checks come first so a draft that fails them doesn't consume judgement. **1. Literal vocabulary scan.** Every off-limits string, case-insensitive, including inside compound and hyphenated words, **across every surface in the scope table above.** Report each hit with the line it appears in and which surface it was on. Do not paraphrase the hit — quote it. **2. Barred-claim scan, literal then semantic.** First the exact phrases. Then the harder pass: does any line *assert or imply* a barred claim in different words? A ban on permanence claims is broken by "you'll never scrape again" just as surely as by the banned phrase itself. State which pass caught each hit. **3. Claim-to-experience trace.** List every factual claim the script makes about the product or the creator's use of it, **from every surface in the scope table**. Against each, write the line from the experience file that supports it. Any claim with no supporting line is a **finding**, and the finding is *unsupported*, not *wrong* — you don't know it's wrong, you know it isn't sourced. Numbers deserve their own sweep. Durations, counts, temperatures, prices and frequencies are claims even when they read as production notes, and they are the category most likely to be sitting in a bracket rather than in a sentence. **4. Derived-claim check.** A claim built out of two other claims needs both checked. "It's the only pan I use now" contains a frequency claim and an exclusivity claim. "Twice as fast" needs both the new figure and the baseline. **5. Disclosure check.** Is the disclosure the intake requires actually present, in the form it requires — spoken if spoken was asked for, visible if visible? Then check the confirmation date on the intake field. If it's stale, the disclosure is unverified even when it's present. **6. Sibling check.** Per incident 1: if this script came from a template, an older script, or a batch, the same claim is probably in the others. Name the likely siblings. Say whether you checked them or only flagged them. ## Reporting Report findings in three buckets. Do not merge them — they carry different consequences and a merged list gets triaged as one thing. | Bucket | Meaning | What happens next | |---|---|---| | **BLOCKED** | Barred claim, present or implied. Or a required disclosure absent | Does not go to the client. Fix, re-run | | **UNSUPPORTED** | A claim with no line in the experience file behind it | Either get the line, or cut the claim. Creator's call, but not silently | | **FLAGGED** | Off-limits vocabulary, stale disclosure date, unconfirmed comparative | Fix or accept explicitly. Accepting is allowed; accepting without noticing is not | For each finding give: the exact line, which check caught it, and which source it failed against. "This feels risky" is not a finding. ## When you can't fully check **Do not report a draft as clean when you couldn't check it.** Those are different outcomes and the difference is the whole point of this skill. - **No barred-claims list in the intake** → report `UNCHECKED — no barred-claims list on file`. Not "no issues found." - **No experience file** → every product claim in the script is UNSUPPORTED by definition. Say that plainly; don't wave it through because the claims sound reasonable. - **Disclosure confirmation date missing or old** → FLAGGED, with the date if there is one. An honest "I could check three of five things, here are the two I couldn't" is a useful report. A clean bill of health that quietly skipped the checks it lacked inputs for is worse than no check at all, because it will be trusted. ## What NOT to do - **Don't fix and move on silently.** State what the draft claimed and what the source says. The creator needs to learn the pattern, not receive a laundered script. - **Don't treat a rewrite as a resolution.** Softening an unsupported claim until it's vague makes it harder to catch next time. Cut it or source it. - **Don't check only the spoken line.** See the scope table. Captions, stage directions, on-screen text, the pinned comment and the cover frame all carry claims, and clients read all of them. - **Don't assume a rule that isn't written down.** If the intake doesn't bar comparison, don't report comparison as BLOCKED. Report it FLAGGED and unconfirmed, and tell the creator to ask. - **Don't run this only on generated drafts.** Hand-written scripts fail these checks at roughly the same rate. The one you wrote yourself is the one you'll read least carefully. ## Closing the loop A check is finished when you can answer all five: 1. Which claims did you trace, and to what? 2. Which could you not trace, and why? 3. Which artefacts other than this script carry the same claims? 4. Of those, which can still be changed and which have already shipped? 5. What is the report's bucket breakdown — BLOCKED / UNSUPPORTED / FLAGGED? If question 4 has an "already shipped" in it, say so in the first line of the report, not the last.
Source: content/module-2/skills/claim-guard/SKILL.md