presentation-builder

어떤 스킬인가요?

Build real deck artifacts when the user needs editable slides, not just prose: investor decks, roadmap/QBR decks, launch decks, architecture/demo decks, workshop/training decks, and game pitch or milestone decks. Use when the job is to choose one deck mode, one smallest useful artifact packet, and one honest handoff surface (HTML review, PPTX, PDF, Google Slides, or Figma Slides). Triggers on: presentation, slide deck, slides, pitch deck, roadmap deck, investor deck, launch deck, architecture review deck, demo deck, workshop slides, keynote, board deck, QBR deck, and game pitch deck. Route long-form docs to `technical-writing`, end-user tutorials to `technical-writing`, research manuscripts to `research-paper-writing`, and broad marketing planning to `marketing-automation`.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

{
  "skill_name": "presentation-builder",
  "evals": [
    {
      "id": 1,
      "prompt": "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.",
      "expected_output": "The skill classifies the request as an investor deck, chooses an outline-first or outline-brief packet before slide generation, uses a `decks/series-a/` workspace, and preserves PPTX handoff as a post-review step.",
      "assertions": [
        "Mentions investor or fundraising deck mode explicitly",
        "Includes a smallest useful packet such as outline-brief or storyboard before export",
        "Uses a deck workspace path such as decks/series-a/",
        "Treats PPTX as the last-mile handoff surface after review"
      ]
    },
    {
      "id": 2,
      "prompt": "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.",
      "expected_output": "The skill routes this to architecture-demo mode, focuses on evidence-rich technical slides, chooses a review-ready HTML packet before export, and preserves PDF as the async-review surface.",
      "assertions": [
        "Mentions architecture-demo or equivalent technical presentation mode",
        "Calls for screenshots, diagrams, or technical evidence rather than generic marketing slides",
        "Includes review-ready HTML or visual review before export",
        "Reports PDF as an async-review handoff target"
      ]
    },
    {
      "id": 3,
      "prompt": "Create a publisher pitch deck for our indie tactics game. Include hook, audience, gameplay loop, milestone plan, budget ask, and next step. Keep the deck source in decks/tactics-pitch and expect cleanup in Google Slides after export.",
      "expected_output": "The skill chooses game-pitch mode, structures the deck around gameplay proof and budget/ask, keeps a stable deck workspace, and makes Google Slides the explicit last-mile cleanup surface instead of pretending the browser deck is the final destination.",
      "assertions": [
        "Mentions game-pitch or publisher pitch mode",
        "Includes gameplay, audience, milestones, and budget/ask in the structure",
        "Keeps the deck source in decks/tactics-pitch or equivalent stable workspace",
        "Calls out Google Slides as a downstream handoff or cleanup surface"
      ]
    },
    {
      "id": 4,
      "prompt": "Help me figure out the launch messaging, channel plan, and owners for next month's release.",
      "expected_output": "The skill should route away from presentation-builder and recommend marketing-automation because the main artifact is launch planning and messaging, not a deck.",
      "assertions": [
        "Routes to marketing-automation or explicitly says presentation-builder is not the right skill",
        "Explains that the artifact is planning/messaging rather than a deck file"
      ]
    },
    {
      "id": 5,
      "prompt": "Write internal technical docs for our rollout plan, migration risks, and rollback steps.",
      "expected_output": "The skill should route away from presentation-builder and recommend technical-writing because the main artifact is a technical document, not a deck.",
      "assertions": [
        "Routes to technical-writing or explicitly says presentation-builder is not the right skill",
        "Explains that the artifact is a technical document rather than a slide deck"
      ]
    }
  ]
}

# 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

| Situation | Best packet | Why |
|---|---|---|
| Audience, story, or evidence is still fuzzy | `outline-brief` | Locks the narrative before visual work burns time |
| The deck structure is known but slide-by-slide content still needs shaping | `storyboard` | Stronger than bullets, cheaper than polished slides |
| The deck needs real visual review in the browser workflow | `review-ready-html` | Keeps source-of-truth editable and easy to iterate |
| The deck is approved and must ship as PPTX/PDF/Slides | `export-handoff` | Captures outputs plus cleanup risks honestly |
| The deck is one artifact in a larger launch/review package | `sync-packet` | Keeps the deck bounded while tracking downstream follow-ups |

## Packet skeletons

### 1. `outline-brief`
Use when the audience and slide promise matter more than visual polish right now.

```markdown
# 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.

```markdown
# 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.

```markdown
# 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.

```markdown
# 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.

```markdown
# Deck Sync Packet

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

## Handoff surface chooser

| Surface | Best when | Caveats |
|---|---|---|
| `html-viewer` | Technical teams will review/present in the browser workflow | Weak fit for nontechnical collaborators who expect office files |
| `pptx` | Executives, investors, customers, or partners need editable office-native slides | Expect font/layout cleanup and feature loss on export/import |
| `pdf` | Async review and fidelity matter more than editability | Harder to revise downstream; animations/interactivity are gone |
| `google-slides` | Cross-functional collaboration and comments matter most | Imports may need cleanup; linked charts/tables still refresh manually |
| `figma-slides` | Design-system continuity and visual collaboration matter most | Not as universal as PPTX for external handoff |
| `mixed` | Browser source stays canonical but downstream reviewers need multiple outputs | Report which surface is canonical and where cleanup will happen |

## 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** → `technical-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

```text
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

---
name: presentation-builder
description: >
  Build real deck artifacts when the user needs editable slides, not just prose:
  investor decks, roadmap/QBR decks, launch decks, architecture/demo decks,
  workshop/training decks, and game pitch or milestone decks. Use when the job is
  to choose one deck mode, one smallest useful artifact packet, and one honest
  handoff surface (HTML review, PPTX, PDF, Google Slides, or Figma Slides).
  Triggers on: presentation, slide deck, slides, pitch deck, roadmap deck,
  investor deck, launch deck, architecture review deck, demo deck, workshop
  slides, keynote, board deck, QBR deck, and game pitch deck. Route long-form
  docs to `technical-writing`, end-user tutorials to `technical-writing`,
  research manuscripts to `research-paper-writing`, and broad marketing planning
  to `marketing-automation`.
allowed-tools: Read Write Edit Glob Grep
compatibility: >
  Best when the environment can run `slides-grab` with Node.js 18+ and Chromium.
  The skill assumes an HTML-first editable deck workflow with browser review,
  then export or downstream cleanup in PPTX/PDF/Slides surfaces after approval.
license: MIT
metadata:
  tags: presentation, slides-grab, pitch-deck, roadmap-deck, investor-deck, demo-deck, pptx, pdf, html-slides, storytelling
  platforms: Claude, ChatGPT, Gemini, Codex
  version: "2.1.0"
  modernization: 2026-04-15
  hardening: 2026-04-18
---

# 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/presentation-modes-and-routing.md)
- [references/artifact-packets-and-last-mile-handoffs.md](references/artifact-packets-and-last-mile-handoffs.md)
- [references/source-and-handoff-patterns.md](references/source-and-handoff-patterns.md)
- [references/review-and-export-checklist.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 `technical-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.

```yaml
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](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:

| If the request is mainly about... | Use |
|---|---|
| technical specs, rollout docs, ADRs, migration details | `technical-writing` |
| tutorials, help docs, onboarding, screenshot walkthroughs | `technical-writing` |
| academic papers, rebuttals, manuscript sections | `research-paper-writing` |
| messaging, launch strategy, campaigns, content calendars | `marketing-automation` |
| a reviewable or handoff-ready deck artifact | `presentation-builder` |

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:

```text
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](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](references/presentation-modes-and-routing.md) for mode-specific slide patterns.

After creating or editing slides:

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

For visual iteration:

```bash
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](references/review-and-export-checklist.md) before export.

### Step 7: Export or hand off honestly
Only export after the chosen packet is ready.

```bash
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
```bash
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
```text
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
```text
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
```text
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`

N:presentation-builder D:"Build real deck artifacts when the user needs editable slides, not just prose: investor, roadmap/QBR, launch, architecture/demo, workshop/training, and game pitch decks. Use when the job is to choose one deck mode, one smallest useful artifact packet, and one honest handoff surface (HTML review, PPTX, PDF, Google Slides, or Figma Slides). Route long-form docs to technical-writing, end-user tutorials to technical-writing, research manuscripts to research-paper-writing, and broad marketing planning to marketing-automation." P:documentation/presentation-builder G:presentation|slides-grab|pitch-deck|roadmap-deck|investor-deck|demo-deck|pptx|pdf|html-slides|storytelling F:Claude|ChatGPT|Gemini|Codex