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

1. Read the slot budget for each pattern just-in-time: masters/patterns/<pattern>.slots.md.
2. 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');

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

Phase 3 — QA

1. 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

Palette files in palettes/ define colors, fonts, chart rules, and mode variations.

Firm Style (Consulting Decks)

For every consulting deck, pick the firm style whose philosophy best fits the content:

Load the corresponding firm reference:

When density level requires references/craft.md (L2+), the firm file layers on top.

Density Profiles

Routing Table

Advanced visuals (build custom — masters/examples/)

No pre-built pattern. Study the script, adapt the technique.

Composition Rules

• Start with p01-cover (most decks) or c05-divider (mid-deck section entry).
• Do not repeat the same pattern back-to-back. Alternate patterns by content type.
• One slide = one argument. Every action title advances a distinct claim.
• Use interstitials intentionally: p10-agenda at section openings; c05-divider for chapter breaks.
• Footnotes: bracket style ([1]), restart numbering per slide.
• Density level governs composition. Do not use L3 techniques on an L1 deck.
• Section rhythm. For decks >8 slides, group into 3-4 sections. Open each section with p10-agenda (active item) or c05-divider. Close with a synthesis slide before the next section.
• Firm composition minimums. McKinsey: ≥1 waterfall (c02) per variance analysis. BCG: panel mini-headers on every multi-panel slide. Bain: ≥40% of analytic slides use c04-facts-perspectives in diagnostic mode.
• Chart variety. Do not use the same chart type (bar, line, table) on consecutive slides. Alternate data shapes to maintain visual engagement.
• Content fit. Each pattern's slot budget (*.slots.md) defines character limits and item counts. Before routing, verify your content fits: too few items produces a sparse slide; too many causes crowding. When in doubt, check the slot file's data schema and item ranges.
• Visual balance. Content is vertically centered in the body zone (between title and footer). Short content centers naturally; dense content fills the zone. If a slide looks top-heavy or bottom-heavy in QA, adjust the content volume — don't force positioning.
• Spatial constraints. PPTX uses absolute positioning — no responsive layout. Content must fit between bodyY and bodyEndY. Anchor elements to zone boundaries and use valign + fit:'shrink' — never manually estimate text heights for Y positioning.

Slot Budgets (Progressive Loading)

Slot budgets are stored per-pattern at masters/patterns/<pattern>.slots.md. Load just-in-time when building each slide — do not read all 21 upfront.

What NOT To Do

• Do not create HTML slide files. Use the createDeck() API directly.
• Do not use Playwright or browser rendering for slide content. All slide content must be native PPTX objects (text, shapes, charts) so the output is editable. Exception: rasterizing assets with no PPTX-native equivalent (e.g., SVG gradients, icon fonts) — see masters/examples/ for techniques.
• Do not scatter colors — define a consistent palette once and reference it throughout.
• Do not position headers or footers in pattern functions — the slide master handles chrome.