pitch-deck

name	pitch-deck
description	Turn a feature drop's pitch summary into a presentation-deck PDF — a bold, type-driven slide deck rendered from `docs/#NNNN-<slug>-pitch.md`, structured Problem → Solution → Impact for a 3–5 minute pitch. Use whenever the user wants to "make a pitch deck", "turn the pitch into a PDF", "create a presentation / slides", "build the deck for

pitch-deck

Render a presentation-deck PDF from a drop's pitch summary. The pitch file (docs/#NNNN-<slug>-pitch.md, written by the pitch-summary agent) is the story; this skill turns it into slides a founder presents.

You are the orchestrator. The judgment of what goes on each slide belongs to the deck-builder sub-agent — you find the target pitch file(s), make sure the renderer can run, fan out one sub-agent per drop, and report what landed. Don't write slide content or PDF code yourself; that's the sub-agent's and the script's job, and keeping it there means many drops can render in parallel.

The deck's shape (Problem → Solution → Impact, demo-led, one line to close) comes from the house pitch reference ref.md. You don't need to read it — that framing is baked into the deck-builder agent.

1. Pick the target pitch file(s)

Pitch files live at docs/#NNNN-<slug>-pitch.md. Resolve which one(s) to build:

• User named a drop ("#0001", "0001", "the fridgechef one") → target that docs/#<id>-*-pitch.md.
• No drop named → Glob: docs/*-pitch.md and branch on the count:
  • none → there's nothing to deck yet. Tell the user pitch files are written by pitch-summary after mvp-execute ships a drop's last phase, and stop. Don't fabricate a pitch.
  • one → use it (mention which one you're building).
  • several → ask which with AskUserQuestion; list each by id + slug, and offer an "all of them" option. Don't silently build every deck — that's a lot of surprise output.

2. Make the renderer runnable (once)

The deck renderer needs reportlab. Resolve a working interpreter a single time and reuse it for every sub-agent:

PYBIN="$(bash "<project_root>/.claude/skills/pitch-deck/scripts/ensure_deps.sh")"

It prints an interpreter path on stdout (installing into a skill-local .venv the first time if your system Python lacks reportlab). If it exits non-zero, surface its stderr — the user may need to install reportlab manually — and stop.

3. Fan out one deck-builder per drop

Spawn the deck-builder sub-agent with subagent_type: deck-builder — one per target pitch file, all in a single message so independent drops render concurrently. Pass each:

id: 0001
project_root: <abs repo path>
skill_dir: <project_root>/.claude/skills/pitch-deck
python_bin: <PYBIN from step 2>
accent: <hex, only if the user asked for a brand color — else omit>

Accent is optional; omit it unless the user specifies a color (the renderer has a sensible default). If they mention a brand color, pass it as a hex string.

4. Report

Relay each sub-agent's slide map and output path — the user wants to know what got made and where. Keep it tight:

• docs/#0001-fridgechef-deck.pdf — 6 slides (Title · Problem · Solution · Demo · Impact · Close)
• note any slide a sub-agent dropped for lack of evidence

The editable spec is saved next to each PDF as docs/#NNNN-<slug>-deck.json — tell the user they can tweak wording there and re-render with build_deck.py without regenerating from the pitch. Then offer the natural next step: open the PDF, or walk the live demo (/playwalkthrough <id>) that the deck's demo slide cues.

Scope

• In: pitch.md → slide-deck PDF (+ its regenerable spec JSON), one per drop.
• Out: writing the pitch summary itself (that's pitch-summary), the Lean Canvas image (business-canvas), and general PDF surgery — merging, splitting, form-filling, editing an existing PDF (that's the pdf skill).