Slides and Diagrams

Make a deck or diagram that moves one audience to one decision or insight, and that still works when someone reads it alone, on a small screen, or with a screen reader. This skill decides structure, wording on the slide, visual evidence, builds, and diagram semantics. Rendering a deck file is the host's presentation tooling; charts on a slide are chosen with design-dataviz; evidence levels and motion rules live in design-core.

Golden path for a deck

1. Audience and the point first. Name who decides or learns what, and write the decision, ask, or insight in one sentence before any slide, because a deck built from the material outward ends on a summary nobody asked for. For a decision deck the ask goes on the first content slide (hypothesis, BLUF) [SRC-VIZ-027].
2. Write the storyline as headlines only. One full-sentence assertion per slide; read the headlines in order and the argument must stand without the bodies. Assertion headlines with visual evidence beat topic titles with bullets for understanding complex concepts in one experiment (context-dependent) [SRC-VIZ-023] [SRC-VIZ-022].
3. One visual that proves each headline. A chart, diagram, image, or short table; cut what does not serve the claim (supported, coherence) [SRC-VIZ-024].
4. Reduce text without losing information. Detail moves to speaker notes, appendix, or handout; narration is not pasted onto the slide, because hearing and reading the same words at once costs understanding (supported, redundancy) [SRC-VIZ-024].
5. Check at real display size. View each slide on the screen it will be shown on - projector, meeting-room TV, a shared window in a video call - and fix anything that is not readable there (hypothesis; no sourced size rule was found).
6. Builds only to signal or segment, one idea per step, with a static handout that carries the same content. Details in references/slides.md.
7. Verify the rendered deck and its claims. Check every claim against its source at a pinned revision, and render every slide in every language at every build step with overflow, overlap, and early-reveal checks, because a file check and a final-state screenshot miss what the audience sees first (observed). Details in references/verification.md.

Golden path for a diagram

Question first, then entities and relations, then one abstraction level, then type, layout, labels, edge cases, semantic check, and text alternative. Load references/diagrams.md for any diagram; user-journey flowcharts belong to design-flows.

Decision rules

• A pre-read deck may carry more text than a presented one, but keeps assertion headlines and the ask on page one (hypothesis) [SRC-VIZ-027].
• Every slide passes a glance test - its point is clear within a few seconds - or it is split (aesthetic) [SRC-VIZ-026].
• Animation and builds signal what to look at or segment a complex visual; decoration goes (supported) [SRC-VIZ-024] [SRC-VIZ-025]. Under reduced motion, or in an exported web deck, each step appears without movement, and anything auto-playing over 5 seconds has a pause (verified) [SRC-VIZ-009] [SRC-VIZ-010].
• Color is never the only cue on a slide or diagram (verified) [SRC-VIZ-007].
• A claim on a slide that no source supports is marked as hypothesis on the slide, because a readout headline is read as a finding (hypothesis).
• Words on slides follow the writing-* skills and figures plain-numbers when installed. Load writing-core before the first slide text, not after a review, and run its AI-tell pass and gate (--artifact slides, with the audience terms) over every language of the deck before it counts as done, because a deck reviewed only for layout ships generated-sounding text.

Load when

• references/slides.md - any deck: decision deck, research readout, talk, pre-read, or builds and animation on slides.
• references/verification.md - before a deck counts as done: claim ledger against the source, every visible state, technical deep dives.
• references/diagrams.md - any diagram: architecture, C4, system map, sequence, state, data model, or choosing a diagram-as-code format.

Gates

• Automated: diagram source parses and renders (mmdc, d2, or dot exit codes); color pairs meet 3:1 for marks and 4.5:1 for text (verified) [SRC-VIZ-008], for example with design-systems/scripts/contrast.py when installed. A tool that renders proves syntax, not meaning.
• Automated, when writing-core is installed: its quality_gate.py --artifact slides over the slide text of each language, no term error, every ai-tell warning judged.
• Automated, for a rendered deck: every slide, language, and build step passes overflow, overlap, early-reveal, and step-zero checks (references/verification.md).
• Manual: claim ledger with a verdict per claim; contact sheet per language looked at; headlines read alone tell the argument; real-size check; reduced- motion and handout parity; diagram semantic check and text alternative.

Done when

The audience and the point are written; every slide has an assertion headline and evidence; builds have a job and a static equivalent; every diagram passed its semantic check and ships with a text alternative and an editable source; claims carry evidence levels or are marked hypothesis; and what was not checked is listed.