Presentation Builder

Presentation Builder

Use this skill when the deliverable is a deck artifact people will review, present, or hand off as slides, not just an outline or narrative document.

presentation-builder is the documentation/publishing-cluster anchor for:

• investor, fundraising, board, and executive decks
• roadmap, QBR, status, and decision-review decks
• launch, GTM, and sales-enablement decks
• architecture walkthroughs, demo decks, and technical presentations
• workshop, training, and keynote decks
• game pitch, publisher, and milestone-update decks

Read these support docs before choosing the workflow:

• references/presentation-modes-and-routing.md
• references/artifact-packets-and-last-mile-handoffs.md
• references/source-and-handoff-patterns.md
• references/review-and-export-checklist.md

When to use this skill

• The user needs an actual slide deck, not just bullets or a memo.
• The workflow needs slide planning, visual iteration, and deck-specific evidence.
• The work must survive browser review before export or downstream office/design-tool cleanup.
• The output needs an editable or shareable slide surface such as HTML viewer, PPTX, PDF, Google Slides, or Figma Slides.
• The request names a deck artifact directly or clearly implies a presentation deliverable for review, pitching, enablement, or decision-making.

When not to use this skill

• The main job is a technical spec, ADR, runbook, migration guide, or internal implementation document → use technical-writing
• The main job is an end-user tutorial, onboarding guide, FAQ, or screenshot-heavy help-center flow → use user-guide-writing
• The main job is a research paper, rebuttal, or academic manuscript → use research-paper-writing
• The main job is broad launch planning, campaign strategy, positioning, or messaging without a concrete deck artifact → use marketing-automation
• The main job is only an outline, memo, or planning artifact and no deck file is actually needed → use the relevant planning or writing skill first

Instructions

Step 1: Classify one deck mode, one artifact packet, and one handoff surface

Normalize the request before drafting.

presentation_builder_mode:
  deck_mode: investor | roadmap-review | launch-gtm | architecture-demo | workshop-training | game-pitch | other
  audience: executives | investors | customers | internal-team | mixed | unknown
  source_material: brief | doc | spreadsheet | screenshots | charts | prototype | mixed | unknown
  review_need: outline-approval | visual-approval | export-ready | mixed
  artifact_packet: outline-brief | storyboard | review-ready-html | export-handoff | sync-packet | unknown
  handoff_surface: html-viewer | pptx | pdf | google-slides | figma-slides | mixed | unknown

Choose exactly one primary deck_mode for the run:

• investor → fundraising, board, strategic pitch, or executive narrative deck
• roadmap-review → roadmap, QBR, planning, KPI, status, or decision-review deck
• launch-gtm → launch briefing, sales-enablement, product narrative, or GTM deck
• architecture-demo → technical walkthrough, architecture review, developer talk, or demo deck
• workshop-training → workshop, training, keynote, or enablement deck
• game-pitch → publisher pitch, game concept, milestone update, or studio BD deck

Use references/artifact-packets-and-last-mile-handoffs.md to pick the smallest useful packet and the real last-mile surface early.

Step 2: Lock the promise, evidence, and downstream editor

Before generating slides, answer these three questions: 1. What should the audience understand, approve, or decide by the end? 2. What evidence must appear on the slides? Screenshots, charts, metrics, citations, links, footage, or product visuals. 3. Where will the final cleanup happen? Browser-only viewer, PPTX, PDF, Google Slides, or Figma Slides.

Do not pretend the handoff surface is irrelevant. Real deck workflows often start in HTML or Markdown but still end with office/design-tool cleanup.

Step 3: Route out non-deck work early

Use the smallest honest boundary:

Many “make slides” requests are really document or messaging requests. Confirm the artifact before building slides.

Step 4: Choose the smallest artifact packet

Default to the smallest output that makes progress:

• outline-brief → slide-by-slide outline with takeaway + evidence + risk notes
• storyboard → stronger slide sequence and rough content plan before visual polish
• review-ready-html → browser-reviewable deck source with visual iteration still open
• export-handoff → approved deck plus explicit PPTX/PDF/Slides handoff status
• sync-packet → deck plus short list of downstream artifacts or cleanup follow-ups

Do not jump straight to exported binaries when an outline or storyboard is the real next step.

Step 5: Build the deck from a stable source workspace

Default to a dedicated workspace such as:

decks/<deck-name>/
  slide-outline.md
  slide-01-cover.html
  slide-02-...
  assets/

Source rules:

• keep the editable source in the deck workspace
• keep raw evidence/assets close to the deck
• revise the source slides, not the exported PPTX/PDF
• keep spreadsheet/chart dependencies explicit if numbers may refresh later
• treat PowerPoint / Google Slides / Figma as last-mile surfaces, not the hidden source of truth

Use references/source-and-handoff-patterns.md for source-lifecycle rules.

Step 6: Use the mode packet, then review visually

Use references/presentation-modes-and-routing.md for mode-specific slide patterns.

After creating or editing slides:

slides-grab build-viewer --slides-dir decks/<deck-name>
slides-grab validate --slides-dir decks/<deck-name>

For visual iteration:

slides-grab edit --slides-dir decks/<deck-name>

Review rules:

• every slide should have one clear takeaway
• screenshots, charts, and footage must remain legible
• unsupported claims or placeholder visuals must be called out
• if async review matters, plan for PDF readability, not only live presentation flow
• if the deck will be edited outside the browser workflow, note the likely cleanup surface explicitly

Use references/review-and-export-checklist.md before export.

Step 7: Export or hand off honestly

Only export after the chosen packet is ready.

slides-grab convert --slides-dir decks/<deck-name> --output decks/<deck-name>.pptx
slides-grab pdf --slides-dir decks/<deck-name> --output decks/<deck-name>.pdf

Report all of these:

• source workspace path
• artifact packet selected
• validation status
• review status (outline approved / visually approved / export-ready)
• handoff surface and likely cleanup location
• output file paths
• remaining manual-polish risks such as fonts, layout drift, chart refresh, or office-tool cleanup

Step 8: Return the deck status in the right shape

Preferred response structure: 1. deck mode + audience 2. artifact packet selected 3. source workspace path 4. evidence used and review findings 5. export / handoff status and remaining risks

Core commands

slides-grab edit
slides-grab build-viewer
slides-grab validate
slides-grab convert
slides-grab pdf
slides-grab list-templates
slides-grab list-themes

All commands support --slides-dir <path>.

Examples

Example 1: Investor deck with explicit PPTX handoff

Turn this product brief into a 10-slide investor deck. Show me the outline first, then generate the deck in decks/series-a and hand off an editable PPTX after visual review.

Example 2: Architecture review deck for async review

Build an 8-slide architecture review deck for our browser automation service. Use screenshots, flow diagrams, and one slide on failure handling. I need a reviewable HTML deck first and a PDF for async review.

Example 3: Launch planning that should route out

Help me figure out the launch messaging, channel plan, and owners for next month's release.

Good direction: route to marketing-automation unless the user also needs a concrete deck artifact.

Best practices

1. Treat deck work as a narrative + evidence + handoff problem, not just a styling task. 2. Pick one deck mode, one packet, and one last-mile surface first. 3. Prefer a stable HTML source and regenerate exports instead of editing binaries directly. 4. Keep docs, spreadsheets, screenshots, and other upstream evidence explicit. 5. Call out where manual cleanup is likely instead of hiding fidelity limits. 6. Use the smallest packet that keeps progress honest. 7. Keep route-outs sharp: many “slides” requests are really docs, research, or marketing work.

References

• Upstream tool: https://github.com/vkehfdl1/slides-grab
• Figma Slides: https://www.figma.com/slides/
• Marp: https://marp.app/
• Slidev: https://sli.dev/
• Google Slides: https://workspace.google.com/products/slides/
• Microsoft PowerPoint: https://support.microsoft.com/en-us/powerpoint

Artifact Packets and Last-Mile Handoffs

Use this reference when the work clearly belongs in presentation-builder but the next move is still unclear. The real decision is usually which smallest deck packet to build now and which surface owns the last-mile cleanup.

Packet chooser

Packet skeletons

1. outline-brief

Use when the audience and slide promise matter more than visual polish right now.

# Deck Outline Brief

## Deck mode
## Audience
## Final ask / decision
## Evidence set
## Slide list
- slide number
- title
- takeaway
- evidence / visual
- risk / missing proof

2. storyboard

Use when the deck flow exists but the team still needs stronger content framing.

# Deck Storyboard

## Narrative arc
## Slide blocks
## Evidence gaps
## Visual notes
## Approval risks

3. review-ready-html

Use when the browser review loop is the next honest milestone.

# Deck Build Status

## Workspace path
## Current mode
## Slides built
## Review findings
## Open polish items

4. export-handoff

Use when the deck is ready to leave the source workspace.

# Deck Handoff Brief

## Output files
## Validation status
## Handoff surface
## Cleanup likely needed
## Remaining risks

5. sync-packet

Use when the deck must stay aligned with adjacent artifacts without absorbing them.

# Deck Sync Packet

## Primary deck artifact
## Required follow-ups
- marketing brief
- technical appendix
- help doc
- spreadsheet refresh
- destination-surface cleanup

Handoff surface chooser

Common last-mile patterns

• HTML source → PPTX handoff: best for investor, exec, launch, and game pitch decks where final editing happens in office tooling.
• HTML source → PDF handoff: best for async review, board-read packets, and fidelity-first sharing.
• HTML source → Google Slides / Figma Slides cleanup: best when collaboration and shared editing matter more than exact browser parity.
• Browser-only review: best for technical demos or internal walkthroughs when no office-native deck is required.

Common mistakes

• Jumping straight to exported binaries before the outline or storyboard is stable
• Pretending PPTX / Google Slides / Figma cleanup will not be needed when nontechnical collaborators own the final review
• Mixing the deck with the launch plan, spec, tutorial, or research manuscript instead of routing that work outward
• Treating spreadsheet-linked charts as static truth when the data will probably refresh later
• Hiding fidelity risks instead of calling out fonts, notes, animations, or layout drift explicitly

Presentation Modes and Routing

Use presentation-builder only when the main deliverable is a slide artifact.

Primary modes

1. Investor

Use for fundraising, board, strategic pitch, or executive narrative decks.

Typical slides:

• hook
• problem
• solution
• market
• proof / traction
• team
• ask

2. Roadmap review

Use for roadmap, QBR, planning, status, or decision-review decks.

Typical slides:

• summary
• goal / KPI state
• progress
• blockers / risks
• next phase
• decision needed

3. Launch / GTM

Use for launch briefings, sales-enablement, product narrative, or go-to-market decks.

Typical slides:

• objective
• audience / segment
• positioning / message
• offer / feature summary
• channel / enablement plan
• timeline / owners
• ask

4. Architecture / demo

Use for architecture walkthroughs, technical demos, solution pitches, or internal engineering presentations.

Typical slides:

• use case
• system / workflow overview
• architecture or flow
• code / screenshots / proof
• trade-offs / metrics
• next step

5. Workshop / training

Use for workshops, talks, keynotes, enablement decks, or training sessions.

Typical slides:

• learning goal
• agenda
• concepts
• example / exercise
• recap

6. Game pitch

Use for publisher pitch decks, game concept decks, milestone updates, or studio business-development decks.

Typical slides:

• game fantasy / hook
• audience / market fit
• gameplay loop
• visual proof / footage
• production plan / milestones
• budget / partner ask

Route-outs

• If the user mainly needs a document, not a slide artifact → technical-writing
• If the user mainly needs a tutorial or help-center flow → user-guide-writing
• If the user mainly needs a research manuscript or rebuttal → research-paper-writing
• If the user mainly needs messaging / campaign / launch planning without an actual deck file → marketing-automation

Durable boundary rule

Presentation requests often arrive with words like "deck", "slides", or "pitch", but those can hide different real jobs:

• memo / strategy note
• launch plan
• training guide
• investor story
• technical review

Classify the real artifact first, then choose the skill.

Review and Export Checklist

Use this checklist before exporting a deck.

Outline review

• Is the audience named or obvious?
• Does every slide have one clear takeaway?
• Is there an explicit final ask / decision / next step?
• Are unsupported claims or placeholder visuals still present?
• Is the slide order coherent for the chosen deck mode?

Visual review

• No overcrowded slides
• Headings and body copy are readable at presentation size
• Screenshots and charts remain legible
• Visual hierarchy is obvious
• Decorative elements do not compete with the core message
• Repeated slide components stay consistent

Evidence review

• Claims are supported by source material, metrics, screenshots, citations, or explicit assumptions
• Sensitive data has been removed or masked
• Speaker notes/rationale do not leak into the visible slide body unless intended
• Any unresolved risks are called out rather than hidden

Export review

• slides-grab validate passes, or failures are explicitly documented
• The deck has been reviewed in the browser viewer before export
• Export targets are confirmed: PPTX, PDF, or both
• File paths are stable and obvious
• Remaining manual-polish items are reported with slide numbers

Handoff review

• If handing off to a nontechnical collaborator, note whether PPTX cleanup is likely needed
• If the deck will be presented live, note any risky embeds, videos, or browser-dependent behavior
• If the deck is for async review, ensure PDF readability without narration

Source and Handoff Patterns

presentation-builder works best when the deck has a stable editable source and a separate delivery artifact.

Recommended workspace

decks/<deck-name>/
  slide-outline.md
  slide-01-cover.html
  slide-02-...
  assets/

Preferred lifecycle

1. Collect source evidence and visuals. 2. Create or revise the outline. 3. Generate / edit HTML slides. 4. Review visually in the local viewer. 5. Export PPTX/PDF only after approval. 6. Keep source slides as the place for future edits.

Common handoff patterns

HTML source + PPTX handoff

Best when the requester wants an editable office file after agent-led authoring.

Good for:

• investor decks
• executive update decks
• launch decks
• game pitch decks

HTML source + PDF handoff

Best when the deck is mainly for async review or preserving layout fidelity.

Good for:

• workshop decks
• customer/shareable summaries
• board-read or milestone packet attachments

HTML source + browser viewer only

Best when the deck will stay inside a technical workflow and visual review matters more than office-tool editing.

Good for:

• engineering demos
• internal architecture walkthroughs
• tool or product prototype reviews

Failure modes to call out

• export fidelity drift
• fonts / screenshots that look correct in the viewer but weak in PPTX/PDF
• too much narrative hidden in speaker notes
• using slides to hold detail that belongs in a document instead