Investor Pitch Deck
Build a fundraising or sales pitch deck that tells a tight investor-grade story: problem, solution, market size, product, business model, traction, go-to-market, competition, team, and the ask. Locks the NARRATIVE arc and per-slide message FIRST (a deck lives or dies on story order, not visuals), then designs a single consistent slide system, then builds a navigable HTML deck — one idea per slide, big claim plus one supporting proof, ending on a crisp ask and use-of-funds. Use for seed/Series-A raises, sales decks, demo days, and investor updates.
Steps
Entry step: narrative. Each step names the specialist role it wants; the full working prompt is expandable.
- Narrative arcplannerentry
lock the story order + one message per slide + the ask
Show working prompt
Design the STORY before any layout or pixels. Step 1: gather the inputs you actually have (problem, who feels it, the product, any traction numbers, the market, the team, and the specific ask amount + use of funds). Step 2: lay out the canonical 10-12 slide arc in order: (1) title/one-liner, (2) problem, (3) solution, (4) how it works / product, (5) market size (TAM/SAM/SOM), (6) business model, (7) traction, (8) go-to-market, (9) competition / why-now, (10) team, (11) the ask + use of funds, (12) closing/contact. Step 3: for EACH slide write exactly one headline claim plus 1-3 supporting bullets or a single number — never a wall of text. Step 4: flag any slide where you lack data and note the assumption you will state. Step 5: write an acceptance-criteria checklist (e.g. 'opens with a one-line value prop title slide', 'problem precedes solution', 'market-size slide gives a concrete number with a stated basis', 'traction slide shows at least one metric or an honest "pre-launch" note', 'closes with a specific ask amount + use of funds', 'one core idea per slide, <= 40 words of body each'). Write the slide-by-slide outline + decisions + checklist via write_task_note AND to notes/narrative.md. No design, no HTML yet.
- Visual designvisual-designer
one reusable slide system: grid, palette, type, number style
Show working prompt
Design ONE slide system the build will apply uniformly, so the deck reads as designed not assembled. Step 1: pick a palette with exact hex values (one ink, one background, one accent, one muted) and a confident type pairing (display weight for headlines, readable weight for body). Step 2: define the slide grid — title position, body zone, footer with slide number, and generous margins. Step 3: define how each slide ARCHETYPE renders: a hero/title slide, a big-number slide (for market size and traction), a 2-up or 3-up comparison slide (competition), a bullet slide, and a team slide. Step 4: specify one restrained accent treatment (a rule, a colored keyword, or a single accent shape) and a consistent emphasis style for the one big number per data slide. Step 5: write a visual-criteria checklist ('every slide uses the same grid + footer', 'exactly one accent color used consistently', 'big numbers are visually dominant on data slides', 'no slide mixes more than two type sizes for body'). Write the slide-system spec + checklist via write_task_note AND to notes/visual-design.md. No slide content yet. - Build the deckdeveloper
implement a navigable index.html applying the system to the outline
Show working prompt
Implement the deck as a single self-contained index.html (inline CSS + minimal JS, no external assets or CDNs). Step 1: create one full-viewport section per slide following the locked narrative order. Step 2: apply the slide system exactly — same grid, palette hex values, type pairing, and footer-with-slide-number on every slide; render each slide using its archetype from the visual spec (hero, big-number, comparison, bullet, team). Step 3: wire keyboard navigation (ArrowLeft/ArrowRight or PageUp/PageDown) and visible slide numbers so it is presentable. Step 4: drop in the approved per-slide headline + supporting content from the outline verbatim — do not rewrite the story or invent new metrics. Step 5: make data slides visually lead with their one big number; ensure the ask slide states the concrete amount + use of funds. On a loop-back, fix ONLY the gaps the reviewer named and do not regress slides that already passed. Write the deck path + final slide count via write_task_note.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
QA the deck against the locked criteria. Step 1: open/render index.html (or trace the source) and step through every slide with the arrow keys; confirm navigation works and slide numbers show. Step 2: verify the narrative order matches the outline (title -> problem -> solution -> ... -> ask -> close) and that problem precedes solution. Step 3: check EACH acceptance criterion from notes/narrative.md and notes/visual-design.md: one idea per slide and <= 40 words of body each, market-size slide gives a concrete number with a stated basis, traction slide shows a metric or an honest pre-launch note, the deck closes with a specific ask amount + use of funds, every slide shares the same grid/footer and one consistent accent color, big numbers dominate on data slides. Step 4: confirm no invented metrics crept in beyond the outline. Write PASS/FAIL for every criterion with the offending slide noted on any FAIL. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "build" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- pitch deck
- investor deck
- fundraising deck
- make a deck to raise money
- demo day slides
- sales deck
Source
View this craftbook on GitHub · MIT license