"Q3 revenue grew 12% on enterprise renewals" — yes. "Q3 Results" — no.

• Most analytics work is not a presentation. Duarte classifies "Research Findings," "Reports," and "Status Update" as slidedocs — read, not presented. If it will be emailed, design a slidedoc and say so: ~100 words/page (175 ceiling), and at 250+ words per page, stop making slides and write a document.
• Never present a slidedoc aloud, and never send a presented deck without a companion. If real narrative is needed for the sent version, put it in speaker notes and export notes pages — don't thicken the slides.

• dreambase-data-stories

  — for the argument. It owns the Big Idea, the pyramid/arc, and audience tiering. This skill owns the slide, the room, and the presenter. When both apply: get the Big Idea and storyline there, then bring them here. When it isn't available,

  references/deck-genres.md

  carries enough storyline structure to work standalone.

• dreambase-visualization-design

  — for every chart. Its selection matrix and integrity gate stay in force. This skill adds what it doesn't cover: legibility at room distance, staged reveals, and one-chart-carries-one-claim.

• dreambase-echarts

  — when charts render. Deck-specific animation settings are in

  references/interactive.md

  ; don't accept ECharts' defaults for a deck.

• dreambase-public-reports

  — when the audience is external. Its redaction rules govern before anything ships.
• A brand skill,

  design.md

  ,

  .potx

  , or a brand URL — whenever offered.

  references/brand-theming.md

  has the extraction procedure per input type. Absent any brand input, derive a system rather than reaching for defaults.

1. Assertion titles, per above. A deck whose titles don't read as a coherent argument on their own isn't finished.
2. Every number traces to data you were given. This is the failure mode that defines the category: AI deck tools accept only text input, so when a layout has a number-shaped hole, the number gets invented — published fact-checks of them report accuracy rates low enough that fabricated statistics have been attached to real named organizations. A number with no source is a bug, not a placeholder.
3. Nothing load-bearing below the room floor — 32 px / 16 pt presented. The message itself ≥ 80 px / 40 pt, so the slide survives a phone.
4. Animate only between states that share a data dimension. Otherwise cut or dissolve. Heer & Robertson: "Without a shared structure between graphics, animation may be ill-defined or misleadingly convey false relations."
5. Highlight, don't withhold. Render all data on slide entry at 25–35% opacity and bring the focus series up — rather than adding data progressively. Progressive addition lets you land on a conclusion the full chart doesn't support; progressive emphasis can't.
6. Nothing essential in a tooltip or hover. On stage there is no cursor at all — the presenter is holding a clicker. Direct-label on the slide; save tooltips for the shared link.
7. Every slide gets a real title placeholder, alt text on every visual, and a source line. The title placeholder is how screen readers navigate a deck; shape order in the file is the reading order.
8. Vary the layout, and decide it before you build. Assign an archetype to every slide in the storyline — full-bleed chart, chart+reasoning, comparison, small multiples, KPI row, single KPI, statement, table, image. Never three consecutive slides on the same archetype; ≥5 distinct archetypes per 20 slides; no archetype over 40% of the deck. This rule loses a fight with rule 1 if you let it: "assertion title, one chart" applied faithfully produces title-over-chart forever, and the deck passes every content rule while looking machine-made. Assertion-evidence constrains the argument, not the layout — the evidence form is what varies. If you're building a third title-over-chart slide in a row, change the evidence or merge the slides.
9. Don't validate against audience preference. Three independent studies found audiences prefer the design they learn less from. Test comprehension ("what's the decision?"), never "does this look good?"

1. Frame. Audience and their decision; reading condition (above); genre; room and surface (projector / big screen / Zoom share / PDF); time budget; brand input; whether it must land in someone's existing template. Ask when the answer changes the artifact — especially reading condition and output path.
2. Storyline. Pick the genre outline from

   references/deck-genres.md

   . Write titles only, in order, and read them straight through. If the argument isn't there in the titles alone, fix it now — no amount of layout rescues a broken storyline. Then add an archetype column — one per slide, chosen against rule 8 — and read the archetype sequence as a line. Any run of three identical labels is a bug you fix here, in the outline, where it costs nothing. Retrofitting variation after the slides exist never happens.
3. Evidence. One chart or number per claim, chosen through

   dreambase-visualization-design

   . Identify the hero chart. Charts that don't prove a title go to the appendix.
4. System. Tokens once for the whole deck: canvas, grid, type scale, palette, motion.

   references/slide-craft.md

   for the specs,

   references/brand-theming.md

   when brand input exists.
5. Slides. Lay out against the grid, building each slide as the archetype you assigned it in step 2. If a slide is fighting its archetype, the evidence is wrong for that claim — change the evidence, don't quietly fall back to title-over-chart.
6. Interaction and builds. Only where they earn it (

   references/interactive.md

   ). Default to zero interaction and one build sequence per slide, five steps maximum.
7. Build. Choose the output path from

   references/build-paths.md

   — the path follows from what the user has and needs, not from a default.
8. Gate. Run the pre-ship checklist in

   references/slide-craft.md

   , plus the visualization-design integrity gate on every chart.

• references/deck-genres.md

  — canonical outlines for board, investor, QBR, readout, launch, sales, all-hands, keynote, and slidedoc, with the metrics each requires and its failure modes. Read first for any new deck.

• references/slide-craft.md

  — the numeric system: canvas and the pt↔px bridge, safe areas, grid, type scale, contrast, motion, density, presenter ergonomics, the generated-deck tells, and the pre-ship checklist. Read when designing or reviewing slides.

• references/interactive.md

  — the interactive-slideshow model, staged chart reveals and their ethics, ECharts settings for decks, live-data discipline, presenter/remote mechanics, keyboard and a11y. Read for any deck with builds, interaction, or animation.

• references/build-paths.md

  — the four build paths with verified mechanics and gotchas: self-contained HTML, pptxgenjs, pptx-automizer, Google Slides API, plus PDF export. Read before building any file.

• references/brand-theming.md

  — extracting a design system from a design.md, website, PDF guide, .potx, or a lone logo; deriving an accessible palette from one brand color; light/dark pairs; the brand-safe checklist. Read whenever brand input exists.

• references/presenters.md

  — the verified canon (Alley, Duarte, Reynolds, Knaflic, Minto, Zelazny, Tufte and Doumont's rebuttal, Rosling, Evans, Meeker, Amazon), what the empirical research actually supports, where the authorities genuinely conflict, and the do-not-cite list. Read when justifying a choice or when a stakeholder invokes a name.