Pitch Deck Writer

A seed investor spends about 3–4 minutes on a deck. Many aren't read to the end, and the first slide gets far more attention than any other. So the deck has to make its case in the headlines alone. YC's rules are legibility, simplicity and obviousness: one idea per slide, large type, and no decoration that doesn't carry meaning. Sequoia's structure is the default narrative, and it expects a bottom-up market size.

How numbers work

Same rule as the business-plan-writer skill:

• Computed figures appear in the spec only as {{path|format}} tokens, filled from a facts file holding the engine's own output.
• The projection chart ("from": "results.projection"), the scenarios table and the competitor grid are generated from the facts directly.
• Never type a computed figure. A path that doesn't exist stops the build.

Step 0: Mode and inputs

Look for the Foundation MCP tools (a client may add a prefix).

• Connected: confirm the project. Save facts.json with currency, project (get_project), results (compute_feasibility) and scenarios (compute_scenarios), pasted in verbatim. Run the market-research skill first if there's no competitorBenchmark or market sizing yet.
• Standalone: no engine figures. Build the story slides; for the financial slide, show the investment inputs and the pricing and say projections come from Foundation. Don't invent profit, IRR or payback figures.

Ask in one round for anything you still need: the audience (angel, VC, bank or grant body), the amount and instrument, the team bios, any traction (customers, pre-orders, letters of intent, revenue so far), and a one-line tagline.

Step 1: Storyline (write the headlines first)

Write every slide's headline as its takeaway, as a full sentence. For example, "No one on the route combines specialty coffee, food and a 7am opening", not "Competition". Read the headlines in sequence. If they don't tell the whole story alone, fix them before designing anything.

Default sequence (10–13 slides):

• Bank or lender audience: move the downside and repayment capacity forward, and play down "why now" and exit.
• Grant body: add impact, such as jobs (project.overview.employment) and local benefit.

Step 2: Write the spec

Format: references/spec-format.md.

• At most about 25 words of body text per slide, and 3–4 points maximum. Put detail in the speaker notes (notes).
• Headlines: 1–2 lines. The renderer warns when text probably overflows its box.
• Every slide already carries a visual element: a big number, a chart, a grid, bars, or an accent rule. Don't add clip-art.
• Use-of-funds percentages must add up to 100 (the renderer checks this).
• Consistency: the same numbers as the business plan and the project. Same ask, same dates, same team.
• Writing-style pass (required). Follow references/writing-style.md, which is based on Wikipedia's "Signs of AI writing" guide. No em dashes. Headlines must be plain claims, not slogans. If a humanizer skill built on that guide is installed (for example blader/humanizer), run it over the headlines, points and notes. It may change wording only, never a number, name, date, source or {{token}}. The renderer's style check must end with no style warnings.

Step 3: Render and QA

python scripts/build_pptx.py deck.json pitch-deck.pptx --facts facts.json --png qa/

This needs python-pptx and matplotlib (preinstalled in Claude's sandbox), plus LibreOffice and PyMuPDF for the PNG step when available.

• Exit code 2: a token path is wrong. Fix the path.
• Look at every slide PNG. Treat QA as a bug hunt, not a formality. Check for overflow, collisions, a headline that wraps to three lines, an unreadable chart, an empty-looking slide, or a number that contradicts another slide. Fix, re-render and look again.
• If LibreOffice isn't available, say that visual QA wasn't possible, and still fix every renderer WARNING.

Step 4: Optional second step: advanced restyling with another tool

The renderer produces a clean, correct deck. For the founder's own slide master or brand template, native editable charts or heavier design, hand the finished .pptx to the presentation tool their environment has, as a second step:

• Claude: Anthropic's pptx skill.
• ChatGPT / Codex: OpenAI's slides handling.
• Gemini: import into Google Slides and use Gemini there.
• Microsoft 365: Copilot and Designer in PowerPoint.
• Cursor and other agents: an open-source skill such as ppt-master (MIT), which fills an existing template.

The table and links are in references/restyling.md. Tell that tool to change design only. Afterwards run python scripts/check_numbers.py pitch-deck.pptx pitch-deck-restyled.pptx, and look at the rendered slides again. If any number was lost, changed or added, don't deliver the restyled file.

Step 5: Deliver

The .pptx, plus a one-paragraph note: the storyline in headline form, which slides rely on [estimate] inputs, and what would strengthen the deck most (usually traction evidence).

References

• references/spec-format.md: slide types and fields.
• references/writing-style.md: the no-AI-tells writing guide (Wikipedia's "Signs of AI writing", no em dashes).
• references/restyling.md: which tool to use for a second-step restyle, by environment, and how to verify the numbers survived.

Guardrails

• No fabricated traction, logos, testimonials or team credentials.
• The market numbers are the market-research skill's sourced figures, with sources on the slide.
• Competitor claims in the grid must be verifiable (public sources).

Sources

DocSend/Papermark deck-reading data (average review time about 3.7 minutes; first slide read most; only about 58% read to the end), YC seed deck guidance (legibility, simplicity, obviousness) and Sequoia's template: DocSend, Papermark, YC library, Sequoia format. Slide QA approach inspired by Anthropic's public pptx skill (referenced, not copied; that skill is source-available, not open source).