Ai Presentation Builder

ai-presentation-builder

A skill for building consulting-grade decks, anchored on the v5 Bright White & Pine design system — a bright near-white ground (FCFCFA), one deep-pine accent (12564A), espresso-INK (1A1A1A) text, a per-deck display font (default Charter) paired with Manrope body, emphasis carried by hairlines and type weight rather than coloured bars, pptx-first delivery. The system was built to strip patterns now widely read as AI-design tells — warm cream grounds, a single font everywhere, one-side accent bars, eyebrow pills, oversized section numerals. The anti-slop posture is part of the DNA: see references/anti-slop.md (the "slop" catalogue mapped to deck relevance) and the static checks in scripts/deck_qa.js.

The canonical reference implementation is assets/reference-build.js — a complete, render-tested pptxgenjs exemplar. Open it to pattern-match slide intent, then copy blocks out. The full recipe library, helper functions, and gotchas table live in references/build-helpers.md.

When to trigger

Use this skill proactively for any of:

• Strategy decks, pitch decks, consulting deliverables, case study responses
• Board presentations, leadership briefings, roadmap decks, transformation plans
• Market-entry analyses, diagnostic decks, recommendation decks, executive summaries
• Anything where the user references "consulting style", "MBB-style", "McKinsey-style", "Bain-style", "BCG", or names a real firm
• Any polished client-facing deck where the user wants brand-grade output with crisp prose

The workflow

Follow these steps in order. The pre/post-flight anti-slop gates are non-negotiable.

Step 0 — MANDATORY anti-slop pre-flight

This skill produces prose that has to survive a skeptical reader. Before drafting any slide copy, speaker notes, thesis line, context lines, or briefing text, read references/anti-slop.md so the language is calibrated against the AI-tells that make a deck read as machine-written.

After reading, hold these constraints while drafting copy:

• No em-dashes unless one is doing specific work you can defend (one per page maximum)
• Zero filler-buzzword vocabulary (delve, leverage, robust, seamless, transformative, paradigm, cutting-edge, game-changer, and the rest of the catalogue in anti-slop.md)
• No negative parallelisms ("it's not X, it's Y"; "not just A, but B")
• Sentences under 30 words; concrete nouns and specific numbers beat abstractions
• Action titles, not topic titles (the single most important rule — see slide_patterns.md)

Structural craft can be perfect and the deck still gets discounted the moment the prose reads as generic consulting-AI. This gate exists to stop that.

Prose discipline (enforce on every slide):

The single most common prose failure is hedging that turns a direct finding into a vague observation. Before delivering any slide copy, check every action title and context line against this test: could a skeptical reader say "that's just noise"? If yes, rewrite.

• Replace: "The diagnostic surfaces compounding leaks across the funnel." → Write: "Three gaps cost PKR 47M per quarter."
• Replace: "Transaction frequency indicates a potential habit-formation gap." → Write: "Users transact 2.4× less than peers despite giving the product an NPS of +42."
• Replace: "There is an opportunity to improve KYC completion." → Write: "KYC completion at 29% is an engineering failure, not a user problem."

The pattern: name the number, name the gap, name the mechanism. Drop the qualifier.

Step 1 — Brief the deck

Use AskUserQuestion (or ask inline where the tool is unavailable) with two back-to-back calls before writing a single slide or line of build.js:

Call 1 — Deck setup:

1. Audience + goal — who's reading this, and what decision or action do you want from them?
2. Deck archetype — diagnostic / recommendation / roadmap / market-entry / transformation / pitch / scqa / scr / bluf / inductive / issue-tree / deductive. The deck may be simple (one archetype throughout) or layered (a spine archetype + section-level overrides). If layered, decide which archetype runs which slide range and respect it; do not collapse it back to one shape.
3. Output format — pptx / html / md / gamma / briefing (multi-select; default: pptx)

Call 2 — Brand + visual brief:

1. Theme — pick one of 8 curated, anti-slop themes (each a complete palette: ground, neutrals, accent, default font). Offer: Bright White & Pine (default; calm, growth) / Slate (corporate, finance) / Oxblood (formal, establishment) / Solarized (technical, distinctive) / Paper (warm editorial) / Mono (austere monochrome) / Ink (dark, cool charcoal) / Midnight (dark navy + gold). The pick sets inputs.theme, which populates every token — including the semantic tokens (STRIP/ON_STRIP/ON_ACCENT/ON_ACCENT_MUTE) that make the dark themes invert fills and reversed text correctly. For brand-locked work, also supply inputs.brand.primary_hex to override the chosen theme's accent. Full per-theme token sets live in design_system.md §1.
2. Header font — pick one of 8 vetted faces (body always Manrope). Offer: Charter (editorial serif, default) / Palatino (warm serif) / Iowan Old Style (quiet serif) / Baskerville (formal serif) / Hoefler Text (classic serif) / Cochin (elegant serif) / Optima (humanist sans) / Manrope Bold (all-sans). Each theme ships a sensible default font; this overrides it via inputs.brand.font_display (sets DISPLAY, with DISPLAY_BOLD=true for Manrope Bold). All are macOS-installed and render-tested in the pptxgenjs→LibreOffice pipeline. Stay off the overused list (Inter, Roboto, Fraunces, Geist, Plus Jakarta, Space Grotesk). An all-sans pick consciously accepts the single-family advisory — see references/anti-slop.md.
3. Brand + content brief — client/company name, presenter, date, and a rough slide-by-slide idea (even bullet notes are fine; Claude structures it).

Schema lives at assets/inputs.example.json. Slide count is NOT a required input — let it follow from the content interview and archetype. Default to 8–12 for executive decks, 15–18 for deeper analyses, 26+ for master-deck synthesis.

Write inputs.json from the answers before touching any build script. Keeping inputs separate from the build script means the same script handles every future deck.

Step 1.5 — MANDATORY ghost deck before any content drafting

Before filling in slide bodies, panels, dots, gantt rows, or any prose: emit a ghost deck version of inputs.json with only:

• title_slide filled in
• slides[i].breadcrumb, slides[i].title, slides[i].context filled in (titles must be action titles — see Universal Conventions in slide_patterns.md)
• slides[i].layout chosen (Claude picks decisively from the archetype-filtered pool)
• All slides[i].content blocks left empty {} or with stub field names only

Present the ghost deck as a table with columns: # | Section / archetype | Breadcrumb | Action title | Layout | Context line (1 sentence) | Main visual / data (5-second test).

The Section / archetype column makes the layered structure visible at a glance. For simple decks (one archetype throughout), every row carries the same value (e.g. — / diagnostic). For layered decks, the column names the section the slide belongs to and the archetype that section runs — e.g. Build case / inductive, Sequence play / roadmap, Close ask / bluf. Section boundaries become visually obvious (adjacent rows share a section label; the change marks the break).

Then use AskUserQuestion (or ask inline) with these questions:

1. Does the narrative arc hold across sections? (Approve all / Revise specific slides / Major restructure)
2. Any title that doesn't state a "so what"? (List the slide numbers to fix, or "all good")
3. Any layout choice that feels wrong for its slide's job — including a slide whose layout fights its section's archetype? (List slide numbers, or "all good")
4. Any context line or visual description missing critical detail? (List slide numbers, or "all good")

Wait for explicit sign-off before drafting any body content. If the user requests changes, update the ghost deck table and re-ask — do not proceed to Step 1.6 until the user says "all good" or equivalent.

Why this exists: it is faster to throw away 10 slide titles than 10 finished slides. The Pyramid Principle / SCQA structuring discussion happens here, on the cheap version. Skipping this step is the single most common reason a finished deck has to be rebuilt, and it is also how sparse hero slides leak in where dense workhorse patterns belong.

Pattern picking inside the ghost deck: Claude picks layouts decisively from the archetype-filtered pool (scripts/pattern_filter.js --archetype=). Only use AskUserQuestion to surface a choice when two patterns genuinely tie on content fit or when the user has expressed taste preference earlier. Granular per-slide picking produces 10–12 forced asks per deck with no proportional quality gain; avoid it.

Monotony guard (opt-in picker): as you fill the Layout column, scan for two or more adjacent slides that would share the same visual idiom — most often horizontal bars (see references/slide_patterns.md → "Vary the bar idiom across adjacent slides"). When you find a run, either vary the treatment yourself or raise the preview-picker for the repeating slide: an AskUserQuestion with the recommended layout first (label it (Recommended)), then 2 render-safe alternatives, each carrying a short ASCII mini-mockup of the layout in the option's preview field so the user picks from pictures, not pattern names. This stays opt-in — it fires on a detected repeat, a genuine tie, or a "what are my options" from the user, not on every slide. It is the cheap counterpart to Step 4.5 Variation mode: nothing is built until the user picks.

Skip Step 1.5 only if the user has already supplied a complete inputs.json or has explicitly written "skip the ghost deck". Otherwise it is non-negotiable.

Step 1.6 — Per-slide creation discipline (5-step)

For every slide, fill the schema in this order. Do not jump ahead.

1. Messaging — write slides[i].title first. It must be an action title (the "so what"). If you can't write the title, you don't yet understand what the slide is for.
2. Structure — pick slides[i].layout from the catalog that supports the title. Default to dense workhorse patterns (diagnostic-three-panel, prioritisation-matrix, phased-roadmap-gantt, three-col-comparison, waterfall-baseline-to-target). Use sparse condiments (stat-row, big-numeral-findings) only as section bridges, never as the bulk of the deck.
3. Graphics / main visuals — fill slides[i].content. The visual should be readable in 5 seconds. For matrices: where do the dots sit? For gantts: which workstreams overlap? For waterfalls: which line item dominates?
4. Support — fill slides[i].context (one-sentence frame before the data hits) and slides[i].footer_note (source + caveat). Both are non-negotiable on data slides.
5. Polishing — handled by scripts/check_titles.js + Step 7 anti-slop post-flight + Step 8 flight-check delivery gate. Run before delivery.

Picking layout before messaging is how sparse hero slides leak in. Picking visuals before layout is how charts end up not supporting their titles. Polishing before content is wasted work. The order matters.

Full reference: references/methodology/slide_creation_process.md.

Step 2 — Read the design system + patterns

Always read (every build), in this order:

1. references/design_system.md — locked palette/typography/anatomy. Don't deviate without a reason.
2. references/slide_patterns.md — the master pattern catalog + universal conventions (action titles, selective color, chart honesty, bar/column ordering, label-direct, area-scale circles, footer discipline, waterfall-specific rules).
3. references/build-helpers.md — palette constants, the header()/title()/footer() helpers, every pattern recipe (§2.x), and the gotchas table. The implementation reference for every build. assets/reference-build.js is the worked example that exercises these.
4. references/methodology/content-interview.md — content interview framework (situation → problem → hypothesis → evidence → argument → answer). Run Phase 1 before touching any build script.

Read on demand (only when the trigger applies):

• references/chart-selection-guide.md + references/chart-library/ — when a slide needs a chart. Driven by Step 2.5; don't pre-load.
• references/slide-job-to-layout.md — when picking layouts in Steps 1.5 and 4.5, to make pattern selection traceable rather than intuitive.
• references/raci-guidance.md — when building a RACI or any role-ownership slide.

If the user provides a reference deck or slide to match, mine its thumbnails for layout and its text for section structure. Treat any external reference as structure-only: study how it is built, never copy its words, numbers, or images.

Step 2.5 — Chart slides: consult the chart library + chart-selection-guide

When a slide needs a chart (bar, line, stacked, dual-panel, combined bar/line, small-multiples, waterfall, mekko), do not improvise. Two references in sequence:

First, references/chart-selection-guide.md — the quick-pick table at the top maps the slide's intended message to the chart type. The principle: chart type fits the message, not the data shape. Apply the chart-specific tips (no 3D, label lines direct, bar logical-order, etc.).

Then, references/chart-library/ for the rendered recipe (one of the 6 distilled patterns):

1. Read references/chart-library/patterns/00-shared-design-rules.md once per session.
2. Pick the closest pattern from:

| Data shape | Pattern file | |---|---| | Ranking 5–12 categories by one metric | 01-horizontal-bar-with-delta.md | | Same categories shown as absolute AND % | 02-dual-panel-bar.md | | Composition / mix across categories or over time | 03-stacked-bar.md | | Continuous time series with 1–4 lines | 04-line-with-annotations.md | | Two related metrics on different scales | 05-combined-bar-and-line.md | | Same chart structure across 3–6 categories | 06-small-multiples.md | | Baseline → mechanisms → target | references/build-helpers.md → waterfall-baseline-to-target |

1. Read that pattern's full anatomy before drafting inputs.json for the slide. Each file has anatomy diagrams, design rules, headline templates, and "when NOT to use" guardrails.
2. Apply the brand palette via brand.primary_hex.
3. Source line is non-negotiable. Every chart slide MUST set slides[i].footer_note with a real source.

Copyright: the chart-library catalogs patterns and conventions only (see chart-library/SOURCES.md). Build every chart from the user's own data; never embed a third party's chart images, headlines, or numbers.

Step 3 — Pick the archetype skeleton

Each archetype maps to a slide skeleton. Pick the one that fits the user's intent, then adapt slide count by adding/removing optional slides marked with (opt).

For layered decks, the skeleton below is the spine — the overall arc. Section-level archetype overrides shape individual slide groups within the spine, not the full deck. A market-entry spine deck whose middle runs inductive uses the market-entry skeleton overall, but slides 3–5 in that section take the inductive shape (Finding 1 / Finding 2 / Finding 3 / Synthesis / Recommendation) instead of market-entry's competitive-landscape pattern at those positions. Decide the sections, then mix: spine skeleton overall, section skeleton inside each declared section.

diagnostic (default) — title · executive-summary · diagnostic-three-panel · p

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: umarmsharif
• Source: umarmsharif/ai-presentation-builder
• License: MIT

Install and usage instructions live in the source repository linked above.