Marketing Mega-Pipeline

One command produces a product's full asset suite: brand onboarding, UI polish, logo reveal, product demo, launch video with audio, social clips, and OG assets. The individual asset skills own their recipes; this skill owns sequencing, gates, and run state.

REQUIRED BACKGROUND: marketing-studio (engine-repo workflow shape and non-negotiables). All PLAYBOOK rules apply.

Production route: read docs/production-quality.md. Require --project <product-repo> and use <workspace> = <product>/marketing/assets/<brand>. Every generated capture, audio file, prop, public-stage asset, render, report, matrix row, and post kit stays in that product workspace. Engine-local out/ is not a product-run path.

Resume check — before anything else

Read <workspace>/marketing/run.json. If it exists and any asset is not delivered, this invocation is a RESUME: load its intake and continue at the first incomplete asset. Confirm every claimed artifact exists inside the product workspace before trusting state.

On resume, still run the Phase 1 environment checks (shared-repo guard + launch.py --check — the previous process died mid-flight), but skip brand onboarding and Phase 2 polish if the manifest marks them complete. Trust a rendered/approved status only after confirming its artifact actually exists on disk; missing or truncated artifact → demote that asset to planned.

Phase 0 — Intake: ONE batched question round, then silence

Fresh runs only. Ask everything in a single AskUserQuestion, then run without asking again (exceptions: per-asset stills gates in gated mode, final delivery):

1. Product/brand — which brand and the explicit product repo used by --project.
2. UI polish before filming? Default YES: the demo films the real running app, so rough edges get rendered at 60fps forever. YES = impeccable → polish → frontend-verify on the product repo before any capture. NO = film as-is. This edits product code, so it is always the user's call — never silently skip it AND never silently do it.
3. Audio — music + voiceover is the default and the only thing a film ships with; ask only WHO narrates (brand voice id vs default) and whether music leads or narration leads. "None" is not an option and music-only is a recorded exception (--music-only), never a default: a film with no voice explaining the product is not done (CLAUDE.md, learned 2026-09-01).
4. Social clips — platforms and count (default: X + LinkedIn, one each).
5. Checkpoint mode — full-auto (self-check stills, user reviews the final gallery) or gated (user approves stills before each full render).

Phase 1 — Foundation

1. Shared-repo guard + python launch.py --check (marketing-studio steps 0–1), then node scripts/install-skills.mjs --check — it warns when a bundled skills/ copy and its installed ~/.claude/skills copy have drifted, so the run does not follow a stale checklist. Warn only; fix the drift or note it, then continue.
2. Brand: if brands/<id>.json is missing, onboard per PLAYBOOK. Brand-token judgment stays in the main loop — do not delegate it.
3. Create <workspace>/marketing/run.json. It stores the intake answers and one entry per planned asset. Statuses mean exactly this:
   • planned — not rendered yet. Gated mode: user approves pre-render stills before the render starts (that is the ONLY user gate per asset).
   • rendered — artifact on disk, post-render frame check pending (extract 2–3 frames from the artifact and inspect them — self-check in both modes).
   • approved — frame check passed; approval is recorded in the manifest the moment it happens, never inferred from chat history. A resumed session redoes the frame check for any rendered asset, showing the frames to the user first in gated mode.
   • delivered — copied to the product repo. Update the manifest after every status change. Never restart a run from scratch because the session died. In executor-judge mode the judge writes rendered plus the artifact path the moment an executor returns, before judging: the truckside session died on 2026-09-05 with a finished, scored launch film on disk and a manifest that still read planned, and the resume had to be reconstructed from file timestamps.
4. Infographic bridge: build the product-owned <workspace>/marketing/infographic-style.md, then name it when an infographic is part of this run so that asset uses the approved brand tokens.

Content and direction gate. Once <workspace>/marketing/brief.json is synthesized and passes the copy gate, generate direction, shot plan, and production plan with the product-aware builder. Run node scripts/build-storyboard.mjs <brand> --project <product>. Approve the grounded copy and a style frame, then build an audio-bearing animatic with scratch voice/music and obtain named non-author approval before full rendering.

Brief synthesis rules. The zod schema (studio/src/lib/brief.ts) is the contract; fill the grounding sections, not just the copy: audience + customerLanguage + objections + switchingForces from the brief-inputs grounding, and a proofPoints entry (claim + source) for EVERY number the copy cites — an unsourced stat is fabrication, omit it instead (lint-copy WARNs on stat-shaped claims in a brief with no proofPoints). Draw hook.headline and each of the (up to two) altHeadlines from DIFFERENT hook categories per references/hook-formulas.md, record the categories in hook.strategies, and include at least one emotion-forward category (story/contrarian) against a value hook — evidence in references/campaign-evidence.md (read it before synthesis; it also lists debunked claims that must never appear in copy). Build cta with the [Action Verb] + [What They Get] formula. The storyboard renders the grounding sections so the approver can check copy against facts.

Copy council (full-auto mode). Before the main-loop judge accepts the storyboard, run a 3-judge council on the brief copy: three parallel Sonnet subagents (model: claude-sonnet-5, explicit), one per lens — positioning sharpness (would April Dunford sign it?), emotional resonance vs feature-dump, and evidence honesty (every claim traced to a proofPoint) — with the third judge additionally instructed to argue AGAINST shipping the copy (mandatory dissenter; kills the echo chamber). Issues raised by 2+ judges go back to synthesis; single-judge nits are noted, not blocking. In gated mode the human storyboard review replaces the council — offer it only if the user asks for a copy critique. (Pattern adapted from Corey Haines' marketing-council skill, MIT.)

Phase 2 — UI polish (only if opted in)

In the PRODUCT repo: impeccable → polish → frontend-verify. Must fully complete before Phase 3 — re-shooting every asset because the UI changed after capture doubles the run. Commit product-repo polish separately from asset delivery.

Phase 3 — Asset pipeline: STRICTLY SEQUENTIAL

The engine repo is shared mutable state (props builders, registries, render queue). Two asset skills at once collide and renders saturate the CPU. One asset at a time, in this order. (One blessed exception: /logo-reveal touches only the engine repo and captures nothing, so it may run concurrently with Phase 2 polish, which touches only the product repo — zero shared state, real wall-clock savings.)

Per asset, inspect inexpensive representative stills before a full render. For the hero film, generate hash-bound start/middle/end samples for every planned shot from the exact final render with contact-sheet.mjs --project <product> --plan ... --render .... Footage caches also live in the product workspace; --force re-captures only when needed.

Render budget: one full-resolution render per asset. The renderer is not where a two-hour run goes; correction rounds are. Measured 2026-09-01 on the 24-core box: a full-res LaunchVideo render is ~9 minutes and --x264-preset barely moves it (Chrome frame rendering is the bottleneck, not encoding), while --scale=0.5 renders 3.3x faster. So: judge every round from the contact sheet, and when a round needs motion, render the preview at --scale=0.5 as launch-vN-preview.mp4. The full-res render happens ONCE, after the stills pass. The postflop launch step rendered three full passes (27 minutes of the step's 48); this rule makes that one. A product bug found mid-capture is a note in run.json judgeNotes for the user, not a fix inside the run (postflop's demo step spent 64 minutes that way).

Budget the VO before you dispatch #4, not after. Picture-lock (#3) and audio (#4) are separate steps, and the trap between them is that measured VO word timings DERIVE act lengths, so scoring a locked film can push it past the 30-90s band launchTiming.test.ts enforces. Do the arithmetic yourself at dispatch time and hand it to the executor: frames_available = 2700 - current_total, minus the demo act which is FIXED (the PLAYBOOK forbids shortening a recorded demonstration to fit narration). Estimate each act's need at ~150wpm plus VO_LEAD + VO_PAD. If the narration overruns, say so in the brief and name the act to cut hardest — copy is trimmed ONLY in build-<brand>-audio.mjs, never by editing act constants. Measured on the practicalsystems run (2026-08-17): an 80.8s lock left 276 frames of headroom against ~564 needed, so ~25 words had to go. Name any claim that must survive the trim, because the shortest phrasing is often the false one — "cold outreach never sends without a human" compresses to "nothing sends without a human", which was untrue there.

Phase 3.5 — Responsive export matrix. After the scored launch and social clips pass their own review, run render-matrix <brand> --project <product> --production --stills-only to prove all formats. This is non-delivery layout evidence. Then run the production matrix without --stills-only; it binds each complete row to the approved plan and strict evidence. Use --verify-production to recheck pending existing media without rerendering it.

Execution mode — pick by session model

• Opus or Sonnet session (default): run each asset skill inline in the main loop. Visual-tuning loops go to Sonnet subagents (model: claude-sonnet-5, always explicit) so iteration stills die with their context. Mechanical checks: Haiku or inline. Escalate to Fable at most once, standalone, only if a new template must be designed mid-run.
• Fable session (e.g. ultracode "/marketing" with Fable as the main model): executor-judge mode, below. Fable never executes asset recipes inline — its context grows for hours at judging-grade rates while doing checklist work.

Executor-judge mode (Fable session)

Fable is the judge and orchestrator; it holds only the intake answers, the manifest, dispatch prompts, and verdicts. Everything heavy happens in disposable executor contexts.

1. Brand onboarding stays in the main loop — one-time judgment work, exactly what Fable is for. If brands/<id>.json is missing, derive tokens from the product repo (DESIGN.md, tailwind, CSS vars per PLAYBOOK) and fold any underivable values into the Phase 0 intake batch — never a mid-run question to an absent user.
2. Phase 2, if opted in, goes to one claude-opus-5 executor that runs impeccable → polish → frontend-verify in the product repo and returns before/after screenshots plus the verify result as raw data. Fable judges those before any capture starts — the polish pass is heavy UI work and does not belong in the judge's context.
3. One executor subagent per asset, strictly sequential (the engine repo and CPU rules from Phase 3 apply unchanged). Models, always explicit: claude-opus-5 for /product-demo and /launch-video (capture choreography and copywriting need judgment); claude-sonnet-5 for /logo-reveal, /audio-track, /social-clip, /og-assets (recipe execution).
4. Dispatch prompt contract: tell the executor to read the asset's SKILL.md, the marketing-studio skill, and the PLAYBOOK gotchas before acting; give it the brand id, manifest path, and intake answers; have it execute the recipe through full render and return raw data — output path, 3 extracted still paths, and any deviations. No prose reports.
5. Judge protocol per asset: Fable Reads the returned stills and judges against the brand's voice rules, composition quality, and copy (no em dashes, no hype). Approve → manifest approved, next asset. Problems → send a numbered correction list via SendMessage to the SAME executor (its context is intact; never respawn a fresh executor to fix its own work). If the resume fails because the executor's transcript is gone (it happens), spawn a MINIMAL corrections executor whose prompt carries the complete defect list plus file-level context — never re-run the whole asset recipe. Maximum 3 correction rounds per asset; after that, record the asset as rendered with judge notes and move on — the user adjudicates it in the final gallery.
6. This mode is full-auto by definition — Fable replaces the per-asset user gates as a stronger judge. The user still sees the final gallery (Phase 5 is unchanged), and delivery + commits stay in the main loop.
7. Fable never spawns Fable, and the 3-Fable session cap applies. Executors are the fleet; the judge is singular.

Dynamic workflows — the only two uses

Whatever the execution mode, the Workflow tool touches only read-only fan-outs. Asset execution NEVER goes in a workflow: workflow agents run in the background with no channel back to the judge or the user, renders are CPU-bound and serial so fan-out buys zero wall-clock, and each fresh agent() re-reads the PLAYBOOK per call. Corrections need SendMessage to a live executor — a workflow can't do that. Mechanical single commands (smoke.mjs, file copies, manifest I/O) stay inline in Bash; a subagent spawned to run one command costs more than the command.

The two legitimate workflows, all agents Sonnet with model explicit:

1. Phase 4 brand-compliance sweep: parallel() one reviewer per asset still, each finding adversarially verified before it triggers a re-render.
2. Optional pre-delivery judge panel: 3 judges score the full gallery; only issues flagged by 2+ judges go back to Phase 3. In executor-judge mode this panel is a pre-filter — the panel flags, the Fable judge adjudicates.

Fable never goes inside a workflow (the model-guard hook blocks it in parallel()/pipeline() constructs anyway).

Phase 4 — Final QA

1. Watch the entire scored hero film with sound as a viewer before reading judge scores. Record whether you would share it and a concrete defect list; weak work returns to its cheapest responsible stage. Contact sheets cannot make this decision. 1a. node scripts/smoke.mjs — runtime gate; it is not visual approval. 1b. node scripts/check-audio.mjs <brand> --project <product> — HARD gate: every delivery-surface video carries its intended mastered track. Run it again after postkit. 1c. Run the existing A/V sync, pacing, palette, motion, drift, and budget judges with --project <product> where supported. judge-audio is mandatory reading, not optional: the sound-design judge's PASS counts VO lines from the manifest, while judge-audio transcribes the master and is the only check that proves each line was heard. On truckside (2026-09-06) the scored film passed the sound-design judge with a music bed whose outro fell inside the picture, which left 3s of dead air and an unheard line that only judge-audio caught. Read its content, order and trailing-silence lines before approving the audio track. These measure properties; warnings return to the perceptual review rather than becoming invented aesthetic thresholds. 1d. Record the structured non-author review in Mission Control, then run judge-production <brand> --project <product> --plan <production-plan.json> --render <final.mp4> --strict. Missing or stale stage approval, three-per-shot evidence, full render/audio attestations, or hash bindings blocks delivery.
2. Brand-compliance sweep: one Sonnet subagent reviews a still from every asset against the brand's voice rules (e.g. noban: profit gold #d6c23c, never green). Re-render only violators — but VERIFY findings against the product repo's source first. Product screenshots inside assets show the PRODUCT's own fonts/tokens, not the engine brand's stand-ins; a reviewer expecting the engine's mono will misread the product's mono as a violation (paperroute run 2026-07-10: 4 of 5 sweep findings were this exact false positive; the fifth was a real product bug, fixed in the product repo, no asset re-render needed).

Phase 5 — Delivery

1. Assets already live in the product workspace; do not copy an engine-local render into place at the end. Write a product-owned README listing each file and intended use.
2. Launch node scripts/mission-control.mjs <brand> --project <product> and give the user its local URL. First re-run contact-sheet on the hero master if any matrix row's judge ran after it: every judge-production run overwrites production-evidence.json, and the console binds the perceptual review to whatever render the evidence names last (truckside 2026-09-06: it pointed at a rejected 9:16 row until the sheet was regenerated). The run is not done until a named non-author has watched the scored film and the structured review is bound to current evidence.
3. Poll <workspace>/marketing/{run,review}.json for approve/redo actions. Approval is a recorded, hash-bound action, never inferred from chat. A redo returns to the responsible stage and produces a new version rather than overwriting evidence.

Phase 5.5 — Thumbnails and paste-ready post kits. Extract thumbnails from the product-owned matrix, then run node scripts/build-postkit.mjs <brand> --project <product> --production. It copies only strict-PASS, hash-bound matrix assets and keeps captions, alt text, checklists, licences, and disclosures beside the media.

Phase 5.75 — Results loop (after publishing, usually a later session). /launch previews by default and takes the product-owned post kit. Live posting remains a separate explicitly authorized action. Record live URLs and later metrics in <workspace>/marketing/posts.json; feed the winning hook category into the next brief rather than treating one campaign's visual treatment as a permanent template.

Phase 5.9 — Prove the link preview actually changed. After delivery and site redeploy, compare the live og:image/twitter:image against the delivered product-owned OG file. A correct render does not prove the deployed meta tags or CDN are current.

Phase 6 — Close out

1. Commit engine source changes only when this run required them (tests + lint + smoke first); generated run data stays in the product repo.
2. Commit product-repo delivery.
3. Final summary: per-asset table (file, duration, status) + deviations log.

Red flags — stop and re-read this skill

• Running two asset skills concurrently "to save time" → engine-repo collision.
• A second full-res render of the same asset before its stills passed → the render budget above; preview at --scale=0.5.
• Fixing the product mid-run because the capture exposed a bug → note it, keep filming.
• Starting with /launch-video "because it matters most" → brand bugs found at the expensive end.
• Capturing before Phase 2 finished → everything gets re-shot.
• "Session died, start over" → read run.json and resume.
• Asking the user questions one at a time across the run → all questions live in Phase 0.
• Deciding yourself whether to edit the product's UI → that is intake question 2, the user's call.