Sprint Deliverables Builder
Purpose
A Fractional CMO ran a Marketing Strategy Sprint live with their client — in person, over a call, however — outside of Claude entirely. What lands in this conversation afterward is the record of that session: a transcript, Gemini/Otter notes, or similar. This skill's job is to turn that single input into the two deliverables the CMO sends the client: the written Marketing Plan document and the recap slide deck — built together, in the right order, so they never quietly disagree with each other.
This skill does no facilitation and makes no judgment calls of its own about what was decided — that's entirely the job of the two skills it calls. It exists purely to remove the manual step of invoking them separately and making sure the second one reuses the first one's extraction instead of re-deriving its own version of the same facts.
Why Order Matters
sprint-marketing-plan-builder and sprint-deck-outline-builder can each work standalone from a raw transcript — that's how they were each built and tested. But when both are wanted from the same transcript in the same sitting, running them independently risks drift: each one re-reads the transcript on its own, and two independent readings of "was the warranty bundling decision aligned or still open" can come back with subtly different phrasing or, worse, a different status. Both skills already anticipate this and say to reuse a same-session extraction when one exists — this skill's whole job is to make sure that's what actually happens, every time, without relying on remembering to ask for it that way.
Use Each Square's Own Skill as the Structuring Framework, Even Though Nothing Is Facilitated Live
This is the part that makes this more than a thin wrapper. The transcript is a record of a live conversation — it wasn't run through sprint-square-one through sprint-square-nine as a live facilitation, so nothing about it is pre-organized into those skills' actual frameworks (the PVP Index and five-ring persona from Square 1, Key Messages/STP/5-Ps/Dunford/Brand Positioning Statement/Brand Tone of Voice from Square 2, the OEP/Hunting-vs-Farming/Watering Hole model from Square 3, and so on). Left alone, sprint-marketing-plan-builder's generic transcript-reading rubric will map content to the right Square but not necessarily organize it using that Square's actual model — it'll produce competent prose, not the same rigor a live-facilitated session would have.
So: for every Square the transcript actually covers, before writing that Square's section, read that Square's own skill file (sprint-square-N) and whatever sub-skills it orchestrates (e.g. Square 2 → problem-usp-builder, brand-positioning-statement, brand-voice-builder; Square 3 → watering-hole-analysis; Square 4 → lead-magnet-builder, landing-page-builder; Square 6 → offer-packaging-builder, sales-conversion-playbook-builder; Square 7 → onboarding-experience-builder; Square 8 → ltv-expansion-builder; Square 9 → referral-program-builder). Use that Square's specific framework and terminology as the structure for organizing whatever the transcript reveals — e.g. write Square 1's section around the five-ring persona structure and note a PVP Index score if the transcript's content supports one, rather than a generic "here's the persona" paragraph.
The Core Rule from both underlying skills still governs completely: if the transcript doesn't contain enough to fill in a piece of a framework (say, the transcript never actually scored a PVP Index, or Square 2's Brand Positioning Statement components weren't all explicitly discussed), say so plainly rather than inventing content just to complete the framework's shape. The frameworks are a lens for organizing what's really there, never a template to pad out.
Process
- Confirm inputs. The transcript/notes file(s) and the client name. If it's unclear which file or which client's sprint this is, ask before proceeding — same standard as the two underlying skills.
- Identify which Squares the transcript actually covers, then read each of those Squares' own skill files (and sub-skills) per the section above, before writing anything — this is what makes the eventual document and deck read like they came from a rigorous facilitated sprint rather than a transcript summary.
- Build the Marketing Plan document first, by invoking the sprint-marketing-plan-builder skill against the transcript, applying the Square-specific frameworks from step 2 to each section. This is the canonical extraction: Square-by-square decisions, Marketing Objectives, the Strategy Activation Plan, and Open Decisions all get derived here first, per that skill's own Document Structure and Core Rule. "Built" means that skill's entire Output Format section is complete — the
.docx built, converted to PDF, and QA'd — not just having the drafted content ready. A long orchestration with a lot of Square-framework reading in front of it is exactly when it's easy to lose track and skip the final export/QA step; don't move to step 4 until you can point to an actual finished PDF file.
- Build the deck second, by invoking the sprint-deck-outline-builder skill against the same transcript (with the same Square-specific framing from step 2 for its Square slides), explicitly telling it that a sprint-marketing-plan-builder extraction already exists in this session and where to find it (the document just built in step 3). Per that skill's own Inputs section, it should reuse the Objectives, Activation/Implementation Plan, and Open Decisions content from that document rather than re-deriving its own version. Confirm it actually did this rather than silently re-parsing the transcript from scratch for those sections — see QA below.
- QA pass — consistency, not just correctness. Before handing anything back, check that the numbers and statuses that appear in both deliverables actually match: the same revenue/CAC figures in the deck's Objectives slide as the doc's Marketing Objectives section, the same Key Results and dates in the deck's Activation/Implementation slide as the doc's Strategy Activation Plan, and the same items — with the same aligned/open/disagreement status — on both Open Decisions treatments. If anything doesn't match, fix it by re-deriving the deck's version from the document rather than picking one at random; this consistency check is the entire reason this skill exists, so don't skip it.
- Hand back both deliverables together, clearly labeled, as one package: the marketing plan PDF and the
.pptx deck. Briefly summarize what's in them (which Squares were covered, what's still open) so the CMO can sanity-check before forwarding to their client — don't just drop two files with no context.
Non-negotiables
- Always read each covered Square's own skill (and sub-skills) before writing that Square's content — don't fall back to generic transcript paraphrasing when a real framework exists to structure it. Never stretch the transcript to fill in a framework element that isn't actually there.
- Always build the plan document before the deck, never the reverse and never in parallel — the deck depends on the document's extraction existing.
- Never let the deck silently re-derive its own Objectives/Activation Plan/Open Decisions when a same-session document extraction exists — that defeats the purpose of this skill.
- Always run the consistency QA pass in step 4 before delivering — two deliverables that individually look right but quietly disagree with each other are worse than either skill's own honesty standard, because now the client is looking at two different numbers for the same thing.
- If either underlying skill can't complete (missing source material, ambiguous client, upload failure), stop and surface that clearly rather than delivering a partial or inconsistent package.
1---2name: sprint-deliverables-builder3description: One-shot client wrap-up package for a Marketing Strategy Sprint run outside Claude (in person or on a call, notes from Gemini/Otter/manual notes) — takes a transcript/notes upload and produces BOTH the written marketing plan (PDF) and the recap slide deck (.pptx), built consistently from one extraction, for a Fractional CMO to send their client. Trigger on "build the deck and the plan doc from this transcript", "package up the sprint deliverables", "give me everything for [client]'s wrap-up", "turn these sprint notes into the deck and marketing plan", "send the client their recap", or similar, especially when a transcript/notes file is uploaded and more than one deliverable is wanted. Do NOT trigger if only one deliverable is wanted — use sprint-deck-outline-builder or sprint-marketing-plan-builder alone. Do NOT trigger for live facilitation — the sprint already happened outside this conversation.4---56# Sprint Deliverables Builder78## Purpose910A Fractional CMO ran a Marketing Strategy Sprint live with their client — in person, over a call, however — outside of Claude entirely. What lands in this conversation afterward is the record of that session: a transcript, Gemini/Otter notes, or similar. This skill's job is to turn that single input into the two deliverables the CMO sends the client: the written Marketing Plan document and the recap slide deck — built together, in the right order, so they never quietly disagree with each other.1112This skill does no facilitation and makes no judgment calls of its own about what was decided — that's entirely the job of the two skills it calls. It exists purely to remove the manual step of invoking them separately and making sure the second one reuses the first one's extraction instead of re-deriving its own version of the same facts.1314## Why Order Matters1516sprint-marketing-plan-builder and sprint-deck-outline-builder can each work standalone from a raw transcript — that's how they were each built and tested. But when both are wanted from the same transcript in the same sitting, running them independently risks drift: each one re-reads the transcript on its own, and two independent readings of "was the warranty bundling decision aligned or still open" can come back with subtly different phrasing or, worse, a different status. Both skills already anticipate this and say to reuse a same-session extraction when one exists — this skill's whole job is to make sure that's what actually happens, every time, without relying on remembering to ask for it that way.1718## Use Each Square's Own Skill as the Structuring Framework, Even Though Nothing Is Facilitated Live1920This is the part that makes this more than a thin wrapper. The transcript is a record of a live conversation — it wasn't run through sprint-square-one through sprint-square-nine as a live facilitation, so nothing about it is pre-organized into those skills' actual frameworks (the PVP Index and five-ring persona from Square 1, Key Messages/STP/5-Ps/Dunford/Brand Positioning Statement/Brand Tone of Voice from Square 2, the OEP/Hunting-vs-Farming/Watering Hole model from Square 3, and so on). Left alone, sprint-marketing-plan-builder's generic transcript-reading rubric will map content to the *right Square* but not necessarily organize it using *that Square's actual model* — it'll produce competent prose, not the same rigor a live-facilitated session would have.2122So: for every Square the transcript actually covers, before writing that Square's section, read that Square's own skill file (sprint-square-N) and whatever sub-skills it orchestrates (e.g. Square 2 → problem-usp-builder, brand-positioning-statement, brand-voice-builder; Square 3 → watering-hole-analysis; Square 4 → lead-magnet-builder, landing-page-builder; Square 6 → offer-packaging-builder, sales-conversion-playbook-builder; Square 7 → onboarding-experience-builder; Square 8 → ltv-expansion-builder; Square 9 → referral-program-builder). Use that Square's specific framework and terminology as the structure for organizing whatever the transcript reveals — e.g. write Square 1's section around the five-ring persona structure and note a PVP Index score if the transcript's content supports one, rather than a generic "here's the persona" paragraph.2324The Core Rule from both underlying skills still governs completely: if the transcript doesn't contain enough to fill in a piece of a framework (say, the transcript never actually scored a PVP Index, or Square 2's Brand Positioning Statement components weren't all explicitly discussed), say so plainly rather than inventing content just to complete the framework's shape. The frameworks are a lens for organizing what's really there, never a template to pad out.2526## Process27281. **Confirm inputs.** The transcript/notes file(s) and the client name. If it's unclear which file or which client's sprint this is, ask before proceeding — same standard as the two underlying skills.292. **Identify which Squares the transcript actually covers**, then read each of those Squares' own skill files (and sub-skills) per the section above, before writing anything — this is what makes the eventual document and deck read like they came from a rigorous facilitated sprint rather than a transcript summary.303. **Build the Marketing Plan document first**, by invoking the sprint-marketing-plan-builder skill against the transcript, applying the Square-specific frameworks from step 2 to each section. This is the canonical extraction: Square-by-square decisions, Marketing Objectives, the Strategy Activation Plan, and Open Decisions all get derived here first, per that skill's own Document Structure and Core Rule. "Built" means that skill's *entire* Output Format section is complete — the `.docx` built, converted to PDF, and QA'd — not just having the drafted content ready. A long orchestration with a lot of Square-framework reading in front of it is exactly when it's easy to lose track and skip the final export/QA step; don't move to step 4 until you can point to an actual finished PDF file.314. **Build the deck second**, by invoking the sprint-deck-outline-builder skill against the same transcript (with the same Square-specific framing from step 2 for its Square slides), explicitly telling it that a sprint-marketing-plan-builder extraction already exists in this session and where to find it (the document just built in step 3). Per that skill's own Inputs section, it should reuse the Objectives, Activation/Implementation Plan, and Open Decisions content from that document rather than re-deriving its own version. Confirm it actually did this rather than silently re-parsing the transcript from scratch for those sections — see QA below.325. **QA pass — consistency, not just correctness.** Before handing anything back, check that the numbers and statuses that appear in both deliverables actually match: the same revenue/CAC figures in the deck's Objectives slide as the doc's Marketing Objectives section, the same Key Results and dates in the deck's Activation/Implementation slide as the doc's Strategy Activation Plan, and the same items — with the same aligned/open/disagreement status — on both Open Decisions treatments. If anything doesn't match, fix it by re-deriving the deck's version from the document rather than picking one at random; this consistency check is the entire reason this skill exists, so don't skip it.336. **Hand back both deliverables together**, clearly labeled, as one package: the marketing plan PDF and the `.pptx` deck. Briefly summarize what's in them (which Squares were covered, what's still open) so the CMO can sanity-check before forwarding to their client — don't just drop two files with no context.3435## Non-negotiables3637- Always read each covered Square's own skill (and sub-skills) before writing that Square's content — don't fall back to generic transcript paraphrasing when a real framework exists to structure it. Never stretch the transcript to fill in a framework element that isn't actually there.38- Always build the plan document before the deck, never the reverse and never in parallel — the deck depends on the document's extraction existing.39- Never let the deck silently re-derive its own Objectives/Activation Plan/Open Decisions when a same-session document extraction exists — that defeats the purpose of this skill.40- Always run the consistency QA pass in step 4 before delivering — two deliverables that individually look right but quietly disagree with each other are worse than either skill's own honesty standard, because now the client is looking at two different numbers for the same thing.41- If either underlying skill can't complete (missing source material, ambiguous client, upload failure), stop and surface that clearly rather than delivering a partial or inconsistent package.
chadjardine