gooseworks-ai/goose-skills

# <Title>

<One paragraph: what the skill makes or decides, and when to use it.>

## Inputs

- <What the agent needs first, and where it comes from.>

## Steps

1. <The first step, in plain words.>
2. <The next step.>

## Done when

# learn-my-brand

The front door. GooseWorks' server researches the brand and stores the kit; this playbook does what only the owner can: confirm what is true, decide what may be claimed, say how the brand sounds, and record what nobody knows yet. Every other playbook reads what it saves, through `../../../skills/marketing/claims-gate/SKILL.md` and `../../../skills/marketing/voice-card/SKILL.md`.

Talk to the owner about their brand, never about tools, ids, fields or other playbooks.

## What you get

- **A signed-off claims list:** each claim the brand may make, verbatim, with proof, scope (products, markets, channels), qualifier, review date and approver; every candidate not approved, with why, what would unlock it and a safe alternative; the never-say list tagged law / platform / owner.
- **A confirmed voice:** personality is/is-not, 3–5 rules with real do/don't pairs, banned words, terminology, how it flexes by channel and speaker.
- **Confirmed basics:** what we sell and the hero offer, who it is for, company type and stage, who approves, what buyers use instead, anything not to say in public.
- **An unknowns ledger:** each gap, what it blocks, the assumption in use, and when it will be asked.
- **All of it saved as it is confirmed**, plus a one-screen read-back the owner checks.

# make-product-photos

The engine composes, generates, judges and retries. This playbook is the e-commerce creative director around it: it decides which pictures the page needs, curates which real photos the engine sees, turns each shot into a precise prompt, holds every scene to what the product physically is, checks each output against the real product, and keeps the catalogue looking like one shoot.

## What you get

- A **shot list** from the surface (store page, ads, social, email, launch page), each shot with its slot, composition, light, scene and ratio — agreed before anything is made.
- A **house-style card** derived from the brand's existing photos (when they can be seen), confirmed once and saved.
- The **photo set** as the page it fills: each photo with its use, the engine's status and score, this playbook's verdict (keep / maybe / reject + named reason), and who checked it (by eye, or engine only with a checklist for you).
- "What we could not make and why", and the credits actually charged.

## Before you start

**Hard rules:**

# make-video-ads

The video engine plans, prices, renders and checks files. This playbook is the creative director and scriptwriter around it: one researched angle, a hook in the buyer's words, every word and picture held to the signed-off claims, no generated person speaking as a customer, the human shown exactly what they pay for, and an honest review of the result.

## What you get

- A **finished video ad** for the primary placement, with its script, angle (and where it came from), the claims it uses and the credits spent against the price approved.
- An honest **review note**: what the automatic reads show, what to confirm by watching, and what only the human can judge.
- **Launch copy and launch notes** in `ads/videos/<project_id>.md` — one file per video — for run-paid-campaigns (the chosen, script-checked post copy; AI label to switch on; music to add in-platform; sibling hook variants).
- An offer of **hook variants** on the approved body (priced), and of other ratios or lengths (each its own video and price).

## Before you start

**Hard rules:**

# GooseWorks ads

Use this entry for existing-ad operations and analysis. For new image ads, more ads, a winner's
variations, copy/font changes, a rejected ad fix or a requested social graphic, fetch
make-static-ads with catalog_fetch (or use the installed current package) and follow its
research, selection, claims and quote gates. If it cannot be fetched, report that creation
is unavailable on this connection and stop. The server generator is a different workflow,
not a fallback for the missing playbook.

- Save lasting human brand facts with the connection's listed knowledge action in their words.
- A batch on its way: job_get. Finished ads: ads_creative_read.
- One finished ad: an animation with ads_creative_animate (price it first, free, with
  ads_creative_animation_quote), its tags or rating with ads_creative_update. A new size with
  ads_creative_resize only when the customer asks: it spends credits and has no free price

# GooseWorks product photos

Use GooseWorks to photograph the customer's physical products, here in this chat. A software
screen or an app is not a product photo.

- A fact the customer states about the brand (a price, a rule, their audience): save it with
  brand_knowledge_save in their words, never in your own notes, and confirm in one line.
- Offer the brand's real products from brand_read; never describe one you can't see. A product
  that isn't listed yet: brand_update adds it from its page. A photo the customer sends:
  media_upload.
- photos_generate makes the photos: get its price first from the same call as a dry run (free,
  it makes nothing), tell the customer the credit total, and make them only after their yes.
  Show a person only when the customer asks for one and confirms they have the rights.
- Follow the photos with photos_read until they are ready.

# GooseWorks video

Installed entry: catalog_fetch type skill goose-video on this connection and follow it. Already fetched this run: no repeat.

For a video already started, call video_read and follow its next_step.

New videos default to a real reference ad remade for the brand (custom); ready-made styles are the fallback. Start with get_started (wants video, request). Cards prove no pick or viewing.

1. The request. If they haven't said what the video is about, ask in one short question.
2. The brand. Ask which brand only when brand_read lists several; with one, use it.
3. The product. Before reference or style choices, ask which product or service to advertise, even with only one saved. Use the product card, or ask by name in chat, and wait. Only their stated choice settles it; a brand name does not. Reuse an explicit pick or request for none; find ids with brand_read, [] for none.
4. Research. Read the kit, learnings and selected products with brand_read, then knowledge_search. Verify product size and use from facts and size-reference photos before planning. Note what to say and avoid.
5. The reference. Their own video ad: video_create with style custom, request, products, its reference_url and a new UUID idempotency_key, then the custom rule. Otherwise, custom asked or not, video_references (action find) with the request and products ([] for none); free, and it reuses the saved list unless they want new ideas (fresh: true). Show it as the answer says; they pick.
6. The pick. video_references (action pick) with candidate_id, request, products and a new UUID idempotency_key starts the custom video. Then the custom rule.

When an answer's next_step gives a command to make a video, its last line says who starts it and how: follow that line exactly, with the command exactly as given.

# GooseWorks

Route specialist jobs to their skills; use GooseWorks for web and social data.

## First steps

1. Discover the listed setup/status action and read brand/task state. Complete missing facts;
   preserve the selected brand/task and continue once setup is done.
2. Read brand_read and advertised knowledge actions for rules/evidence; pass results to the
   playbook. Use legacy action names only when listed; ask only what remains ambiguous.
3. Save lasting human brand facts in their words through the listed typed knowledge action.
   Keep guesses and temporary creative choices as proposals; follow claim, rights and approval
   rules. Generic context is not approved product proof.

# Human version

The owner approves script, then ingredients and budget here; cards and Studio are optional. Keep reference format, product and sound. GooseWorks checks the final.

---

# Agent version

## Non-negotiables

1. Watch every reference end to end with sound, or use the server's measured reference profile, and save the evidence before any script.
2. Write the script with write-video-ad-script (catalog_fetch it).
3. Keep the reference's format: people stay people, demos stay demos, sound type stays. Otherwise list the change in changes_from_reference.
4. The voice is the master clock. Never cut or retime sound apart from a talking face.

# ad-policy-check

Used by: make-static-ads (paid ads) and run-paid-campaigns (creative it checks at launch). Organic, email and creator content: load `disclosure.md` instead (or as well, when a paid ad uses a creator).

Craft knowledge, not legal advice. Policies change: when a rule decides whether an ad ships, tell the human to confirm it on the platform's live policy page. Claims are a separate check (the `claims-gate` skill, `../claims-gate/SKILL.md`); run that first — a line cut there is not reworded here.

**Reads:** the ad's planned or rendered text (copy, on-image or on-screen words, end cards, captions), what the picture shows, the people in it, the platforms and placements from the brief, the brand's category, and the brand's `dont` / `must` learnings (past disapprovals).
**Writes:** one policy line per ad and platform, and any set-level flag.

## 1. Category first

Regulated (health, supplements, food with health, nutrition or free-from claims, cosmetics with efficacy language, alcohol, cannabis/CBD, tobacco/vape, financial products, crypto, weight loss, kids' products, regulated professions, gambling, dating, political) or a special ad category on Meta (housing, employment, credit, social issues)?

- No brand rule on file for it → flag the whole set "needs legal review before launch".

# analyze-performance

## What you get

- **The Monday report** — saved to `reports/performance/<YYYY-MM-DD>.md` and shown in chat, the same shape every week (`references/monday-report.md`); run-paid-campaigns decides and acts on its recommendations.
- **Learnings** written to the brand brain after the marketer has seen and kept them; ended tests' measured results saved as readouts.
- **A run record** for next week (`references/run-memory.md`): the per-channel and per-ad scorecards with the trend since last run, each call with its owner, review date and test, and what happened to last week's calls — saved to the brand, so "what worked" and "what to make next" rest on weeks of history, not one week.
- **Monthly unit-economics read** for plan-campaign's replan; **daily pulse** on request, exception-only (`references/monthly-and-pulse.md`).

## Before you start

1. **Setup first:** do the `marketing-guide` skill (`../marketing-guide/SKILL.md`) §1–2 (connect, brand, brain read) before anything else; the job line is "read your results". This playbook offers **local mode** (marketing-guide §5): with no GooseWorks it reads through the marketer's connectors, else exports and screenshots, and keeps the contract, reports and run records in the local folder. A missing connection is never a blocker: say in one line what this read can and can't see, and go on.
2. **Read the brain and the plan** (free; local mode: `references/local-mode.md` instead). Brain chapters: 18 "How we count results", 20 "Our plan" (targets, decisions, experiments), 22 "Everything we have made and run", 23 "What is working" (readouts, worn-out angles, lessons). Fallback path: `brand_read` sections `summary, kit, products, learnings, onboarding, accounts`, and `knowledge_search` `["learning"]` for past results. Then `gooseworks:campaign_read` — live briefs (Economics, targets, Test plan, Measurement plan, Replan triggers, the change-log slug in Status); workspace (`gooseworks:file_list` / `file_read`): `reports/performance/definitions.md`, the latest dated report and its Decisions, `ads/campaigns/<slug>/state.md` (frontmatter `meta_push_ids`, health line, open recommendations) and the `### YYYY-MM-DD — <title>` blocks of `decisions.md` (what was actually done — written by run-paid-campaigns and the server), make-static-ads' batch files `ads/batches/<YYYY-MM-DD>-<slug>.md` (creative id → angle, hook, test; picks), `lifecycle/program.md` (which flows exist), the newest `research/competitors/watch/<YYYY-MM-DD>.md` (line 2), and research-market's "What people are saying" section — in the newest `research/market/<D>-read.md` (mentions, sentiment, trends, risks; check the section's own window line before treating it as this week's, and read share of voice only if it is there).
3. **Load the last runs** — the Start steps of the `run-memory` skill (`../run-memory/SKILL.md`) for this job (`weekly performance read`, `monthly read` or `daily pulse`; `references/run-memory.md`): the last record, plus up to four weekly records back for the scorecards and angle history; every earlier call checked against a source; run-paid-campaigns' newest run record for each campaign (its money moves and verdicts). No record → say it's the first read; this run's numbers become the baseline.

# Test calls, calls and learnings (atom)

**Load:** `../analyze-performance/references/tests-and-learnings.md`.

**Inputs:** the brief's test plan; this week's results; last week's report (its calls); the change log (what was actually done); the learnings and readouts (`brand_knowledge_browse` kind 23 / `brand_knowledge_search` where listed; else `knowledge_search source_types: ["learning"]`, `brand_read` learnings); the paid run's newest run record.

**Do:**
1. Call each ended test Win / Loss / Unclear against its written criteria with the brief's action; state how sure (confirmed / likely / first look).
2. Score last week's recommendations through run-memory's outcome check (`../analyze-performance/references/run-memory.md`): what was actually done (the `### YYYY-MM-DD — <title>` blocks in `decisions.md`, run-paid-campaigns' run record), and what happened — for a money move, the paid run's verdict plus the store-joined check over the same window; right or wrong.
3. Write this week's calls (kill / scale / hold, Google negatives) with object, why, how sure and "would change if"; first look → "watch".
4. Check fired replan triggers against the brief's thresholds.
5. Draft ≤ 3 learnings as one-line rules (template in the reference); only ended tests, 2+ week patterns that clear the test n floors on the referee-joined number, confirmed surprises or failures; each shows what it would retire.
6. Readouts: each Win / Loss → kind 23 `experiment_readout.<campaign-slug>-t<n>` through save-learning's readout path, only with the marketer present; scheduled runs mark it `readout to save`.
7. After the marketer's reply to the decisions block: write the kept learnings through the `save-learning` skill (`../save-learning/SKILL.md`) — one idea per learning, `[learning YYYY-MM-DD]` (+ ` A-NN`), their exact words as the statement, own superseded facts retired in the same call; read back, compare, report which landed. Without their words, write nothing.

# Plumbing and the why (atom)

**Load:** `../analyze-performance/references/diagnosis.md`.

**Inputs:** the clean dataset; the overclaim ratio and its trend; the change log (`decisions.md`); push failures/disapprovals reported by run-paid-campaigns or the marketer; the competitor watch digest; research-market's "What people are saying" section (newest `research/market/<D>-read.md`; check its window); the promo calendar and stock notes from the brief; destination URLs of top ads.

**Do:**
1. Plumbing: test each break signature (ratio jump/collapse, zero-conversion days with spend, ROAS spike with flat orders, LPV/click drop, UTM traffic missing). For each break: symptom, likely location, what to check, the fix when identifiable, what it blocks. Mark affected numbers suspect.
2. For each metric that moved materially at equal maturity: read the change log, check noise, mix shift, breakdown effect and denominator changes, then walk the cause checklist in order. One piece of evidence per named cause; confidence; ruled-out and unconfirmed causes listed.
3. Page/message match for the top 2–3 winners and losers (open the page if the host can browse; else ask for a screenshot): product, promise, offer, price, stock.

**Output:** the report's Plumbing and Why-it-moved sections, and mismatches to note.

# Intake, hygiene and coverage (atom)

**Load:** `../analyze-performance/references/measurement-contract.md`.

**Inputs:** the measurement contract (company type, referee, channel roster); tool reads (`meta_read performance`, `social_analytics_get`, `ads_creative_read`, `video_read`, `campaign_read`); the marketer's connectors / exports / screenshots / pastes from the one input message.

**Do:**
1. Start from the minimum useful read (contract §4) and tick the rest against the roster; big pasted exports are totalled in code when a code tool exists; with none, never totalled by eye — ask for the summary report and mark the referee not measured until it arrives (contract §4); never echoed. Then: what arrived, what didn't ("not checked this week" — no mid-run asks).
2. Hygiene: strip test, wholesale, staff orders and subscription renewals from new revenue; net refunds; align timezone and currency; note discount depth.
3. Maturity: compare this week as first reported with last week as first reported; show last week restated separately. Exports are the week's source; `meta_read` identifies Goose ads and cross-checks — de-duplicate by ad id.
3b. Save the input summary to `reports/performance/inputs/<YYYY-MM-DD>.md` for run-paid-campaigns to reuse.
4. Coverage line: per channel — truth / claimed / not measured / not used; share of Meta spend seen in detail.
5. The type's referee missing (or no total spend) → claims-only mode (labels, no MER, calls capped at first look, first-line notice).

# Creative ranking and channel reads (atom)

**Load:** `../analyze-performance/references/creative-and-channels.md`.

**Inputs:** `meta_read performance` (ranked by spend; the scorecard on the settled `days: 14` minus `days: 3` window, 7- and 28-day reads for the fatigue trend); each Goose ad's angle annotation (`ads_creative_read` and the campaign concepts); the non-Goose export; UTM store conversion per angle; email export; `social_analytics_get` posts and accounts; Google export and search terms; app/local exports.

**Do:**
1. Creative: group by angle → hook → format; rank by spend; apply minimum-spend gates; verdict with confidence; fatigue trend; name no winner if `insight.available` is false; state coverage.
2. Build the per-channel and per-ad scorecards against last run's rows and the angle history line (`../analyze-performance/references/run-memory.md`).
3. Draft "what to make next" from the history: tiring 2+-run winners first, retire losers, fair test for too-early, organic overperformers as paid candidates; nothing that already failed without a new reason; unmade items carried with their first date — producer and date for each.
4. Email & SMS, organic, Google (+ wasted-spend terms), apps, local: one short block each, or "not measured this week" / "not used".
5. Future rows: creators (codes), outreach (reply rates), WhatsApp — named, never dropped.

**Output:** the scorecards for the run record; the report's Creative ranking, channel blocks, channel-table rows and What-to-make-next draft.

# Revenue join (atom)

**Load:** `../analyze-performance/references/revenue-join.md`.

**Inputs:** clean store/CRM numbers; total spend per platform; platform claims; break-even MER and allowable CAC (campaign brief economics box / measurement contract); last week's report (the story the marketer picked).

**Do:**
1. Business-truth table: this week, last week, 4-week average, same week last year.
2. MER, new-customer MER, nCAC, contribution after ads — each vs break-even / allowable / target.
3. Overclaim ratio, like-for-like as in the reference (claimed purchases ÷ store orders, or claimed revenue ÷ store gross; a floor when a claimant is missing), with its 4-week trend.
4. Marginal: Δ new-customer revenue ÷ Δ spend vs last week and vs the 4-week average.
5. If the platform and blended stories point different ways: write both at the same grain, each ending "if true, you'd…", a recommendation, and the cheapest test that would settle it. Carry forward the story the marketer picked last time unless a test changed it.
6. B2B: pipeline chain and cost per qualified lead / opportunity instead of revenue.

# claims-gate

One contract for every playbook that writes copy, scripts, briefs, emails, posts, pages or captions. Only this atom ever writes a claim as approved; claims and markers already in the brand (from the GooseWorks app or an earlier brand pass) are read the same way. The calling playbook keeps its own extract step (on-image text, video scenes, page sections) and hands this atom the spans.

Say it to the human in plain words ("two lines need your OK before I use them"), never as tool, fact or playbook names.

## 1. Load the contract (once per job)

**Which path.** Use the **older path** (steps 1–2: the marker and its `Claims you may use —` facts) on every server today, including ones that list `brand_knowledge_*` tools: approvals customers already gave live there, and a chat sign-off recorded by §5 is usable at once. Also count a brain claim a person confirmed (step 5). Where the two disagree, the stricter wins. Steps 3, 4, 6, 7 and 8 always apply. (The **brain path**, where only brain-confirmed claims count and a chat yes waits for the app, §4.6, applies once the brand's server says chat approvals are recorded only in the app.)

**Local mode** (no GooseWorks, [the `marketing-guide` skill](../marketing-guide/SKILL.md) §5): the contract is `gooseworks-local/<brand-slug>/claims.md`, read and written by [`local-claims.md`](local-claims.md) (next to this file) in place of steps 1–3 and 5. Only a row whose newest status is `approved` and that passes its checks (scope, date, the approver's own words, proof reopened) is usable; declined, pending and retired rows never are. The `dont`s and `must`s come from `brand-notes.md`. §2–4 run as written, with `local-claims.md` for who approves and the record.

1. `gooseworks:brand_read` `sections: ["learnings"]` (lean is enough: it returns every `must` and `dont`).
2. **Older path:** find the **marker**: a `must` fact starting `Claims sign-off (learn-my-brand,` (a fixed format: the opening names its first writer and stays as it is). Read its status token and match it exactly:

# email-lifecycle

One marketer want: "Cart and welcome emails make money while I sleep — mine do not exist." The playbook drafts and stages a lifecycle program; the marketer loads it into their own tool and presses send.

## What you get

1. **Deliverability and list report** — every plumbing item green / red / unknown, each marked *verified* (the agent saw it), *from you* or *unknown*. Never a green the agent did not see. Red and unknown items come with the exact fix and who does it.
2. **Flow pack** — the flows you asked for, or else the top two this business can load today (a third is offered), each a build sheet in your tool's own terms: trigger, filters, exit, re-entry, consent per market, priority and suppressions, timing, and every message finished, plus its goal metric, its test, a holdout where one fits, and the result it should beat. Each flow is marked **ready to load** or **not ready**, with the blocker in plain words ("waiting on your answer about returns", "needs your app to tell the email tool who installed", "your current plan can't run this — here are the options").
3. **Segments, priority and cadence** — segment definitions in the company's own terms (clicks, orders, activity — not opens), the flow priority map and frequency cap, the proposed send cadence.
4. **This week's broadcasts and the month's calendar** — broadcasts finished and ready to schedule (email; SMS only where consent exists and the moment is high-intent); the calendar as one table of dates and ideas.
5. **Proposals awaiting a yes** — offer depth with margin math, cadence, sunset slice, tool or plan changes, a tracking plan for missing events, any high-stakes send.

## Before you start

# broadcast-planner

**Reads:** make-content's next newsletter issue if any; `../email-lifecycle/references/segments-cadence-offers.md`, `../email-lifecycle/references/copy-craft.md`, `../email-lifecycle/references/sms-push-whatsapp.md`, `../email-lifecycle/references/modes-and-incidents.md` (seasonal); the approved cadence and segments from `lifecycle/program.md`; the brand's promotional calendar and launch dates (brain or asked); campaign records with an email/SMS leg via `gooseworks:campaign_read`; last week's results from the latest `reports/performance/*.md`; stock for every product it will feature (asked if the brain does not hold it).

**Does:**
1. **The month's calendar.** One row per planned send: date, segment, type (value / promotional / launch / newsletter), the one idea, offer if any (from the ladder only), channel. Campaign moments come from plan-campaign's brief; the rest are filled to the approved cadence with roughly 60–70% useful sends in non-sale weeks; a pull-back week after any tentpole. Flags blackout dates and shipping cut-offs. Totals the month's sends (sequences built as broadcasts + broadcasts + newsletter, after exits) against the plan's monthly send limit; spreads the sends or proposes the upgrade.
2. **This week's sends, finished.** Per send: segment and exclusions (recent purchasers, people mid-checkout flow, unengaged), send time and time-zone basis, subject + 2 alternates, preview, body, CTA with tracked URL, plain text, the test (subject, send time or offer; winner on clicks or orders; test slice size), stock confirmed for each featured product. Newsletter: slot make-content's issue (`content/newsletter/<date>.md`) with segment, send time and exclusions; this atom does not write the issue.
3. **SMS** only for high-intent moments with SMS consent, with brand name, STOP language, quiet hours, segment count.
4. **Margin box** from offer-math beside every discount.

**Writes:** `lifecycle/calendar/<YYYY-MM>.md` and `lifecycle/broadcasts/<YYYY-MM-DD>.md` (week starting date), plus the same in chat.

# flow-writer

**Reads:** the flow's entry in `../email-lifecycle/references/flow-library.md`; `../email-lifecycle/references/loadable-flow-format.md`; `../email-lifecycle/references/copy-craft.md`; `../email-lifecycle/references/worked-flows.md` (quality bar); `../email-lifecycle/references/sms-push-whatsapp.md` when the flow has those legs. From the brain: voice, banned words, signed-off claims, product records (price, offers, notes), learnings. From the program sheet: tool and plan, segments, priority map, cap, consent per channel. The standing offer from the shared `Standing offer:` fact. From the audit: the live flow this replaces, if any.

**Does:**
1. **Wire it first, in the tool's real syntax** (`loadable-flow-format.md`; when unsure of a tag, name the editor action instead of guessing). Check plan reality: no workflows → a fixed-date sequence becomes scheduled broadcasts with an exclusion list and the sign-up welcome becomes the form's autoresponder, written in the tool's terms (not tool-neutral); only a flow the plan cannot run even that way is said and written tool-neutral. Fill the flow header completely in the tool's own vocabulary: exact trigger name, trigger and flow filters, exit, re-entry, consent, smart sending, quiet hours, priority and suppressions, cap, UTM template, discount object (from offer-math), holdout, A/B test (winner on clicks or orders), build notes. A feature the plan lacks gets its workaround.
2. **Plan the messages.** Count and delays from the library, adjusted to this brand's price and cycle (say why if moved). Write one job per message before any copy. Check the sequence reads as a story, not five versions of the same email.
3. **Write each message finished.** Subject + 2 alternates, preview, from and reply-to, body blocks, one CTA with full URL, merge tags with fallbacks, dynamic blocks with out-of-stock behaviour, splits with a default branch, image needs with alt text (optional art requests as a line: `Graphic needed: for make-static-ads · header art: <flow, message, size, what it shows, alt text> · return to: lifecycle/flows/<flow-slug>.md`), a full plain-text version, footer, and the claim id or record behind each factual sentence. Vary length and shape across the flow. For B2B and services default to plain text from a named person.
4. **Self-check against `copy-craft.md` failure list.** Rewrite any hit.
5. **Leave honest gaps.** Anything the brain and the marketer have not settled stays a visible [placeholder] with its question at the top of the flow file, and the flow's status line reads `not ready: answer Q3, Q5`. A flow written against tracking-plan events reads `not ready: needs events E1–E3 live`; one the plan can't run even with that workaround reads `not ready: needs tool decision T1`. Only a flow with no open blocker is `ready to load` (with `· switch on after fix #N` while authentication is red or unknown); a header-art request never blocks it. Never invent a fact, an offer, a review, a count or an existing event name; events that do not exist yet go into the tracking plan (event, properties, when it fires, which flow) labelled "proposed — confirm with engineering", and the flow is written against those names.

6. **Hypothesis for this cycle.** One line per flow: what it should do and against which number (e.g. "abandoned checkout: ≥ 4% of recipients order within 7 days; baseline unknown"), the goal metric and when it will be read. Saved into `lifecycle/program.md` for the next run's read-back.
7. **Art answers.** On a re-run, read any `Graphic ready:` line under this flow's header-art `Graphic needed:` request and place the image.

# lifecycle-audit

**Reads:** the optional audit items from intake message 1 (flows list, 90-day campaign report, list size, the "original" text of one recent campaign, the spam-rate chart — it asks nothing separately); `lifecycle/program.md` and the latest `lifecycle/deliverability/*.md` if present; the latest `reports/performance/*.md`; whatever the marketer handed over (tool exports, screenshots, Postmaster chart); the customer's own email-tool connector if the host has one (read only). Loads `../email-lifecycle/references/deliverability.md` and `../email-lifecycle/references/benchmarks.md`.

**Does:**
1. **Plumbing.** For each checklist item in `deliverability.md`, collect evidence. Authentication is green only from a marketing test email's headers (sent through the email tool) showing `spf=pass`, `dkim=pass` aligned with the From domain, and `dmarc=pass` — SPF on the tool's own return-path is fine (Mailchimp, and HubSpot without a dedicated IP, can't align SPF; that is not a fix item). Check the headers came through the email tool (its Return-Path or DKIM signature, a List-Unsubscribe header) — a personal Gmail or Workspace email's headers don't count and stay unknown; with a shell, `dig TXT` supports it (return-path domain, `_dmarc`, DKIM selector). A root-domain record alone is "present — not verified for marketing mail". Mark every item verified / from you / unknown. Never mark unknown items green.
2. **List.** Size; engaged-30/90 counts and share (clicks and orders, not opens); growth and churn in the last 30 days; consent source per channel; any bought, scraped or marketplace-sourced segment (hard stop for those contacts); last send date (6+ months dormant → re-permission first).
3. **Flows live** — in the email tool and in the store platform (Shopify's default abandoned-checkout email, Shopify Email automations, review-app request emails such as Judge.me or Okendo), so the build order can switch off duplicates. Name, trigger, status, message count, the last 90 days' recipients, conversion or revenue per recipient. Look for the classic breaks: buyers still receiving cart emails (no "placed order since" filter), overlapping flows with no priority, dead or expired codes, links to removed products, missing fallbacks.
4. **Read-back against last cycle.** For each flow in `lifecycle/program.md`, compare its recorded hypothesis and target — and the last run record's numbers for it (`../email-lifecycle/references/run-memory.md`: same window length, same attribution setting, settled, never opens) — with this cycle's result (the weekly read's email rows or the marketer's export): beat it → keep, promote the winning test; missed it → its weakest message is first in line to rewrite; no data → "not measured". Write each flow's result and next hypothesis into the state block for step 2's ranking.
5. **Recent sends (90 days).** Cadence by segment, revenue or conversion per recipient, unsubscribes, complaints, bounces; the worst three sends and why.
6. **Verdict.** GREEN / AMBER / RED with the blockers first. Only missing consent or complaints ≥ 0.3% stop the writing. Red or unknown authentication blocks switching on and broadcasts, not drafting: flows are still written, marked "switch on after fix #N", and unknown items go on the marketer's fix list. Bulk-sender rules are requirements at ≈ 5,000+ a day to Gmail/Outlook (a list above ~5,000 with unknown Gmail share is treated as bulk); below that, amber best practice. If the list's main market is one where people buy over chat (India, Southeast Asia, Brazil, much of Latin America), the first line says WhatsApp is likely the main channel and is not covered yet.

**Writes:** the report in the format at the end of `deliverability.md`, shown to the marketer before any writing, and saved later as `lifecycle/deliverability/<YYYY-MM-DD>.md`. A short "state of the program" block (list, flows live with last cycle's result vs target, what is broken, what is missing) feeds the flow choice. In chat, the report names no tools or ids — "your sending isn't verified yet: here's the one setting to change".

# offer-math

**Reads:** `../email-lifecycle/references/segments-cadence-offers.md` (ladder and formula); AOV and margin per product or category from `lifecycle/program.md` (marketer-stated); the standing first-order offer from the shared `Standing offer:` fact (else the Brand record's business facts, read with `file_read`; never a search snippet); product records for price.

**Does:**
1. **Check the offer is allowed:** the standing offer, or a step of a ladder the marketer approved. Welcome never deeper than the standing offer; first cart reminder never discounted; no discount to returning full-price buyers in cart flows; no code twice in 30 days. Anything else is a proposal, not a draft.
2. **Compute** contribution per order, discount cost per order, share of contribution used, and the break-even lift, with the inputs shown. Free shipping: cost = average shipping cost × share of orders newly qualifying. Rewards (referral): cost per successful referral both sides vs contribution of the referred first order. Subscriptions and apps: use the subscription formula in the reference (store fee, months retained).
3. **Leakage:** shared vs unique code (if the sign-up form shows a shared code, repeat that code and flag the leakage as a proposal naming the popup edit — never switch it silently), stacking, exclusions, expiry, which segments see it (are full-price buyers in them?).
4. **Recommend one** — usually the cheapest offer that does the job, or a non-discount value (free shipping, gift with purchase, early access) — in two plain sentences.
5. **Unknown margin:** show cost per order in money, say "margin unknown", and do not call it affordable.

**Writes:** an offer box placed next to the flow or send that uses it, and into the "awaiting your yes" list. The approved depth is saved in `lifecycle/program.md`; the approved depth stays in the program sheet (a standing offer the marketer states is written at SKILL step 9).

# send-check

**Reads:** the drafted flows and broadcasts; `../email-lifecycle/references/copy-craft.md`; `../email-lifecycle/references/deliverability.md`; `../email-lifecycle/references/sms-push-whatsapp.md`; the result of the `claims-gate` skill (`../claims-gate/SKILL.md`) for every message (run first, in SKILL step 7); `../ad-policy-check/disclosure.md` (in the `ad-policy-check` skill) for email and SMS disclosure; product records; `lifecycle/program.md`.

**Checks — each item pass / fixed / open question:**
- **Flow logic:** purchasers exit on every step ("placed order since starting"); checkout suppresses cart suppresses browse; a cross-flow cap and smart sending set; re-entry windows set; post-purchase keyed to delivery, not order date; replenishment uses the product's cycle and skips subscribers; every split has a default branch; a sequence built as broadcasts carries an active (dynamic) exclusion list on every send after the first, never a static one; the plan's monthly send limit is respected.
- **Offers:** none deeper than allowed (offer-math ran); unique, single-use, non-stacking codes with expiry; recent purchasers excluded from promos; full-price returning customers never discounted in cart flows.
- **Stock and data:** every featured product in stock; prices pulled live, not typed; every merge tag has a fallback; dynamic blocks hide out-of-stock lines.
- **Claims:** the claims gate has run on every message and its cuts are applied (this atom does not judge claims itself). Shipping, returns and guarantee promises match the `Policy:` facts and the `[lifecycle]` policy rules, including ones confirmed in this run's message 2 and written at step 9. Drug-like wording and financial promises the gate kept are still flagged for a human read — the sentence, not the whole category.
- **Compliance:** consent per market (no abandoned-checkout email to non-subscribed Canadian contacts; CASL implied-consent windows); footer with legal name and postal address via the tool's own tag, visible unsubscribe and preference link, one-click unsubscribe header noted for the tool; SMS: separate consent, brand name, STOP language, quiet hours, local rules for the markets; review requests go to all customers, not only happy ones; no marketing to marketplace-sourced buyers.
- **Rendering:** single column, mobile first, live text, alt text on every image, full plain-text part, dark-mode-safe logo, HTML under 102 KB, seed tests listed for Gmail, Outlook, Apple Mail, Yahoo.
- **Voice and craft:** brand banned words; the 14-item failure list in `copy-craft.md`; one job and one primary CTA per message; subject and preview not repeating.
- **Measurement:** goal metric per flow (never opens); holdout only on always-on marketing flows with enough volume (never transactional, legally required, booking, dunning or one-time launch messages — "no holdout — <reason>"); the random-sample split sits after the message that delivers what the form or a transaction promised — a holdout placed before it fails; one test per flow or send; UTMs consistent.

# honest-review

Used by: make-static-ads (its render-review step) and run-organic-social. The rubric — what to check — lives in each playbook; this atom is how to check and how to report.

## 1. Know what you can perceive

| You can | How | Say |
|---|---|---|
| See images | The host shows them, or a shell host downloads the file and opens it | "checked by eye" |
| Read an automatic description | `gooseworks:media_analyze` on the asset (description, visible text, for video a word-timed transcript and sampled shots) | "the automatic read shows…" |
| Watch motion or hear audio | Almost never — a transcript and sampled frames are not watching | never claim it |

Decide the mode at the start and label every item with how it was checked. Never present the engine's own "passed" or "checked" as your review.

# Human version

Get the search work you asked for: an SEO audit, competitor gaps, a topic map, domain metrics, a plan for templated pages, or an AI-answer visibility check. The report shows the evidence, the priorities and what remains unknown. Changes stay drafts for review.

---

# Agent version

## What you get

One readable, linked report containing the requested deliverable. An audit returns the requested number of ranked fixes; a topic map shows the pillar, supporting pages and links; a pSEO plan includes the templates and data needed to build useful page sets. SEO metrics are obtained and shown when access allows, with missing data stated plainly. Finished copy and code belong in the report's closing editor section; new-page briefs use the existing page-map shape.

## Before you start

# citation-check

**Reads:** `search/questions.md`; `../improve-search-visibility/references/citation-protocol.md`; the last run record's per-question snapshot (`../improve-search-visibility/references/run-memory.md`); the canonical brand facts from the brain (for accuracy checks on brand questions); the tracked competitor list.

**Does:**
1. **Free pass (step 1):** ChatGPT, AI Overview and AI Mode in the host's own browser (private window, signed out; stop on any CAPTCHA or refusal and mark the surface), and the host's web search for who ranks, labelled "web search". **Paid top-up (step 3, only after the one yes):** Google's exact page one through `gooseworks:data_call_provider` (provider `scrapecreators`, path `/v1/google/search`, the query and region), inside the ceiling (the `spend-gate` skill (`../spend-gate/SKILL.md`) proxy branch), stopping at it. No browser → the minimum paste set, offered in the first message.
2. **Run** — ChatGPT once per question and three times for the key questions; AI Overview and AI Mode once each when Google allows; Google page one once per question in the top-up; pasted: 5 questions (up to 4 key questions + at least one brand question), ChatGPT twice, AI Overview and AI Mode once each. New chat per question, memory off, never the brand name in non-brand prompts. Wait for each answer to finish (protocol's wait rule); unfinished answers are retried once, never scored as misses.
3. **Only this run's observations count.** An earlier run's answers are the baseline from the last run record (`../improve-search-visibility/references/run-memory.md`): shown as "last checked <date>" beside today's reading and compared only like with like (same question version, same route and location, the noise rule there), never counted in today's numbers or tables. A surface not checked today says "not checked today".
4. **Record** every run with the full field list; save verbatim answers. Note whether ChatGPT searched (sources shown) — answers without search come from training memory.
5. **Classify** every cited URL by source type. For brand questions, list each stated fact and compare it to the brain: correct / wrong (quote both) / not on file.
6. **Score** each row (named k of N, won/partial/lost/no-brand answer, prominence, stable or unstable), then mention rate per surface and stage, own-citation rate, third-party coverage and share of voice against the brands the engines named. Won = ≥ ⅔ of runs; unstable = some but not all; one run is never stable.

**Writes:** the rows table used by the report and the verbatim runs file (`search/visibility/<date>-runs.md`, not imported); every charge is logged by the spend gate, and the report states credits charged against the ceiling in the gate's own words.
**Never:** reports one run as fact; passes an organic or API read off as what buyers see in the AI apps; ranks the brand "#2 in ChatGPT".

# entity-footprint

**Reads:** `../improve-search-visibility/references/entity-and-local.md`; the canonical facts from the brain (name, one-liner, category, founding facts, domain, pricing, locations); brand-question accuracy errors from the citation check and the sources they traced to.

**Does:**
1. Confirm the canonical facts with the human if the brain lacks any (never guess founding year, HQ, NAP).
2. Pick the five profiles that matter for this type (always include any profile an engine cited for a wrong fact). Read each public page with the host's fetch where allowed (never G2, Capterra, Trustpilot or Amazon — they forbid automated collection; blocked or no fetch → ask for a screenshot, else "not checked"); mark complete / inconsistent / missing / unclaimed and list mismatches.
3. Local: per location (worst 2–3 first on a large chain) the Business Profile fields, NAP across directories, review count, average, recency and reply rate.
4. Write each correction as exact field values plus how to edit (claim steps, vendor portal, suggest-an-edit). Review gaps → a review-request brief addressed to email-lifecycle. No reply drafts: replying to reviews is not covered yet (say so plainly).

**Writes:** the entity table and candidate fixes.
**Never:** drafts a Wikipedia article; adds an unsourced Wikidata item; suggests fake or gated reviews or incentives tied to a positive rating (a platform's own disclosed programme is fine); adds keywords to a Business Profile name.

# fix-writer

**Reads:** `../improve-search-visibility/references/finished-fix-examples.md`, `../improve-search-visibility/references/gap-to-fix.md`, `../improve-search-visibility/references/prioritising.md`; `../improve-search-visibility/references/page-map.md`; the page map row the fix or brief comes from; the brand's voice; product records; the CMS and who ships (from intake). Claims are decided by the `claims-gate` skill (`../claims-gate/SKILL.md`), run over every finished fix in SKILL step 4 — this atom never decides a claim itself.

**Does:**
0. Honor the request's count and job scope from `../improve-search-visibility/references/seo-jobs.md`. A technical finding with insufficient code/CMS access gets an exact engineering handoff (affected URLs, observed defect, proposed outcome, verification and risk/undo), not guessed implementation. Use `Agent: <time> - Human: <active time>` when estimating work.
1. Write the change itself: the exact title/meta/H1/opening paragraph, Q&A block, markup, field values, robots line, listing text or drafted inclusion request — in the CMS's terms (where in Shopify / WordPress / Webflow it goes; markup as an edit to the theme's existing block with live values, never a second hard-coded block).
2. **Facts in the draft:** mark every sentence that states a fact with its source (a "Claims you may use" fact, a product record field, or [PROOF NEEDED]) so the claims gate can keep, rewrite or cut it. The live page supplies plain product facts only (name, price, size, listed ingredients, how to use) — re-read prices from it; ratings and review counts appear only as a "Claims you may use" fact, or in markup that mirrors reviews shown on the page. **The brand's own marketing lines are claims too** ("closes the loop", "self-improving", "growth outcomes" from the site, the kit description or value props): without sign-off they are cut or rewritten to plain facts, or shown as `[needs your sign-off: …]` — never pasted into fix copy as ready to publish. **No comparison table or outreach line about a rival** unless each cell comes from that rival's own page, read this run and cited; otherwise leave the rival out. Competitor facts come only from the competitor's own page, read this run and cited with its date — never from a list or a review site — and only if the human allows naming rivals.
3. **Two versions of every fix.** For the report's "What to do" section, plain words only: what changes and where, who does it and how long, why it is a priority (the gap it closes, said as the buyer question it fixes — never a question id), how we'll know it worked. For the report's last section, "For whoever edits your site": the finished copy, field values or code and exactly where it goes, plus time to show, risk and undo.
4. **Page briefs** ("needed" rows of the page map, listed separately from this week's visibility fixes) to `search/briefs/<page-slug>.md` in the exact shape in `../improve-search-visibility/references/page-map.md` (make-content's brief input).

**Writes:** both versions into the report, the working copy into `search/fixes/<date>.md`; brief files. Briefs name the questions they answer in words, not ids.
**Never:** "add an FAQ", "improve E-E-A-T" or any instruction without the finished text; invented stats, prices, dates or reviews; FAQ markup promised as a rich result.

# page-and-foundation-check

**Reads:** `../improve-search-visibility/references/foundation-check.md`, `../improve-search-visibility/references/gap-to-fix.md`; the requested audit scope (`../improve-search-visibility/references/seo-jobs.md`) or gap rows and nearest pages for a visibility check; sitemap/crawl inventory and Search Console export when available.

**Does (free checks first):**
0. **Find the pages.** `gooseworks:knowledge_import` in its website **discover** mode lists up to 25 same-site pages for free; use these as starting leads, then inventory the requested scope from sitemaps/feeds/indexes or crawl exports; 25 is not the site's page limit. Import mode only when the host cannot fetch pages at all: the needed selected pages, only inside the same ceiling the human agreed (the import's own cap described in words, per the spend gate), then read them with `gooseworks:knowledge_search`.
1. **Site-wide once (free):** fetch robots.txt and classify every rule by retrieval vs training bot; with a shell, test CDN blocking by requesting a page as OAI-SearchBot and PerplexityBot vs a normal agent (no shell → not checked, developer checklist); sitemap; duplicate platform host; Search Console and Bing Webmaster Tools set up (from intake). Indexing comes from Search Console if shared, else from the one paid `site:` probe of the credit flow (step 4).
2. **Per page:** status and redirects, canonical, robots meta and header, content visible without JavaScript, title/H1/meta, the answer-first opening, structured data validity and match with visible text, field speed data where available, internal links in.
3. **Compare with the winner (when relevant to the job):** for each lost key question, the passage the engine lifted from the winning page vs the brand's page — what the winner states that the brand does not.
4. **Near-winners:** from available Search Console or clearly labelled managed SEO/query evidence, queries around positions 4–15; high impressions/low click rate only from own performance data. For an audit, include relevant queries beyond a prior AI question set.
5. For technical audits, include the foundation reference's applicable migration, facet, rendering and competing-page checks. State sample coverage; implement nothing live. Mark everything pass / fail / not checked. Use the host's own fetch or shell; what it cannot see goes to a short developer checklist — never a technical question to the human. Read the theme's existing structured data before proposing any.

**Writes:** the foundation table and per-page notes for the report; candidate fixes (blockers flagged) for fix ranking.
**Never:** marks an item passed that it did not see; proposes a structural change (robots, redirects, noindex, URL change) as anything but a proposal with risk and undo.

# question-set

**Reads:** `../improve-search-visibility/references/question-list.md`, `../improve-search-visibility/references/battlegrounds.md`; brand summary, products, audience, competitors (`gooseworks:brand_read`, `gooseworks:competitor_read`); research-audience's `research/audience/voc-bank.md` and research-market's `research/market/demand.md` if present; customer language via `gooseworks:knowledge_search` with `source_types: ["document", "evidence"]` (query "Voice-of-customer bank — customer questions, objections, words customers use"); Search Console export if shared; the previous `search/questions.md` and `search/page-map.md` on re-runs.

**Does:**
0. **Cover every audience the site sells to.** If the site sells to more than one buyer or carries more than one positioning, include questions for each, so the decisions message can ask which buyer to win.
1. Re-run: reuse the saved set, then **top it up to the mix** — at least 3 brand-accuracy questions and every audience the site sells to — before anything runs; propose at most 3 other additions or swaps with reasons; keep ids stable — the same id always means the same words: a reworded question gets a new id and the old one is marked `retired (reworded → Q<n>, v<N>)`, so the next run never compares different wordings.
2. First run: draft 18–20 candidates across the stage mix in both forms, never with the brand name in non-brand questions; 3–6 brand-accuracy questions always; local variants per city for physical businesses.
3. Score value (buying intent 1–5, `../improve-search-visibility/references/question-list.md`) × winnability (1–3) provisionally with a one-line reason each; drop to the best 12–15. A brand name that is a common word always carries the category in brand questions. Pre-launch: category questions plus one name-collision question only.
4. **Cluster and weight.** Group the questions into clusters (one cluster = one page that should answer them); with a Search Console export, sum each cluster's impressions as its demand weight and add any high-impression query the list missed. These clusters are the page map's rows.
5. **Pick the key questions yourself** (the 3–5 highest value × winnability) and run the set — no approval before the free pass. The first message shows the set grouped by cluster for edits; edits apply to the paid top-up and the next runs.

**Writes:** `search/questions.md` in the saved-set format (version, date, country, language, engines, runs·route line, the table with a cluster column).
**Never:** invents search volumes or "how many people ask this". Demand comes from Search Console, Google Trends or autocomplete (free), Keyword Planner when the brand shares it, or a vendor prompt-volume estimate the brand already has — always labelled with its source, estimates as estimates; otherwise "no demand data, ranked by judgment".

# store-listing-audit

**Reads:** `../improve-search-visibility/references/app-store-listing.md`; the store links from Before-you-start step 4's lookup (ask only if not found); the iOS keyword field (asked — not public); the "best app for X" rows from the citation check; product facts from the brain.

**Does:**
0. Before release: write the launch-day listing (name, subtitle, keywords, short description, first three captions, with counts) and skip the comparison of ratings.
1. Read the public listings (host fetch; blocked or no fetch → ask for screenshots) for the brand and three competitors: name/title, subtitle/short description, description opening, first three screenshots and captions, rating and count, recent review themes.
2. Write the rewrite table: field · now · proposed · count · why — following the indexing rules; every product statement kept only if the claims gate allows it (SKILL step 4) — captions like "works offline" or "never jolts" are claims.
3. Rating below ~4.3: an engineering ticket for the native rating prompt after a positive moment.
4. Note that iOS name, subtitle and keywords ship with the next app version.

**Writes:** the listing fix (candidate for the five) and the audit table for the report.
**Never:** uses rival trademarks; claims a keyword rank it cannot see.

# make-content

## What you get

One of five things, saved to the brand's workspace and shown in chat:

1. **A repurposed set.** One finished asset is mined into scored units. Each platform the brand uses gets a native version with a different lead unit and hook, ready to paste. Each version has an asset line saying what visual it needs and who makes it.
2. **A single post.** One LinkedIn, X, Threads or Instagram post, a thread, or an X long post or Article (references/formats.md), written native to its platform. It skips the calendar and the units table unless there is a source asset.
3. **A fresh piece.** A one-page brief, then a first draft in the brand's (or a named author's) voice. Long-form adds the publish kit: headline options, meta, slug, H2 skeleton, internal links, CTA, image notes and distribution notes.
4. **A refresh redline.** An old piece rewritten where it decays, with each change and its reason.
5. **This week's newsletter issue,** written from a saved template and the week's notes.

Every piece carries an **edit note** and a **claims check**: what was kept, softened and cut, and the proof that would restore each cut. The formats are listed in references/formats.md. Anything else is routed (Out of scope).

# Content brief

No fresh draft starts without a brief. Write it, check it against the six gates below, and save it before drafting.

## Read first (all free)

- `gooseworks:brand_read` `sections: ["summary","kit","learnings"]`, lean (it returns every `must`/`dont` fact; read learnings in full only for `do`/`insight` rules): the voice, audience, value props, the kit's reference examples and templates, and the learnings (`must` / `do` / `dont`). Read the kit in full (alone: `sections: ["kit"]`, `detail: "full"`) only when you need its example lines or images.
- `gooseworks:knowledge_search` with the topic as the query, across all source types. This returns past creatives and feedback, saved rules, customer evidence and documents. Then work out which brand claims are usable through the shared claims gate (the `claims-gate` skill, `../claims-gate/SKILL.md`): signed-off claims, the scoped sign-off this run, or plain product facts only. Proof slots may only hold usable claims and the sourced facts in `../make-content/references/fact-rules.md`.
- The voice-of-customer bank (research-audience writes it): `gooseworks:file_read` `research/audience/voc-bank.md` (brand coworker scope). If it is not there, use `gooseworks:knowledge_search` `source_types: ["document","evidence"]`, query "voice-of-customer bank <topic>". It gives buyer phrases, objections and questions on this topic, each with its source and date.
- When the ask comes from a sibling:
  - **improve-search-visibility page brief:** `gooseworks:file_read` `search/briefs/<page-slug>.md`. It gives the cluster, intent, the questions the page must answer, the facts it must state, the claims allowed and the competitor-name rules. Put the brief's path on the draft's first line.
  - **plan-campaign asset list:** `gooseworks:campaign_read` `campaign_id` gives the brief, the concepts and the asset row.
  - **analyze-performance "what to make next":** the latest `reports/performance/<date>.md` (`gooseworks:file_list` `reports/performance/`), its "what to make next" section.
- When it is a comparison: `gooseworks:competitor_read` for dated competitor facts.

# Source to units

Input: the full text or transcript of one finished asset (`../make-content/references/repurposing.md` §1 says how to get it in). Read it completely before mining. Never mine from a summary.

## Output table

```
Source: <title> · <link or media_asset_id> · <length/duration>
| # | Type | Anchor (verbatim, ≤25 words) | Where (timestamp / ¶) | Alone | Charge | Novel | Proof | Total | Best homes |
|---|------|------------------------------|-----------------------|-------|--------|-------|-------|-------|------------|
```

- **Type:** claim · contrarian take · story · stat · quote · framework/steps · mistake+fix · before/after · objection+answer · audience Q · demo moment.
- **Scores (1–3):**

# Edit, check, edit

Run on every fresh draft, refresh redline and repurposed set. The full checklists are in `../make-content/references/editing.md`.

1. **Substance pass.** Write four answers into the edit note:
   - the thesis in one arguable sentence;
   - the swap test (pass, or what fails);
   - the fakes removed;
   - whether the CTA matches the intent.

   Run the rest of Pass 1 (so-what, proof density, skeptic, order, hedging) as checks. Fix what fails without writing it up.
2. **Claims check:** the shared claims gate (the `claims-gate` skill, `../claims-gate/SKILL.md`) for brand claims, plus `../make-content/references/fact-rules.md` for world facts, competitor facts, stories, sensitive topics and third-party rights. When the piece is sponsored, affiliate, gifted or a creator collaboration, also load `../ad-policy-check/disclosure.md` (in the `ad-policy-check` skill) and apply it (disclosure in the piece itself, before "more"). It cuts and softens lines, which leaves gaps.
3. **Readability pass** on the post-cut text: smooth the gaps, headline, lede, H2s as claims, scannability, ending. Then **voice match** against the best voice sample available, in this order:
   1. the named author's voice card (bylined pieces);