Deck Design — Operational Playbook

What This Skill Does

• Input: a deck brief + any structured data the user has (tables, time series, bridges, evaluation criteria, etc.).
• Output: a native editable .pptx file with slide masters, theme colors, and all content as PowerPoint-native objects (text boxes, shapes, charts). Every element is individually editable in PowerPoint.

The brief

The brief is everything the user provides about what they want. Before generating anything, extract these signals:

Not every brief contains all signals. Extract what's there, infer what you can, and use defaults for the rest. Do not ask the user to fill out a checklist. If the user provides a custom palette, brand guide, or design spec, follow it — the built-in styles are defaults, not constraints.

Storyboard intake (from consultant skill)

When the input is a storyboard artifact (from the consultant skill), the brief extraction is already done. Map directly:

Skip Phase 1 steps 1 and 5. The storyboard provides the content decisions; deck-design-ppt provides the visual execution.

Pattern library (21 communication patterns)

All patterns work across all 5 styles — the palette controls the visual identity, not the pattern.

Patterns are reference implementations, not constraints. Use them when they fit the content. When a slide needs a layout that no pattern covers, build custom using pptxgenjs directly — the grid constants, theme tokens, and slide master chrome still apply. The pattern library is a starting vocabulary, not a ceiling.

How To Generate A Deck (Algorithm)

Phase 1 — Understand

1. Analyze the brief. Extract signals from The brief. Research what the brief references — web search for market data, benchmarks, competitors; user-provided data is the primary source.
2. Pick style: consulting-mckinsey / consulting-bcg / consulting-bain / founder / sequoia. See Style Routing.
3. Pick density level. See Density Profiles.
4. Load firm reference (consulting decks only). See Firm Style.
5. Extract data shapes (table, timeline, bridge, grid ratings, etc.).
6. Route each slide to a pattern using the Routing Table, or build custom if no pattern fits.

Phase 1.5 — Outline

Before writing any code, produce a deck outline in markdown. This prevents sparse slides, content overlap, and mid-build surprises.

The outline must include:

1. Governing thought — one sentence that states the deck's answer.
2. Slide list — for each slide: action title, pattern, content summary, and data shape.
3. Flow test — read all action titles in sequence. Do they tell a complete story without the slide bodies? If not, fix the narrative before proceeding.
4. Density check — for each slide, confirm the content fills the body zone without overflowing. Patterns use dynamic vertical centering — content that is too sparse will float; content that exceeds slot budgets will crowd.
5. Data sufficiency — for each slide, confirm you have the data its pattern needs (chart series, metric values, table rows). If not, research to fill gaps before building.

Save the outline as {slug}-outline.md alongside the build script. It serves as both a planning artifact and documentation for future edits.

Phase 2 — Build

7. Read the slot budget for each pattern just-in-time: masters/patterns/<pattern>.slots.md.
8. Write the build script. Assemble the slide list with structured data for each pattern:

const { createDeck } = require('./skills/deck-design-ppt/masters');

createDeck('consulting-mckinsey', [
  { pattern: 'p01-cover', data: { title: '...', subtitle: '...' } },
  { pattern: 'p10-agenda', data: { items: [...] } },
  { pattern: 'p04-scorecard', data: { title: '...', cards: [...] } },
  { pattern: 'p03-evidence', data: { chart: {...}, callouts: [...] } },
  { pattern: 'c05-divider', data: { sectionNum: '02', title: '...' } },
  { pattern: 'p08-closer', data: { title: '...', nextSteps: [...] } },
], 'strategy-update.pptx');

9. Run it: node build-deck.js — produces the .pptx directly. No HTML, no browser, no rendering step.

Phase 3 — QA

10. Generate thumbnail grid for visual review and fix any issues:

Use the pptx skill's thumbnail script to generate a preview grid of the deck.

Output Organization

Save deliverables to the current working directory (or a user-specified output folder). Use kebab-case naming derived from the deck title:

• {slug}.pptx — the deliverable
• build-{slug}.js — the build script (reproducible)
• {slug}-outline.md — the deck outline (content plan)

Intermediate artifacts (QA thumbnails, temp rasterizations) go to the system temp directory — do not leave them in the workspace.

Architecture

Self-contained: package.json + node_modules/ are inside the skill folder. All require() calls resolve locally — no workspace-level install needed. Run npm install inside this skill folder if node_modules/ is missing.

The build kit lives in masters/:

Slide masters are parameterized by the theme — one set of master definitions works for all 5 styles. The theme controls:

• Header bar (yes/no + color)
• Footer rule, logo, page number colors
• Canvas background
• Accent color for titles, highlights

Pattern functions receive a slide (already has master chrome), the pptx instance, content data, and the theme. They only place content in the body zone — never touch the header, footer, or margins.

Grid constants (grid.js) define the spatial contract:

• bodyY / bodyEndY — body zone boundaries
• marginL / contentW — horizontal margins
• footerRuleY / footerTextY — footer positions
• centerY(contentH) — vertically center content in body zone

Style Routing

| If the deck is… | Use palette