# Sprint Marketing Plan Builder > Turns a completed (or partially completed) Marketing Strategy Sprint into a written marketing plan document the client keeps — a Square-by-square (TREC) record of decisions, consolidated objectives, a time-bound Strategy Activation Plan (dated goal cascade with checklist tactics), open decisions, and next steps, delivered as a polished PDF. Use when someone wants a marketing plan document, strategy document, or activation plan written up from a sprint; trigger on "write up the marketing plan", "turn this sprint into a plan doc", "build the strategy activation plan", "document what we decided", "marketing plan for [client]", or similar, even if "sprint" isn't said explicitly but Square/TREC decisions clearly need documenting. Do NOT trigger for the slide deck version — use sprint-deck-outline-builder for that instead (same source material, different artifact). Do NOT trigger for live facilitation of any Square. - Skill: `chadjardine/sprint-marketing-plan-builder` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add chadjardine/sprint-marketing-plan-builder` - Raw SKILL.md: https://api.skillmd.com/api/skills/chadjardine/sprint-marketing-plan-builder/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: chadjardine (https://skillmd.com/u/chadjardine) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/chadjardine/sprint-marketing-plan-builder --- # Sprint Marketing Plan Builder ## Purpose This is the document the client keeps and refers back to — as opposed to sprint-deck-outline-builder, which produces a slide deck for walking the client through the same material live. The two are commonly requested together from the same source material, and should stay consistent with each other (see Inputs below), but this skill owns the canonical written record: what was decided Square by Square, the objectives that fall out of those decisions, a time-bound activation plan for executing on them, what's still unresolved, and what happens next. This is not a facilitation skill and it doesn't run a session. It assembles a document from work that's already done. If a Square wasn't run or a decision wasn't made, this document's job is to say so — not to quietly invent professional-looking content that papers over the gap. A polished document that misrepresents what was actually decided is worse than an honest one with visible gaps — it tells the client something was decided when it wasn't, in a document they'll reference for months. ## Core Rule Every substantive claim in this document — every goal, date, number, decision, or tactic — must trace to a specific input: a stored Square skill output, or something identifiable in the source sprint notes/transcript. Where the source is silent, say so explicitly ("timing not specified," "not yet addressed this sprint") rather than filling the gap with generic, plausible-sounding content. This applies with equal force to the Strategy Activation Plan section (see `references/strategy-activation-plan-format.md`) — a dated Key Result or a checklist tactic is just as much a factual claim as a paragraph of prose, and needs the same grounding. ## Inputs Source material is the same as sprint-deck-outline-builder: stored Square skill outputs, raw sprint notes/transcripts, or both. This skill is the canonical extraction — when both this document and the deck are being built from the same sprint in the same session, build this one first and let sprint-deck-outline-builder reuse its Marketing Objectives, Implementation/Activation Plan, and Open Decisions content rather than each skill re-deriving its own version and risking drift (e.g. one calling a decision "aligned" while the other calls it "open" because each independently re-read the transcript slightly differently). If this document doesn't exist yet in the session, this skill derives everything itself from the raw source — it never waits on or depends on the deck skill. If it's unclear which source material or which client's sprint this is, confirm before building. ## Handling Raw Source Material Sprint chapters typically break into a Summary, a Decisions block (Aligned / Needs Further Discussion / Disagreements / Shelved — varies by sprint), Next steps, and a timestamped Details section, followed by a full transcript. Read Decisions → Details → Next steps first; use the transcript only to verify or resolve ambiguity. Map decisions to Squares by substance, not by looking for the word "Square" — it won't appear in most transcripts. Use this rubric: | What was actually discussed | Square | |---|---| | Growth goals, budget, targets, CAC/LTV math | Zero Square | | Who the customer is, persona, ICP | Square 1 | | Positioning, pain points, key messages, brand voice | Square 2 | | Where to reach them, channel budget/ranking | Square 3 | | Lead magnets, opt-in offers, capture pages/forms | Square 4 | | Email/follow-up sequences, retargeting after opt-in | Square 5 | | Pricing, packaging, the sales process, close criteria | Square 6 | | Onboarding, unboxing, first-use experience | Square 7 | | Repeat usage, upsells, loyalty/gamification | Square 8 | | Referral incentives, case studies, advocacy | Square 9 | Preserve each decision's status exactly as sourced — an "aligned" item and one still "needs further discussion" should never read the same in the document. The dedicated Open Decisions section exists precisely so unresolved items are visible in one place rather than buried inside Square write-ups that otherwise read as settled. ## Handling Stored Square Skill Outputs When the input is stored output from actually running sprint-square-one through sprint-square-nine (rather than a raw transcript), it looks nothing like the Decisions/Details/transcript shape above — it's already a structured write-up (persona cards, message tables, positioning statements) produced by that Square's own facilitation flow. A few things are specific to this input type: - **There's no Aligned/Needs Discussion/Disagreement markup to key off of.** Square outputs represent what the facilitation session actually landed on — treat everything in a Square's stored output as settled/aligned unless the output itself explicitly flags something as unresolved. Don't invent an "open" status for something just because it wasn't phrased as a decision. - **A single Square can arrive as several artifacts, not one.** Square 2 in particular orchestrates multiple sub-skills (problem-usp-builder, brand-positioning-statement, brand-voice-builder) that each produce their own output alongside Square 2's own Key Messages and positioning work. Treat all of a Square's artifacts as one logical unit for that Square's section in this document — don't split one Square across multiple document sections, and don't feel obligated to preserve each sub-artifact's original formatting verbatim; synthesize them into the connective prose described earlier in this file. - **The Square-mapping rubric table above is for unlabeled transcripts.** Stored Square outputs already say which Square they're from — you don't need to map by substance here, just use the label. ## Handling Squares That Weren't Run Not every sprint covers all ten Squares (Zero through 9) in one sitting, and this document needs to represent that honestly rather than pretending otherwise. For every Square (including the Zero Square) that wasn't actually run: - **Determine its position.** Find the highest-numbered Square that was actually run. A Square with nothing run after it is a **trailing gap** — the engagement just hasn't gotten there yet. A Square with at least one later Square that *was* run is a **mid-sequence gap** — it was actively passed over. - **Both trailing and mid-sequence gaps now get their own explicitly labeled subsection** ("Not yet addressed this sprint") in the same place that Square's write-up would otherwise sit, styled with the yellow flag treatment described below. This replaces any prior instinct to fold trailing gaps quietly into the Journey/Summary framing or omit them from the Square-by-square section — don't do that anymore; every Square gets a visible entry now, run or not. - **Word the two kinds differently even though both are now visible and both get the same yellow styling:** a trailing gap reads as "not yet reached" (e.g. "Not yet addressed this sprint — scheduled for a future session"); a mid-sequence gap reads as actively deferred (e.g. "Not yet addressed this sprint — deferred from the original agenda"). - **Never combine a mid-sequence gap and a trailing gap into one write-up** — they mean different things to the client reading this later, and conflating them either overstates the trailing gap as a deliberate omission or undersells the mid-sequence one as routine. (This is the same gap-classification logic sprint-deck-outline-builder uses for its slides — keeping the language identical between the two skills is deliberate, so a Square's treatment doesn't quietly diverge between the document and the deck.) ## Flagging Any "Not Enough Information" Moment (Yellow Flag) This is a blanket rule, not something scoped only to Square sections: **anywhere in the document** where the source material doesn't have enough to state something as a confirmed fact — a whole section, a single sentence, a missing date, an unscored metric, a budget figure that was never resolved — that spot gets visually flagged yellow so the CMO can scan the document and immediately see every place that needs their attention before it goes to the client. Don't rely on the wording alone ("timing not specified," "not yet addressed") to carry that signal — the CMO should be able to spot every gap at a glance without reading every line. **Where this shows up, beyond the Square sections themselves:** 1. **Every unaddressed Square subsection** — both trailing and mid-sequence gaps, per Handling Squares That Weren't Run above. No exceptions; every Square that wasn't run gets a visible, yellow-flagged subsection now, not a one-line mention or a silent omission. 2. **Any addressed Square that's thin on material** — the Square was actually run/discussed, but there wasn't enough in the source to complete its framework (e.g. persona documented but no PVP Index score, a Brand Positioning Statement missing a component, a Zero Square with a revenue goal but no CAC/LTV numbers). Write up the real content normally, but flag the specific missing piece. 3. **Marketing Objectives** — any target/metric that's directional or partially defined rather than a clean, sourced number gets its own yellow callout rather than sitting styled identically next to fully-confirmed objectives. 4. **Strategy Activation Plan** — any Key Result or tactic with unspecified timing, an unassigned owner, or any other missing planning detail gets a yellow callout, not just an invented date or a plain italic caveat. 5. **Open Decisions** — this section is inherently about unresolved items, but where the source is especially thin on what the actual disagreement or open question even is (rather than just "not yet decided"), flag that specific item so the CMO knows it needs more digging before the client meeting, not just a decision. 6. **The Executive Summary and The Sprint narrative** — if the source doesn't describe the client's before-state, or what got covered vs. deferred, in enough detail to state confidently, flag it yellow rather than writing something vague-but-confident-sounding. **Visual treatment:** a shaded callout box (implemented as a single-cell shaded table or a shaded paragraph background, same mechanism the document already uses for navy/blue callouts) filled with warm yellow — `#FFF3CD` fill, `#F0B429` left border/accent bar, near-black (`#0A0A0A`) text. This is a deliberate, intentional exception to the "no secondary accent color" rule in `references/house-design-system.md` — yellow is reserved exclusively for flagging gaps and thin content, and should never be used decoratively or for anything else in the document, so it stays instantly recognizable as a "needs attention" signal. This yellow is Claude's own addition, not part of the house design system itself — never let it bleed into other sections' styling. - For a full unaddressed-Square subsection: the entire subsection sits inside the yellow box, with its one or two honest sentences (per the wording guidance above) — don't pad it with invented content just because it's now a visible, styled block. - For a thin-but-addressed Square, or a thin item elsewhere in the document (an Objective, a Key Result, an Open Decision): keep the real content in its normal styling, and flag only the specific missing item in its own small yellow callout (e.g. "PVP Index — not scored this sprint") placed where that piece would otherwise sit. - The Core Rule still governs completely regardless of styling: no invented substance, ever — the flag communicates the gap, it doesn't fill it. ## This Is a Different Reading Experience Than the Deck, Not the Same Content Reflowed The deck exists to be presented out loud in a room — it has to compress every Square down to 2-4 bullets a viewer can read in a few seconds. This document exists to be read on its own, later, by someone who wasn't in the room. If a Square's write-up here just restates the deck's bullet fragments with periods added, the document has failed at its actual job: it should read as connected prose with the texture a bullet can't hold — the reasoning behind a decision, a relevant quote from the transcript, how one decision affects another. Write full sentences and short paragraphs, not bullet lists dressed up as paragraphs. A useful test: if you could hand someone the deck's slide for a Square and this document's section for the same Square, and they read as the same three facts in two formats, the document section needs more — not necessarily more facts, but more connective explanation of the facts you have. This also matters for length and pacing (see Output Format below): a document built from genuine prose naturally fills a page without needing artificial whitespace or a forced page break after every heading. ## Document Structure Produce the document in this order. Don't force a page break before every item on this list — only before the genuinely major parts (Executive Summary, Zero Square/start of the Square-by-square body, Strategy Activation Plan, Open Decisions). Squares 1-9 should flow as continuous headed sections, not one Square per page; a Square with three sentences of real content doesn't need a page to itself, and forcing one is what makes a modest sprint balloon into a document that reads far longer than what's actually in it. 1. **Cover page** — document title, client name, date, prepared-by line. 2. **Executive summary** — a few sentences: where the client stands today, what this sprint covered, and the shape of the plan that follows. Keep it short; it's a preview, not a recap of everything below. 3. **The Sprint** — a brief narrative of what actually happened (dates, format, who was involved, and — same as the deck's Journey slides — an honest account of what got covered and what got deferred, and why, if that's known). 4. **Zero Square** — the growth goal and unit economics if this Square was run, or a yellow-flagged "not yet addressed" subsection if not (see Handling Squares That Weren't Run and the Yellow Flag rules above). State the marketing budget ceiling/implied spend in the client's own terms; if a specific agency retainer/fee figure was resolved during the sprint, that's a fact for the Strategy Activation Plan or a closing section, not this one — see the note on this in sprint-deck-outline-builder, which follows the same sequencing logic for its own Zero Square slide. 5. **One section per Square, 1 through 9, no exceptions now** — each one either covering what was aligned, what's still open (cross-reference rather than duplicate — see Open Decisions), and what was explicitly shelved, or, if the Square wasn't run, its yellow-flagged subsection per the rules above. Apply the trailing/mid-sequence wording distinction either way. Optionally, a compact Before/During/After 3x3 summary grid (Before = Squares 1-3, During = Squares 4-6, After = Squares 7-9 — see `references/house-design-system.md` for this layout) can accompany this section as an at-a-glance overview, with any unrun or thin cell also carrying the yellow flag. 6. **Marketing Objectives** — the measurable targets actually stated across Squares, consolidated in one place. This is the section sprint-deck-outline-builder's Objectives slide should reuse verbatim when both are being built together. Flag any directional/partially-defined target per the yellow flag rules above. 7. **Strategy Activation Plan** — the time-bound goal cascade described in `references/strategy-activation-plan-format.md`. Read that file before writing this section; it's a distinctly different format (dense, checklist-driven) from the narrative sections above it, and covers the same ground the deck calls its "Implementation Plan" slide but in much more actionable detail — this section is the canonical version the deck should summarize down from, not the other way around. Flag any tactic or Key Result with unspecified timing, an unassigned owner, or any other missing planning detail using the same yellow treatment rather than an invented date. 8. **Open Decisions** — every item flagged "needs further discussion" or "disagreement" anywhere in the document, consolidated in one place, so the client can see at a glance what still needs a decision before execution can fully proceed. Flag any item where even the nature of the open question is unclear from source. 9. **Next Steps** — concrete, owned, dated where possible. ## Output Format Read `references/house-design-system.md` before building — it's the default visual style (colors, fonts, table/callout patterns) for this document, built from the same system used for the sprint deck, so the two deliverables read as a matched pair. Specifics worth holding onto from that reference: Primary Blue (`#2E6FB7`) is the dominant accent throughout, not navy (navy is a rare, sparing highlight); flat borderless light-gray card blocks (`#EFEFEF`) are the default content-grouping treatment rather than bordered cards; cover-page titles use heavy Montserrat rather than the serif (Libre Baskerville is reserved for in-page section headings); and a compact Before/During/After 3x3 grid maps directly to Squares 1-9. Layer the yellow flag rules above on top of whichever palette is used, as the one deliberate exception. If the client has their own brand guide, that overrides everything except the yellow flag convention, which stays regardless since it's a gap-visibility signal rather than a brand element. **Length is a signal, not a target.** For a typical one- or two-day sprint covering a handful of Squares, expect something in the neighborhood of 4-8 pages once rendered — not 12+. If a draft is running much longer than that, it's almost always because sections got a forced page break they didn't need (see Document Structure) or because the Square write-ups are padded restatement rather than the tighter, connective prose described above — not because the sprint genuinely produced that much material. Check both before assuming the content itself demands the length. The deliverable is a finished PDF, not a text draft handed back in the chat and not a Google Doc. This client isn't expected to edit it — a locked, presentation-ready file that looks exactly as designed on any device beats an editable one with degraded formatting. (An earlier version of this skill delivered via a hosted HTML-to-online-document upload; that path is deliberately not used anymore — online document models don't support the tight, poster-like layout the Strategy Activation Plan section needs, and their converters silently flatten it. PDF avoids that entirely by rendering exactly what was designed.) 1. Build the document as a polished `.docx` first — consult the docx skill for the actual document-building mechanics (headings, tables, shaded navy/blue/yellow callout boxes, checkboxes for the Activation Plan tactics, header/footer, page numbers, the embedded logo). Because this is a local build rather than something inlined into a single upload tool call, there's no token-budget pressure here — embed the real logo image (whatever you've supplied in `assets/`) and use the full house styling without the workarounds an earlier version of this skill needed for the hosted-document path. 2. Convert the finished `.docx` to PDF (e.g. via the docx skill's own export step, or a local conversion tool) and treat the PDF as the actual deliverable — the `.docx` is a working intermediate, not something to hand to the client. 3. Do the required visual QA on the rendered PDF, not just the source: render pages to images and check every page for overflow, cut-off text, or broken tables — especially the Strategy Activation Plan page, which is the densest page in the document and the one most likely to clip if a box runs long. Also confirm every unaddressed or thin item — Square-level or otherwise — actually shows its yellow flag, and that yellow doesn't appear anywhere it shouldn't. 4. Name the file after the client: `{Client Name} Marketing Plan.pdf`. 5. Deliver the PDF file directly — no upload step, no link to confirm. ## Process 1. Confirm source and scope — which source material, which Squares were actually run, and whether this is the first extraction for this sprint or a rebuild. 2. Draft section by section, in the Document Structure order above, now including a section for every Square whether run or not. Don't jump between sections — it's easy to lose track of which Squares still need a write-up and which open items have already been captured if you bounce around. 3. QA pass before building the file: does every claim (including every Key Result and tactic in the Activation Plan) trace to source; does every open or contested item get flagged as open rather than presented as resolved; does every unrun Square get the correct trailing/mid-sequence wording; and — the broadest check — scan every section (not just Square sections) for any sentence, date, number, or claim that isn't fully sourced, and confirm each one carries the yellow flag rather than reading as confidently stated. 4. Build the document per Output Format (`.docx` build → PDF export). ## Non-negotiables - Never write a Square's section from a generic template — every section must reflect what THIS client's sprint actually decided, not a stock description of what that Square usually covers. - Never invent a goal, date, number, decision, or Activation Plan tactic without a source. - Give every unaddressed Square — trailing or mid-sequence — its own explicit, yellow-flagged subsection. Never omit a Square silently anymore, and never merge the two gap kinds into one write-up. - Flag **any** "not enough information" moment anywhere in the document with the same yellow treatment — not just Square sections. This explicitly includes Marketing Objectives, the Strategy Activation Plan, Open Decisions, and the Executive Summary/Sprint narrative, scoped to just the specific sentence/callout that's thin rather than the whole section if the rest is genuinely complete. - Reserve yellow exclusively for this flagging purpose — never use it decoratively or for anything else in the document. - If a same-session sprint-deck-outline-builder extraction already exists, this skill still derives its own canonical version first (this skill is the source of truth); if there's a risk of the two disagreeing, this document's version wins. - Deliver as a finished PDF, not chat text and not a Google Doc, unless the user explicitly asks for a text draft or an editable file instead.