Full SKILL.md

Storyboard

Build the storyline spine for a presentation before any slides or HTML exist — the governing thought, the MECE key line of section arguments, and a slide-by-slide plan of action titles, ghost exhibits, and supporting evidence, with vertical and horizontal coherence checks (Minto pyramid). Use whenever the user is planning a deck, storyboarding, structuring findings into an argument, deciding what slides they need, sequencing a presentation, or asks to organize analysis into a story before building pages — even if they don't say "storyboard" or "pyramid". Produces a reviewable spine to sign off before drafting; it does not build the slides.

Produce the storyline spine: the slide-by-slide plan of a deck's argument, drafted and checked before any HTML or slides are built. The spine is a gate, not an automation step — its value is forcing a sign-off on the argument while changing it is still cheap. Re-storyboarding costs minutes; rebuilding pages costs hours.

This skill plans; it does not build. The output is a reviewable table the user approves before anyone writes a page.

Where this sits

Pipeline: engagement thinking → storyboard (here) → optional title pass → exhibits → expand to HTML → convert to deck → QA.

  • Upstream, if a product-strategy skill is available, use its deck-architecture section for the section skeleton and its exhibit library for ghost-exhibit vocabulary. If not, work from whatever findings the user provides.
  • Downstream, the spine feeds the HTML draft and the deck converter. Each row becomes a slide.

The spine (the output)

One row per slide. This is the artifact the user signs off and downstream steps consume.

  • Action title — a complete so-what sentence stating what the slide proves. Draft to the action-titles standard (verb-led, quantified where the evidence allows, one message, two lines max).
  • Ghost exhibit — the single visual that proves the title. Name the chart type and what it shows, not "a chart". If product-strategy is available, name the exhibit from its library.
  • Supporting points — the evidence that will fill the body. Enough that the HTML step can write the slide without re-deriving the argument.
  • Type — cover / section divider / content / statement / closing. Maps to deck-template archetypes downstream.

Below the table, output: (a) the governing thought in one line, (b) a per-section ladder line confirming the section's titles sum to its argument, and (c) a flags list of anything that doesn't hold.

Workflow

0. Gather inputs and the core question

Collect the findings, any section skeleton, and — critically — the client's core question (the decision this deck must answer). If the core question isn't explicit, infer a candidate and confirm it. Everything ladders up to answering it.

1. Fix the governing thought

The governing thought is the single sentence that answers the core question — the one thing the audience must leave with. Frame the setup with SCQA (Situation → Complication → Question → Answer); the Answer is the governing thought. If the findings support more than one defensible answer, present 2–3 candidate governing thoughts with their implications and ask which to build on rather than picking silently. Never invent a conclusion the evidence doesn't support.

2. Build the key line

The key line is the set of section-level arguments that, taken together, prove the governing thought. Rules:

  • 3–5 sections. More than 5 means the grouping isn't tight; regroup.
  • MECE — sections don't overlap and together cover the question. Test both directions: is anything double-counted, is anything missing.
  • Each section argument is itself a so-what sentence, not a topic label ("Why the mid-market wins", not "Market analysis").
  • Choose inductive grouping (parallel reasons that sum to the point) or deductive flow (situation → problem → therefore) per section; see references/pyramid-and-examples.md.

3. Lay out slides per section

For each section, the slides whose titles sequence into the section's argument. For each slide draft the action title, name the ghost exhibit, and list supporting points. Add divider slides between sections and a closing/next-steps slide. Keep content slides to one message each — if a title needs "and", split it.

4. Run the coherence checks

  • Vertical — does each slide's content actually prove its title? If the title claims more than the exhibit shows, weaken the title or strengthen the evidence.
  • Horizontal — read the action titles top to bottom with nothing else. Do they tell the whole story on their own, and do the titles within a section sum to the section argument, and the sections to the governing thought? This is the test of a real storyline.
  • MECE — re-check the key line for overlap and gaps.
  • Opening and close — the first content slide should land the SCQA framing; the deck should end on the decision/next steps, not trail off.

5. Output and recommend the next step

Emit the spine table, the governing thought, the ladder summary, and the flags. Then state the recommended next action: sign off, then (if available) run action-titles across the spine for the horizontal pass, build the ghost exhibits, and expand to HTML for the converter.

Integration with other skills

  • action-titles — storyboard drafts titles to that standard for the vertical logic (each title proves its slide). After sign-off, running action-titles checks the horizontal logic (the titles as one connected narrative) and tightens weak ones. If action-titles isn't installed, apply its rules inline.
  • product-strategy — source the section skeleton and exhibit vocabulary from it when present; its storyline blocks are good raw material for section arguments.
  • deck converter (e.g. html-to-visa-deck) — the Type column maps to template archetypes; keep the spine's one-message-per-slide discipline so the converter's density limits are met.

Degrade gracefully: if a referenced skill isn't installed, do the equivalent inline and note it.

Quality bar — failure modes to catch

  • Buried answer — governing thought hidden on slide 20 instead of stated up front. Lead with the answer.
  • Topic labels as arguments — sections or titles named by subject, not so-what.
  • Non-MECE key line — sections overlap or leave a hole in the argument.
  • Too many sections — more than five; the grouping needs another layer.
  • Title the exhibit can't prove — vertical logic broken.
  • Titles that don't ladder — read alone, they don't make the section's case.
  • Descriptive close — ends on a summary instead of a decision and next steps.

For the pyramid method (vertical Q&A, inductive vs deductive, MECE tests, SCQA, ordering logic) and a full worked payments example, read references/pyramid-and-examples.md.

References

  1. Pyramid Method & Worked Example

    1,262 w
    references/pyramid-and-examples.md6 sub-sections