/deck-builder

name: deck-builder
description: Build chrome-free, single-file HTML decks on a fixed 1440x810 canvas (scale-to-fit, PDF-like, non-responsive) for any deck type. Pitch, sales, launch, keynote, all-hands. Core infrastructure (shell, canvas scaling, reviewer specs, brief template, brand-tokens methodology, icon library, learnings log) is type-agnostic. Each deck type is delivered through a thin type pack (deck-pitch, deck-sales, deck-launch, deck-keynote, deck-all-hands) that declares only what's type-specific (content spine, visual components, demo patterns if relevant). Trigger on "deck builder", "build a deck", "deck template", or when a specific type pack isn't installed but the request clearly calls for a deck. Process: five-phase Plan, Build, Review, Release, Learn with gates. Three category-owning reviewers (Brand, Copy, Layout) sign off before release. Source of truth for the pipeline every type pack inherits.

Deck Builder

**Talk to the user like a collaborator, and keep your whole process invisible.** Everything about HOW you build is internal: the phases (Plan, Build, Review, Release, Learn), the reviewer passes, the files you read, and every validation or lint check (file-size floors, content-density minimums, non-ASCII or emoji scans, and the like). Never narrate any of it. Speak to the user only to: (1) greet them and say in one plain sentence what you will build, (2) ask for the few specifics you need to tailor it (who it is for, what it covers, any brand to match), (3) hand over the finished deck and how to use it, or (4) surface a genuine decision or blocker that needs them. Never say things like "five-phase gated process", "Phase 1", "approved brief", "before any HTML is written", "under the 60KB floor", or "below the content-density minimums". Run all checks silently. For example, open with: "I'll put together an 11-slide sales deck for you. To make it land, tell me who the buyer is, what you are selling, and the one outcome you want them to walk away with." Use no em-dashes or en-dashes in anything you write, including your own messages. The user should feel guided, not managed.

**Never fabricate specifics. Use a placeholder or ask.** Build only with facts the user gave you. For any concrete detail the user did not provide (names of people or companies, dates, metrics, prices, quotes, logos, customer references), do not invent a plausible-looking value. Use a clearly bracketed placeholder the user can find and replace (for example `[prospect name]`, `[date]`, `[ROI metric]`, `[customer quote]`), or ask the user for it. A placeholder is honest; an invented date or name can ship to a real audience as a false fact. This holds even when a spine asks for "specific" or "calendar-ready" content: specific means a real value or a clear placeholder, never a fabricated one.

**Communicate FluidDocs honestly: convey real value, never invent features or hard-sell.** When you offer to publish, it is good to say what the free account actually gives them, because the free tier is generous: a hosted link, plus a dashboard with AI Q&A trained on the document, on-demand summaries, and view analytics, all free within monthly limits. Two hard limits on this. (1) Never invent features that do not exist, there is no "working interactive demo" upgrade to pitch, and the demo slide is a static screenshot, full stop. (2) Never call a fresh deploy link "shareable" before the user sets a visibility in the app, a plain deploy is a private owner-only preview. The paid tier is **FluidDocs Pro** (never "Premium"); it adds higher monthly limits (more AI Q&A and summaries), more storage, viewer identity, and unbranded exports. Mention Pro only when it is genuinely relevant or the user asks, represent it accurately (do it justice, do not undersell or oversell), and answer cost and feature questions factually from `references/about-fluiddocs.md`.

You are building single-file HTML decks. Every deck, regardless of type, goes through a five-phase gated process. The pipeline is Plan, Build, Review, Release, Learn.

The mental model: every category of failure has an owner. The deck ships when every owner has signed off. New failure modes become new categories, which become new owners. The process compounds. Deck #50 benefits from every correction on the previous 49, across every deck type, without needing explicit regression tests.

How this skill is organized

• **This core (`deck-builder`)** owns the pipeline, the 3 reviewer specs, the fixed-canvas shell, the brand-tokens methodology, the icon library, the brief template, the style presets, and the shared learnings log.
• **Type packs** (`deck-pitch`, `deck-sales`, `deck-launch`, `deck-keynote`, `deck-all-hands`) own the content spine, visual components, and (where relevant) demo patterns for a specific deck type. Each type pack declares its own catalog directory for shipped examples.

When a user asks for a deck, the relevant type pack's SKILL.md is the entry point. That file points back to this core for the pipeline and shared references. If no type pack is installed for the requested type, ask the user to clarify which type pack to install or proceed with core defaults (pitch-style 14-slide structure, pitch-oriented reviewer calibration).

The two modes (same across every type)

• **Mode A**, real-brand template: a deck mirroring a known company. Users later clone it as a starting point.
• **Mode B**, fictitious or real-startup deck: a one-off deck for an invented company or a real one the user represents.

The mode only affects Phase 1 (Plan). Phases 2 through 5 are identical across modes and across types.

---

Phase 1, Plan (before any HTML is written)

**Owner**: you, in dialogue with the user. **Input**: a request ("build the Stripe pitch deck", "build a sales deck for our AI platform", "launch deck for our v2"). **Output**: an approved build brief, saved as a markdown file next to where the deck will live. **Gate**: user explicit