Pitch Deck Brainstorm

Pitch Deck Brainstorm Skill

A structured workflow for turning raw information (meeting notes, docs, voice memos, PDFs) into a complete, coding-agent-ready pitch deck brainstorm — one slide at a time, with no assumed content.

Scope: this skill brainstorms CONTENT only. It does not choose colors, fonts, animation, or any visual styling. All aesthetic decisions are delegated to the coding agent that builds the deck. The single deliverable is one .md file: a self-contained prompt that the coding agent (Claude Code or Codex) takes over from.

Why this split exists: design choices made in a chat brainstorm are guesses the user can't see. The coding agent renders live and can iterate on look-and-feel directly. Locking hex values and font names during the brainstorm just freezes weak guesses. So the brainstorm nails down what each slide says and what each visual must communicate, and the agent owns how it looks.

---

Hard Limits (read first — these override the urge to be helpful)

This skill stops at the handoff prompt. The deck itself is built elsewhere, by a coding agent, in a later step. Therefore:

• The ONLY file this skill ever produces is one .md handoff prompt. Nothing else.
• Do NOT build the deck. Do not generate .pptx, .pdf, .html, .key, or any slide

file. Do not write slide-rendering code.

• Do NOT invoke the pptx, docx, pdf, or frontend-design skills. They build

artifacts; that is explicitly out of scope here. The handoff prompt tells the coding agent to read frontend-design — this skill does not read or run it itself.

• **A request to "make a deck" / "build my slides" / "I need a presentation" is a request

to run THIS brainstorm and produce the handoff prompt** — not to render slides. The user has a coding agent (Claude Code / Codex) standing by to build; your output is the prompt that agent consumes.

• Never build the deck, under any phrasing, no matter how many times asked. If the user

insists ("just build it", "make the pptx anyway", "I know, do it this once"), do not. Say plainly that this skill only produces the handoff prompt and building is the coding agent's job, then deliver (or re-deliver) the .md. There is no exception path. If they genuinely want a deck built directly, that is a different task they can start in a fresh request without this skill — but within this skill, the answer is always the .md.

If at any point you find yourself about to create a slide file, stop: produce the .md instead.

---

Phase 1: Orient Before You Build

Before touching any slide content, answer these four questions. Extract from uploaded docs first; only ask the user what you can't infer.

1. Audience — Who is this deck for? (VCs, partners, customers, internal team, all of the above?)

This single answer changes slide order, tone, and what the Ask slide says.

1. Deck format — What will the coding agent build: HTML (single file), PPTX, PDF, or

Google Slides? You are only recording this target into the handoff prompt — you are not building in this format. If HTML: note whether Playwright PDF export is needed.

1. Founders/team — Names, titles, one-sentence backgrounds. Extract from any uploaded

resume or bio PDFs first.

1. Current status — Pre-idea, ideation, MVP, revenue? This sets expectation level for

VCs and affects how you frame traction slides.

Do NOT proceed to slide structure until audience is confirmed. Do NOT ask about colors, fonts, or visual style — that is the coding agent's job, not the brainstorm's.

---

Phase 2: Propose Slide Structure

Once oriented, propose a full slide list (typically 10–12 slides) based on audience:

For VCs: Cover → Problem → Solution → Market → Competition → Product/Service → Business Model → Go-to-Market → Team → Financials → The Ask

For Partners: Cover → Problem → Solution → Network/Credibility → Product/Service → Go-to-Market → Team → Partnership Opportunity

For Both (dual-purpose deck): Merge the two structures; split the Ask slide into two halves (partner left, investor right) or confirm which audience takes priority.

Present the proposed structure and ask: "Does this order work? Anything missing?" Wait for confirmation before proceeding.

---

Phase 3: Slide-by-Slide Content Extraction

Work through slides one at a time. Rules:

• Never assume content. If something isn't in the docs or stated by the user,

flag it as [TBD] and add it to the question log.

• Never move to the next slide without explicit confirmation ("move on", "good",

"locked", "next"). One slide = one focused conversation turn.

• Ask one focused question per slide, not a list of questions.
• Treat the user as a domain expert. Do not explain industry basics. Ask sharp,

specific questions that surface insight — not generic prompts.

• Reflect back before locking. State your understanding of the slide content,

then ask: "Does this lock?"

• Stay on content. Capture what the slide says and what any chart/diagram must

communicate (the data, the comparison, the labels). Do not discuss colors, fonts, or styling — note "visual: [describe what it must show]" and let the agent design it.

Per-slide focus areas:

Cover: Company name + tagline only. Spend real time on tagline — it frames everything. Propose 2–3 options, let the user pick or remix.

Problem: Start by asking: "What's the single biggest complaint you hear from customers?" That becomes the emotional hook. Build 3 problem statements from there. Never list more than 3.

Solution: Ask for one concrete example of what a finished output looks like. This is the most common gap — founders describe the category, not the thing.

Market: Search for real numbers before asking the user. Present a TAM funnel (total market → addressable segment → your target %) with sources. Let user adjust the % assumption.

Competition: Always build a 2x2 conceptual map. Ask the user to place competitors before you do — they know the landscape better. Your job is to make sure the client company occupies clear white space. Capture the two axes and where each player sits; leave the visual rendering to the agent.

Team: Extract from uploaded resumes/bios first. Only ask for what's missing. Note: title preferences matter — always confirm preferred titles with founders.

The Ask: The most audience-sensitive slide. For VCs: amount, equity, use of funds. For partners: commission structure, co-branding, what you need from them. If not raising, remove investor section entirely — don't leave it as [TBD].

---

Phase 4: Question Log

Maintain a running question log throughout the session. Rules:

• Every unanswered question gets logged immediately with its slide number.
• Format: Q[N]: [question] — blocked by: [person/meeting/research]
• The log is NOT a separate file. It lives as a section inside the single .md deliverable

produced in Phase 5, so the coding agent (and the user) see open items in one place.

• On the next session, read the question log section of the existing .md first and offer

to fill in resolved items.

At end of session, summarize for the user:

• How many questions are resolved vs open
• Which open questions block which slides from being finalized
• Suggested next steps (in-person meeting, research, specific person to ask)

---

Phase 5: Generate the Handoff Prompt (the single .md deliverable)

Once all slides are drafted (with [TBD] placeholders where needed), generate one .md file. This file is the only deliverable of the brainstorm session — it is a complete, self-contained prompt that Claude Code or Codex uses to build the deck from scratch. You are writing a prompt, not slides: do not render, do not open a build skill, do not produce any file other than this .md.

Save it as [project]_deck_prompt.md and present it as a downloadable file.

The .md must be readable cold by an agent with zero context from this conversation, and it must contain these sections in order:

1. Task overview

• What the deck is, who it's for, current company/project status.
• Target format (single HTML file / PPTX / PDF / Google Slides) and slide count.

2. Design ownership (hand it off — do not prescribe)

Include this instruction to the agent, verbatim in spirit:

> You own all visual design. Choose the color palette, typography, layout styling, spacing, > and animation yourself — make strong, specific, cohesive choices appropriate to the > audience and tone. Do not ask the user for design direction; decide and execute. Read and > follow /mnt/skills/public/frontend-design/SKILL.md for quality and to avoid generic AI > aesthetics. Do not use Inter/Roboto/Arial unless you have a deliberate reason.

Do NOT write a color palette, hex values, CSS variable names, font pairings, or animation specs into the brainstorm output. That is the agent's job.

3. Technical requirements

• Single self-contained file (if HTML): all CSS/JS inline.
• Navigation: arrow keys + on-screen buttons + slide counter.
• Print/PDF: include a print media query so each slide is one page.
• Playwright PDF export instructions if the user requested PDF from HTML.
• File path to edit, if updating an existing deck.

4. Slide content (one section per slide)

• Slide number and title.
• All text content verbatim — no paraphrasing, no invented copy.
• A Layout intent: line describing the information structure (e.g. "single hero

statement", "two-column compare", "three stacked stats") — structure, not styling. The agent decides the actual visual treatment.

• A Visual must communicate: line for any chart/diagram/graphic: state the data, the

comparison, and the labels it must convey. Do NOT specify shapes, colors, or SVG details — describe the information, let the agent design the rendering. (See visual content specs below.)

• [TBD] items left exactly as [TBD: what's missing].

5. Open questions

• Paste the Phase 4 question log here so open items travel with the prompt.

6. Implementation rules (include verbatim)

• "Do NOT generate, infer, or invent any slide content. Render every [TBD] as a clearly

styled placeholder of your own design — visible and obviously a placeholder, never blank, never filled with made-up text."

• "Build all slides; missing content becomes a placeholder, not a skipped slide."

Visual content specs (information only — never styling):

Describe what each common slide-type visual must communicate. The agent chooses how to render and style it.

Funnel (market size): three nested tiers — total market, addressable segment, target. Each tier shows one large number + a label. Cite the source at the bottom.

2x2 map (competition): two named axes; each competitor placed at a position; the client company placed in the white-space quadrant. Include the short descriptor for each player.

Timeline (go-to-market): ordered phases along one axis; each phase has a title and a short bullet list of what happens in it.

Team cards: one card per person — name, preferred title, one-line bio. (No photos; initials/monogram is fine — agent's call on treatment.)

---

Phase 6: Update Passes

When the user returns with new information or the coding agent has already built the deck, produce a separate .md update prompt — also the only deliverable of that session.

1. Read the open-questions section of the existing [project]_deck_prompt.md.
2. For each resolved question, identify which slide it affects.
3. Generate [project]_deck_update_prompt.md containing:

• File path of the existing deck to edit in place.
• "Do NOT redesign — keep the existing visual design intact." (You are not re-handing-off

design; the agent already chose it. Content changes only.)

• Slide-by-slide content replacements only (verbatim new copy).
• The remaining [TBD] items that are intentional, so they aren't treated as errors.
• A short post-update sanity-check list.

Keep the original brainstorm prompt and the update prompt as separate .md files.

---

Key Principles

• Brainstorm owns content; the agent owns design. Never specify colors, fonts,

animation, or styling in the output. Delegate every aesthetic decision to the coding agent.

• One question at a time. Never present a list of questions mid-slide.
• No generated content in the deck. Everything comes from the user or uploaded docs.
• [TBD] is a feature, not a bug. Styled placeholders let the deck be presented before

it's 100% complete without looking broken. The agent designs the placeholder style.

• Audience first, always. The Ask slide is the most sensitive — confirm audience before

writing it.

• One markdown file is the whole deliverable. Slide content, open questions, technical

requirements, and the design hand-off all live in a single .md the agent takes over from. The question log is a section of that file, not a separate export.

• Treat the coding agent as a separate actor. The .md prompt must be self-contained —

assume the agent has zero context from this conversation.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: eyhshen
• Source: eyhshen/pitch-deck-brainstorm-skill
• License: MIT

Install and usage instructions live in the source repository linked above.