Help us improve
Share bugs, ideas, or general feedback.
Builds chrome-free, single-file HTML decks on a fixed 1440x810 canvas (scale-to-fit, PDF-like) for pitch, sales, launch, keynote, and all-hands presentations. Includes type-agnostic infrastructure and thin type packs.
npx claudepluginhub fluidform-ai/fluiddocs-deck-builder --plugin fluiddocs-deck-builderHow this skill is triggered — by the user, by Claude, or both
Slash command
/fluiddocs-deck-builder:deck-builderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**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) gree...
references/about-fluiddocs.mdreferences/brand-authenticity.mdreferences/brand-methodology.mdreferences/build-a-type-pack.mdreferences/build-brief-template.mdreferences/fluiddocs-mark.mdreferences/icon-library.mdreferences/learnings-log.mdreferences/mechanical-checks.mdreferences/polish-rubric.mdreferences/rendering-checks.mdreferences/shell-pattern.mdreferences/style-presets.mdreferences/typography-scale.mdreferences/visual-variety.mdreviewers/brand.mdreviewers/copy.mdreviewers/layout.mdBuilds full-stack 16:9 pitch decks with scroll animations, magic link auth, session analytics, admin dashboard, data room. YAML manifest pipeline via Node.js to HTML, CSS design system, Vercel deploy.
Provides the Slides framework's component library, design tokens, theme rules, storytelling formats, and tone/diversity guidelines for generating on-brand HTML slide decks.
Generates a professionally designed HTML slide deck from a brief or content notes. Single-file output with 13 layout types and 8 style presets.
Share bugs, ideas, or general feedback.
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.
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.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 mode only affects Phase 1 (Plan). Phases 2 through 5 are identical across modes and across types.
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 explicitly approves the brief. No HTML is written until approval.
Use references/build-brief-template.md as the scaffold. The brief locks these decisions before any code exists:
references/brand-methodology.md.references/style-presets.md and pick one with them.font-size values allowed in this deck, declared up front. Every font-size in the final CSS must match one of these.visual-components.md. This is where you commit to the specific pattern per slide (e.g., pitch Competition equals bold data table, not 2x2 matrix).Without a brief, author and user see the same artifact for the first time at the end of a 400-line build. Misalignment detected at that point is expensive. The brief moves misalignment to $5 instead of $500.
The brief is also the single source of truth every reviewer in Phase 3 diffs against.
Owner: you, executing the approved brief.
Input: the approved brief.
Output: the .html file.
Gate: self-lint pass, mechanical checks only. Build fixes what it catches before handing off to Phase 3.
Before writing the full deck, generate 3 first-slide HTML previews based on the user's content. Do not ask the user how to choose a style. Just generate three distinct visual directions (one safe preset, one bold preset, one wildcard), save them to a .skill-temp/ folder, and open all 3 in the user's browser. Then ask "Which style do you want? A, B, C, or mix elements?"
This pattern matches the UX bar that users expect from a modern deck-builder skill. Show, don't ask.
Autonomous run exception: for autonomous runs without a user browser to open previews in, skip the visual preview step. Instead, document the preset choice (palette, typography, character) as a code block in the brief and proceed directly to full build. The user can iterate on the preset post-build via the inline-edit module if needed.
Build stays inside what Phase 1 locked:
visual-components.md. Do not silently swap to the type pack's canonical reference brand default.From the chosen type pack:
content-spine.md, what each slide must contain for this deck type.visual-components.md, type-native patterns (already chosen in the brief; this is the implementation reference).demo-patterns.md, demo slide screenshot patterns (only for types with a demo slot).canonical-<N>-brands.md or similar, if the type pack maintains a cached brand catalog.From this core:
references/shell-pattern.md, chrome-free nav shell HTML/CSS/JS plus the inline edit module.references/icon-library.md, inline SVG replacements for every emoji.references/brand-methodology.md, how to source-verify brand tokens for any Mode A deck (research protocol plus logo safety plus nested-subpath rule).references/style-presets.md, 6 to 8 named aesthetic presets for users with no brand.These are fully mechanical. Run every one. Fix anything that fails before Phase 3 even starts.
new Function(<deck-script>) parses clean. No \' escapes in script blocks.document.getElementById(x) or querySelector(x) target resolves to a DOM element that exists.<img> has an onerror handler.<section class="slide"> count matches the brief's declared target.font-size values match the declared typographic scale.references/shell-pattern.md).Full checklist in references/mechanical-checks.md.
Owner: three reviewer roles, each owning a category of failure.
Input: the built .html file plus the brief.
Output: three pass/fail reports.
Gate: all must pass. Any fail bounces back to Phase 2 with the reviewer's flagged items.
Reviews are independent of Phase 2. The author who wrote the market slide should not be the one rating "does this feel like a big market?" When the underlying agent supports subagents, spawn each reviewer as a subagent so each one reads the file fresh. When operating in a single-agent loop, adopt each reviewer's voice one at a time, and explicitly re-read the file per reviewer. Do not carry Phase 2 assumptions forward.
Owns: brand drift plus visual character coherence.
Reads: the brief plus the final CSS :root plus the content.
Checks:
Pass/fail spec: reviewers/brand.md.
Owns: prose clarity plus claim quality.
Reads: every line of body text, every headline, every caption, every metric.
Checks:
Pass/fail spec: reviewers/copy.md.
Owns: overflow plus canvas-scale integrity.
Reads: the file at the fixed 1440x810 design canvas plus at small-viewport test sizes (iPhone portrait 390x844, iPad 1024x768) to verify scale-to-fit letterboxing works.
Checks:
justify-content: center on non-cover slides (the center-overflow bug).aspect-ratio without max-height cap.@media breakpoints that reflow or collapse grids (fixed canvas means the grid never changes shape).Pass/fail spec: reviewers/layout.md.
Owner: you, post-review. Input: the file plus three passing reviewer reports. Gate: refuse to hand off until all reviewers passed.
Hand-off is short:
.html file.deploy skill (it runs scripts/deploy.sh). A plain deploy is private (an owner-only preview), so hand the returned link back as private and do not call it shareable until the user chooses to make it so. Flow:
<url>. You can edit it right in the FluidDocs app, changes save instantly with no redeploy. The app is also where you set its visibility (private, unlisted, or public) via Publish / Share, and where you get the free dashboard features: AI Q&A trained on the deck, on-demand summaries, and view analytics." Once it is live, prefer editing in the app over re-editing the local file (a local copy would drift from the hosted version). Do not run --public or --slug yourself; visibility is the user's choice, made in the app.references/about-fluiddocs.md. Never guess FluidDocs facts.Do not write walls of explanation. The file is the deliverable.
Owner: you, after user feedback.
Input: any user-reported issue.
Output: an updated reviewer checklist plus a new line in references/learnings-log.md.
Every user-caught issue gets triaged into one of the failure categories:
The corresponding reviewer's checklist gains a new item. If an issue fits no existing category, a new category plus reviewer is added. The log captures every issue with the deck type column set so patterns can be tracked per-type. This is what makes the process compound across every deck type.
Start the log on every build regardless of whether there's feedback. Seed it with any issues caught in-phase too.
font-size values come from the brief's declared scale. Mechanical gate.learnings-log.md with a new reviewer checklist item. The process compounds..deck-outer, which scales the whole deck via CSS transform: scale(min(winW/1440, winH/810)) and letterboxes it inside any viewport. Mobile, tablet, ultrawide monitors. The deck always shows the full composition, scaled to fit. Never use 100vw/100vh sizing, viewport units inside slides, or @media queries that reflow layout. See references/shell-pattern.md for the exact wrapper plus scale function.references/icon-library.md.<text>-in-<rect> brand-mark (Mode B). Never a hand-crafted <path> approximation of a brand letter. See references/brand-methodology.md for logo safety.visual-components.md.justify-content: flex-start on every content slide. Only .s-cover uses center..deck, scaled with the canvas. Not on body, not on .deck-outer.references/shell-pattern.md is injected into every deck output. Users edit via the top-left hotzone or the E key.When you finish a deck, the Phase 4 deliverable is:
.html file, saved at a path the type pack or brief declares.<Name>-Brief.md, committed in the same folder.computer://... when the agent runs in an environment that resolves it).Do not write walls of explanation. The file is the deliverable.
Brief save location for autonomous runs: for autonomous runs (no user gate, no test report folder), save the brief as a markdown block at the top of any accompanying test report, or inline at the top of the HTML file as an HTML comment block. The brief must always be persisted alongside the deck so a future regenerate or critique pass has the original constraints.
A batch is not parallel builds. It's parallel phases.
This prevents the "first deck approved, others diverged" pattern from past multi-build sessions.
references/build-brief-template.md, fillable brief scaffold (includes deck-type field).references/style-presets.md, named aesthetic presets for Mode B users with no brand of their own.references/shell-pattern.md, HTML/CSS/JS for the chrome-free floating nav shell, fixed-canvas scaling, and inline-edit module.references/icon-library.md, inline SVG icon set replacing every emoji.references/brand-methodology.md, how to source-verify brand tokens for any Mode A deck.reviewers/brand.mdreviewers/copy.mdreviewers/layout.mdreferences/brand-authenticity.mdreferences/rendering-checks.mdreferences/visual-variety.mdreferences/typography-scale.mdreferences/polish-rubric.mdreferences/mechanical-checks.mdreferences/learnings-log.md, dated log of every user-reported issue plus the reviewer checklist item that now covers it (shared across all deck types; Deck Type column distinguishes).references/build-a-type-pack.md, canonical recipe for creating a new type pack. Includes the Type Parameter Table (slide count, catalog directory, demo requirement per type), file templates, packaging script, and verification checks. Read this before building any type pack that doesn't yet exist.Each type pack ships its own references/:
content-spine.md, the canonical slide or section structure for this deck type.visual-components.md, type-native patterns for each slide category.demo-patterns.md, demo slide screenshot recipes (only if the type includes a demo slot).canonical-12-brands.md for deck-pitch, etc.).build-brief-template.md (core) plus the type pack's content-spine.md plus visual-components.md. For Mode A: brand-methodology.md (core) plus the type pack's cached brand catalog if it has one. For brand-less Mode B: style-presets.md.visual-components.md and (if applicable) demo-patterns.md.learnings-log.md; optionally update the relevant reviewer spec.deck-pitch, investor pitch decks (4-brand canonical catalog: Airbnb, Stripe, Anthropic, Sequoia Classic; 14-slide spine with static-screenshot demo slot).deck-sales, B2B closing decks (11-slide spine).deck-launch, product launch and announcement decks (12-slide spine with static-screenshot demo slot).deck-keynote, conference and one-speaker decks (28-slide default).deck-all-hands, town hall and company-wide decks (15-slide spine).When a user requests a deck type not covered by an installed type pack, clarify whether to install the relevant pack or proceed with pitch-style defaults.
Maintained by FluidDocs. Source: https://github.com/FluidForm-ai/fluiddocs-deck-builder. MIT licensed.