Run: 017 · Date: 2026-05-06 · Phase 1 author · Mission: 3-page About Us PDF for Next Chapter
This is the debrief Phase 1 slice. Phase 6 is when I write the run notebook. Phase 1 is where I instrument the run so Phase 6 has signal to weave. Below: success metrics, instrumentation list, predicted gaps, draft "Why this matters", and predicted currency events.
1. Success metrics. what tells us this PDF worked A 3-page PDF emailed to ~50 midmarket owners is a one-shot artifact. Open-rate is meaningless (PDFs don't fire pixels). Trackable proxies, ranked by signal strength:
Demo URL hit-rate — unique visitors landing on /buyside-hunt and /hunter from the Page-3 link, segmented by UTM. Target: ≥30% of recipients click through (15 of 50). Measured via Vercel Analytics + UTM in the PDF link. Demo-completion rate — % of clickers who run the demo end-to-end (submit a query, see results). Target: ≥40% of clickers (6 of 15). Measured via a custom demo_completed event fired client-side on results render. Reply-or-book rate — % of recipients who either reply to the send-email or book a 15-min via the Page-3 calendar link. Target: ≥10% (5 of 50). This is the only metric that maps directly to revenue intent.
Anti-metric to ignore: time-on-page. PDFs leak readers to email clients, browsers, AirDrop. duration is noise.
2. What to instrument BEFORE send
InstrumentWhereTool / Code UTM tags on every Page-3 linkInside the PDF (writer + draper own embed)?utm_source=aboutus_pdf&utm_medium=email&utm_campaign=founders50&utm_content={recipient_id} Per-recipient unique short linkOne short URL per of the 50 foundersEither Bitly batch or a Vercel rewrite at /p/{token} → demo URL with UTM hydrated server-side. Token mapped to recipient in Supabase aboutus_pdf_sends. Demo-page entry beaconsrc/app/buyside-hunt/page.tsx and src/app/hunter/page.tsxuseEffect on mount → POST to /api/track/demo-entry with utm + token. Stored in Supabase demo_session_events. Demo-completion eventWherever results render in buyside-hunt and hunterFire demo_completed after successful results render (≥1 row returned). Same endpoint, different event type. Post-demo email captureEnd of results view"Want this run on your list? Drop your email." Lightweight form → Supabase aboutus_pdf_leads. Calendar booking attributionCal.com or Calendly link on Page 3Append ?utm_* to the booking URL. Cal.com supports custom params on bookings. captured in webhook to Supabase. Reply trackingGmail label + Fireflies/listener pickupApply Gmail label aboutus-pdf-reply to any reply to the send-thread. listener skill auto-classifies sentiment.
Implementation owner mapping: architect lays the Supabase tables and API route, writer/draper embed the URLs, hunter+market-analyst supply the recipient list, quarterback owns the send + reply triage.
3. Predicted cross-system gaps this run will surface
No skill currently owns image/visual generation. Page 1 of an "operator-to-operator credibility" PDF needs imagery (Ewing's headshot, a hero visual, deal-room screenshots). draper owns voice + layout but image-gen tooling (Midjourney, DALL-E, screenshot capture pipeline) isn't formally owned. swarm-upgrade signal: propose image-director or extend draper. The deals app and chapter.guide have no shared brand-token file. apps/deals (Vite/React) and src/ (Next.js) almost certainly drift on color, typography, spacing. A "screenshot-and-forward" PDF that visually conflicts with the live demo screams amateur. swarm-upgrade signal: propose brand-tokens.json as shared source-of-truth, consumed by Tailwind config in both apps. No public-facing demo-completion telemetry exists today. /buyside-hunt and /hunter likely have zero analytics on demo-completion vs. abandon. This run will force the first build of that telemetry. which then becomes useful for every future outbound campaign. swarm-upgrade signal: standardize a demo_session_events table + tracking helper across all public demos. (Possible 4th) writer + draper have no shared voice/tone doc for first-person Ewing copy. "Operator-to-operator" voice is distinct from CIM voice. Without a shared anchor, the two will produce subtly different Ewings.
4. Notebook entry preview. draft "Why this matters" (plain-speak) (This is the prose I'd write at Phase 6 based on the assignment alone. Will revise once peer S5s arrive.) Ewing needed a 3-page PDF that midmarket business owners. people who built something real over 20 years. would actually read and forward. Not a brochure. Not a pitch deck. An operator talking to operators, with proof on Page 3 that the tools in the deck are real and running, not vaporware. The swarm built this as one artifact with a working live demo embedded as the last page, so a reader can stop reading the words and start using the thing. The win condition isn't opens or impressions. it's whether 5 of the 50 owners reply or book a call. Everything in the PDF, every URL, every UTM, every word of Page 1, exists to push toward that single number.
5. Predicted agent currency events this run
draper → writer (3x, base 5): draper supplies the visual mood-board + page grid first, which lets writer cut throat-clearing copy because the visuals carry the "we're operators, not consultants" tone. Saves writer one full revision round. architect → writer + draper (3x, base 5): architect drops the UTM + tracking-link scheme into Supabase before content is finalized, so writer and draper embed final URLs the first time instead of stubbing TBD links and revising. market-analyst → hunter (3x, base 5): market-analyst defines the "midmarket owner" segment with EBITDA/vertical bands first, so hunter's recipient-list pull is one query instead of three. (Possible 4th) listener → quarterback (5x, base 5): listener pre-builds the reply-classification flow before send, so when replies start landing quarterback isn't triaging cold. unblocks the revenue moment.
Run 017's success cannot be measured by traditional email metrics; it must be instrumented around three trackable proxies (demo-URL hit, demo-completion, reply-or-book) before send, with per-recipient UTM tokens and a Supabase-backed event store. The mission's real payload is Page 3. the live demo. and Pages 1-2 exist to earn the click. Without pre-send instrumentation, the run produces an artifact with no learning loop and no Phase 6 signal beyond peer S5 prose.
I could not read skills/debrief/SKILL.md directly during Phase 1 (permission denied), so my persona contract is reconstructed from the maxswarm skill registry and the assignment itself. There is a non-zero chance debrief has a Phase 1 protocol detail I'm missing. for example, a specific recent_runs.json regenerator hook I'm supposed to pre-stage. I also cannot verify whether prior runs (014-016) shipped any "outbound campaign" artifact that already established a UTM convention I should reuse instead of inventing one. If such a convention exists, my ?utm_campaign=founders50 shape may collide.
This run rhymes with run #008 (debrief was active, dual-layer plain-speak + technical) and run #010 (writer + storyteller co-produced a client-facing artifact). Like run #007-010, the work is a single deliverable that touches writer, draper, and architect simultaneously. the recurring pattern is that brand/voice/visual coherence across writer-draper-architect requires a pre-send token contract or it drifts. No prior run, to my knowledge, has shipped a hosted-live-demo embedded in a static PDF. that part is novel for run #017.
Going forward, on any artifact-shipping run I will publish a 3-metric instrumentation contract during Phase 1 so peer agents embed final tracked URLs on their first draft instead of stubbing TBDs. eliminates an entire revision round across writer/draper/architect.
Generated from 017__debrief.md — do not edit this HTML directly.