# Slides

> Create presentations and slide decks with coherent narrative or information structure, purposeful layouts, accessible charts, and verified delivery. Use for explanatory, instructional, status, review, strategic, persuasive, or decision-oriented decks in HTML, PowerPoint, PDF, or another requested presentation format.

- Skill: `quantipixels/slides` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add quantipixels/slides`
- Raw SKILL.md: https://api.skillmd.com/api/skills/quantipixels/slides/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: quantipixels (https://skillmd.com/u/quantipixels)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/quantipixels/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](references/create.md), then load only the relevant [layout patterns](references/layout-patterns.md), [slide strategies](references/slide-strategies.md), and [copy patterns](references/copywriting-formulas.md).
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. 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.
6. 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.