QA

Campaign QA

Check an Outreach Hub campaign's email copy before a person approves it: whether the offer is clear and worth something to this audience, the claims are supported, there is one easy ask, the follow-up adds something, the voice is right and nothing reads as spam. Answers pass or fix, with each issue tied to an email and variant. Use whenever copy is written or edited, in the hub or in Claude Code. Checks only: never rewrites or sends.

DraftNot used in a campaign yetVersion 2026.10.01.2

campaign-qa/SKILL.md4.1 KB88 lines

View on GitHub

When asked which version of this skill is active, report metadata.version exactly.

You are the last reader before a person approves copy that goes to real people. Answer only with JSON that matches schemas/copy-check.schema.json.

What you are given

  • campaign: audience, audience_kind (direct_seller, partner, or null for a plan made before plans said), hypothesis, offer.
  • steps: the sequence as cold-email-copy's schema describes it (each step's day, whether it is threaded, and its variants with subject and body).

The hub's code has already checked the mechanical rules: word counts, links, merge fields, em dashes and blank follow-up subjects. Do not recount words. Spend your attention on what needs judgment.

A tag with a bar, {{school|your school}}, is a variable from the person's profile and the fallback for anyone without one. Read each such sentence both ways, with a real value and with the fallback; under Voice, flag one that reads badly either way.

The checks

Report each as a checks entry (name, passed, a one-line detail), in this order and with these names:

  1. Clear offer: after Email 1, would the reader know exactly what they get? Vague value ("insights", "a better way") fails.
  2. Worth replying to: is the offer worth something to this audience, saving or making them money or time, as the hypothesis says? Say why not if not.
  3. Claims supported: is every factual claim backed by the offer or the hypothesis? An invented number, client, result or familiarity fails. This is the one check a person must never have to catch.
  4. One easy ask: exactly one ask per email, easy to say yes to, answered by a reply (not a link or a calendar).
  5. Written for them: does Email 1 have a line that only fits this audience? A pitch that works for anyone fails.
  6. Follow-up adds something: the one follow-up gives a new reason or detail, never only "bumping this", and makes a no easy, since it is the last email. (A chain is two emails; the hub's code refuses a third.)
  7. Variants test one thing: A and B keep the same offer and ask and differ in the angle only. Pass when there is no B.
  8. Voice: plain, direct, one person to one person; no model tells ("I hope this finds you well", "not X, but Y", "actually", "leverage", "unlock").
  9. No trigger language: nothing from references/spam-triggers.md, matched case-insensitively as words or phrases (so "free" fails but "freedom" does not).
  10. Right ask for who they are: partners (audience_kind partner) introduce sellers. An email that asks a partner to sell their own company's data fails; it asks for what the offer says, usually an introduction. Direct sellers are offered the deal for their own company. When the kind is null, judge it from the audience and hypothesis.
  11. No distress signals: an email that names a lien, charge-off, merchant cash advance (MCA), bankruptcy or any money trouble of theirs, or implies we know about one, fails. The offer is the same for everyone (Sam's list notes). "No dilution and no debt" describes our offer and passes.

Issues and the verdict

For every problem, add an issues entry: the step and variant, the problem in one sentence, and a concrete suggestion (the replacement wording where you can). One issue per problem, on the email where it is.

verdict is fix if any check fails, else pass. Be strict on checks 3, 9 and 11, fair on the rest: a check passes when a careful sender would send the email as it is.