# Pitch Deck Advisor > Build, review, and improve investor pitch decks for startups, with deep specialization in high-tech / deep-tech projects. Use this skill whenever the user wants to create a pitch deck, investor presentation, or fundraising materials; asks to review, critique, or "red-flag check" an existing deck; needs help writing or restructuring individual slides (problem, market, traction, team, ask); or asks how to pitch VCs, angels, or accelerators — even if they never say the words "pitch deck" (e.g. "help me raise a seed round", "prepare for demo day", "investor one-pager", "презентация для инвесторов", "питч-дек", "инвестдек", "собрать дек для раунда", "проверь мой дек", "дек для акселератора"). Based on Y Combinator, Sequoia Capital, a16z guidance and DocSend research on 200,000+ investor interactions. - Skill: `amaklakov-droid/pitch-deck-advisor` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add amaklakov-droid/pitch-deck-advisor` - Raw SKILL.md: https://api.skillmd.com/api/skills/amaklakov-droid/pitch-deck-advisor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: amaklakov-droid (https://skillmd.com/u/amaklakov-droid) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/amaklakov-droid/pitch-deck-advisor --- # Pitch Deck Advisor Help founders create and review investor pitch decks that get meetings. The guidance below synthesizes Y Combinator (Kevin Hale), Sequoia Capital's business-plan template, a16z practice, DocSend behavioral research, and deep-tech fund recommendations (Khosla Ventures, Julian Capital, Hard2beat). **Language:** conduct the conversation and produce deck content in the language the user is using. The principles below are universal. ## The one principle that governs everything An investor spends **2–4 minutes** on a first read (DocSend median: 3m44s; decks that fail lose the reader at ~2m13s). Top funds invest in roughly 1 of 200 warm pitches. Therefore: > A pitch deck is not built to "explain everything." It is built to be > understood and remembered in 3 minutes and to earn a meeting. The meeting — > not the investment — is the deck's only job. Every recommendation you make should trace back to this. When the user pushes to add more content, remind them of the 3-minute reality. ## Workflow Identify which mode the user needs, then follow it: 1. **Create** — build a deck (outline or full content) from scratch. 2. **Review** — audit an existing deck against the checklist and red flags. 3. **Slide surgery** — improve specific slides. ### Before doing anything, establish context Ask (briefly, only what is missing — don't interrogate): - **Stage**: pre-seed / seed / Series A+. This changes everything: pre-seed decks lean on Why Now, team, and vision; Series A decks lean on traction, unit economics, and a scaling model. "Why Now" is critical at pre-seed and barely read at Series A. - **Sector and whether it is deep tech** (hardware, biotech, new materials, energy, novel science). If yes, read [references/deep-tech.md](references/deep-tech.md) — deep-tech decks answer a different risk question ("will the physics work and scale?") and need extra elements. - **Audience and format**: emailed deck ("read me") vs. live presentation ("listen to me"). These are two different documents — see Form rules below. - **Strongest asset**: exceptional traction? star team? unique IP? Lead with the strongest card (Buffer led with revenue and unit economics, which covered a weak problem statement). ## Three design laws (Y Combinator) 1. **Legible** — readable by "an older person with bad eyesight from the back row": large type, simple typeface, high contrast, dark text on white. 2. **Simple** — one slide, one idea. Pick the **5–7 key ideas** the investor must remember and build the deck around only those. After a short pitch, people genuinely retain 1–2 ideas. 3. **Obvious** — a stranger must understand each slide at a glance. If a slide needs a second read, rewrite it. No subtle humor, insider metaphors, or "figure it out yourself" charts. Remember: investors invest in the team, not the slides. Slides only carry the message. ## Canonical structure — 12 slides + appendix | # | Slide | Must contain | Quality bar | |---|-------|--------------|-------------| | 1 | Title | Company name + one declarative sentence of what you do | A 5-year-old understands it | | 2 | Problem | Customer pain, its cost, how it's solved today | Specifics and numbers, never "current systems are inefficient" | | 3 | Solution | Value proposition, use cases | Clear in 10 seconds; show, don't tell (screenshots/demo frames) | | 4 | Why Now | Tech / market / regulatory shifts enabling this | Answers "why not 5 years ago, and why not in 5 years" | | 5 | Market | TAM / SAM / SOM, customer profile | SAM computed bottom-up, never "1% of $X B" | | 6 | Product / Technology | How it works, architecture, IP, roadmap | No jargon; depth goes to the appendix | | 7 | Traction | Growth chart, pilots, LOIs, retention | One honest chart beats ten vanity metrics | | 8 | Business model | How you make money, pricing, unit economics | Exactly one model, not three "options" | | 9 | Competition | Competitor map + durable advantage | Never "we have no competitors" | | 10 | Go-to-Market | Channels, first customers, sales cycle | Concrete actions and timelines | | 11 | Team | Founder-market fit: why *you* | Relevant achievements, not photos + diplomas | | 12 | Financials + Ask | Key numbers, round size, milestones | One number, "this round gets us to X" | | App | Appendix | Tech depth, financial model, pilot data | Everything that would overload the core | Order is flexible: lead with your strongest slide. If no growth chart exists, the investor assumes growth is bad — pre-Series A, "signal traction" is acceptable (e.g., "paid late-stage pilot with Enterprise client X with an expansion option"). For detailed per-slide guidance (content patterns, examples, common failure modes for each of the 12 slides), read [references/slide-guide.md](references/slide-guide.md). ## Form rules - **10–15 slides** in the core deck. Under 8 reads as unfinished; over 20 reads as inability to prioritize (engagement drops sharply). - **≤ ~50 words per slide**; any slide needing >30 seconds to parse is too complex. - **Two versions**: "read me" (emailed, self-sufficient, slightly more text) and "listen to me" (live, minimal text, large theses). Never one file for both jobs. - **Send as PDF attached to the email** — never a Drive/Dropbox link with an access request. 40%+ of emails are opened on phones. - Page numbers on every slide; "Private & Confidential" footer is the normal substitute for an NDA. - Live timing: 30-min meeting = ~15 min presenting (~75 sec/slide for 12 slides) + 15 min questions. - Series A: consider two documents — a short storytelling deck plus a separate data deck for the second meeting. ## Red flags — never let these into a deck If reviewing, flag each of these as a critical issue; if creating, refuse to add them and explain why: 1. **NDA request before viewing** — marks the founder as a novice; investors almost never sign pitch-stage NDAs. 2. **Exit-strategy slide** at early stage — great companies "are bought, not sold"; its absence is one of the most stable markers of strong decks. 3. **"We have no competitors"** — signals unresearched market. Competition includes Excel, manual work, and "do nothing." 4. **Valuation in the deck** — valuation is negotiated, not presented. 5. **Multiple business models "to choose from"** — reads as "we don't know how we'll make money." 6. **Unrealistic projections** ("$1B ARR in 5 years" without grounding). 7. **Ask as a range or "open to offers"** — one number + specific use of funds. 8. **"18 months of runway" as the plan** — runway is not a plan; state what becomes true about the company (milestones). 9. **Vanity metrics** (signups, page views, likes) instead of revenue, retention, cohorts, NDR. 10. **Top-down market sizing** without a bottom-up calculation. For the full anti-pattern list including form violations, read [references/review-checklist.md](references/review-checklist.md). ## Review mode When auditing an existing deck: 1. Run the **3-minute test** first: after a 3–4 minute read, can a stranger retell — what you do, for whom, why now, what proves it, how much you're raising? Report which of the five the deck fails. 2. Go slide by slide against the structure table and [references/review-checklist.md](references/review-checklist.md). 3. Separate findings into: **critical red flags** (from the stop-list), **structural gaps** (missing/weak canonical slides), and **form issues** (text overload, legibility). 4. For every issue, give a concrete fix — rewrite the offending headline or propose replacement content, don't just point. 5. For deep-tech decks, additionally check the deep-tech items in [references/deep-tech.md](references/deep-tech.md) (proven vs. to-prove, science vs. engineering risk, IP/moat slide, capital efficiency). ## Create mode 1. Gather context (stage, sector, audience, strongest asset — see above), plus the raw material: what the company does, customers, numbers, team backgrounds. If key inputs are missing (e.g., no traction data), ask once, then proceed with clearly marked placeholders like `[MONTHLY REVENUE CHART]`. 2. Choose the 5–7 key ideas the investor must remember; state them to the user before writing slides. 3. Produce a slide-by-slide outline: for each slide give a **headline that carries the message** (a full assertion like "Contractors lose $400/week to scheduling chaos", not a label like "Problem"), body content within the ~50-word budget, and a short speaker note. 4. Apply stage calibration and, for deep tech, the deep-tech structure from [references/deep-tech.md](references/deep-tech.md). 5. Finish by running your own output through the review checklist and the 3-minute test; state the 5–7 ideas the deck now carries. When the user asks for an actual presentation file (.pptx), build the content first using this skill, then use a presentation-building skill/tool if available. ## User requirements (standing — apply to every deck without being asked) ### Content: three things every deck must state explicitly Before finishing any deck (create or review), verify each of these has its own clear, dedicated formulation — vague or scattered treatment is a defect: 1. **Problem — one exhaustive formulation in plain language.** A single precise statement of the gap ("не существует продукта, который..."), plus its consequences for each affected party. The reader must be able to quote the problem in one sentence after reading. 2. **Target audience — who needs it earliest/most.** Name segments explicitly with their role (покупатель / пользователь / бенефициар), and single out who can extract value NOW, even while the market is small. State honestly which segments come later and that early revenue does not depend on them. 3. **Form factor — what exactly is being built.** Both the essence (mandate, wallet, protocol, ...) and the delivery format of each component: приложение / SDK-библиотека / облачный сервис / SaaS / открытая спецификация / open source. Also state what it is NOT (e.g. "не потребительское приложение, не новый платежный рельс"). ### Style for Russian-language decks - **Never use the letter "ё"** — always "е" (кошелек, расчет, партнер). Verify the final artifact (including speaker notes) contains none. - **Business register:** minimal idioms and colloquialisms; only terms accepted in the professional community are allowed (гейт, bps, рельсы, freeze, governance). Avoid startup slang: "отгружать" (→ "выпустить / вывести на рынок"), "городить" (→ "разрабатывать собственное решение"), "убивает" (→ "прекращает действие"), "раздает бесплатно" (→ "предоставляет бесплатно"). No "=" as a verb in headlines — spell it out ("— значит ...").