slides

Slides

Turn supplied material and a reader outcome into a visually coherent presentation. Own the deck's information/narrative structure, slide jobs, layout relationships, evidence-to-visual choices, and deck-level design coherence. Do not maintain a private layout/style search engine or a fixed HTML implementation scaffold.

Workflow

1. Confirm audience, intended reader outcome (for example understand, learn, compare, review, decide, or act), delivery format, slide count/range or time budget, source data/evidence, brand constraints, and target viewing context. For native PowerPoint delivery, use the host's presentations capability after the narrative/design contract is clear.
2. Read create, then load only the relevant layout patterns, slide strategies, and copy patterns.
3. Build an outline where each slide has one clear job, the minimum message/content needed for that job, supporting evidence when applicable, and a transition/relationship to the surrounding deck. Use a claim-style headline when the slide is making an evidence-backed assertion; do not force reference, instructional, agenda, or status slides into persuasive claim copy.
4. Choose layout and chart forms from the relationship the slide must communicate. Use current brand/project tokens when they exist. A standalone deck does not require creating a project design-token system merely to render.
5. Output: requested/host destination; otherwise .qp/artifacts/<stable-subject>/. Use temp for disposable intermediates.
6. Build the requested format through the host/native presentation or normal HTML/code capability. Keep implementation mechanics local to that output instead of preserving a package-specific deck generator/template.
7. Select imagery from supplied/current task evidence or current search/image capabilities when useful. Verify at the actual presentation viewport/export: overflow, contrast, legibility, chart labels/units, keyboard controls for interactive HTML, and reduced-motion behavior where motion exists.

Quality rules

• One dominant job or relationship per slide.
• Prefer a specific source-supported claim when a claim is the slide's job; use descriptive headings when the slide is primarily instructional, reference, navigation, or status information.
• Use hierarchy and whitespace; do not rescue overloaded slides by shrinking type.
• Keep candidates/data comparable on a common visual grammar when the slide asks for comparison.
• Use charts only when they make the relationship easier to perceive than prose/table.
• Preserve brand voice and current token relationships when available.
• Respect reduced motion and provide accessible descriptions for meaningful non-text visuals.
• Do not assume a CDN/chart library/animation system until the deck actually needs it.