# Pitch Creator > Create a product pitch/proposal to improve a step in the growth funnel (acquisition to activation to engagement to retention to monetization to referral). Use when asked to write a pitch, proposal, or business case for a feature, growth experiment, or UX change, when someone says 'pitch this', 'make the case for X', 'proposal for', 'should we build', or wants to justify a change by its funnel-met… - **Type:** Skill - **Install:** `agentstack add skill-exiao-pm-skills-pitch-creator` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [exiao](https://agentstack.voostack.com/s/exiao) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [exiao](https://github.com/exiao) - **Source:** https://github.com/exiao/pm-skills/tree/main/pm/pitch-creator ## Install ```sh agentstack add skill-exiao-pm-skills-pitch-creator ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Pitch Creator > **Output rule (overrides everything below):** communicating simply and concisely is the single most important thing this skill does. **Total text across the whole pitch is one page max.** If the pitch needs more than that to land, the extra weight goes into diagrams, prototypes, or visuals, never more prose. Text states the decision (proposal, problem, recommendation); artifacts carry everything else. If you're writing a fourth paragraph of explanation, you owe a prototype or a diagram instead. A pitch that's a wall of text has failed even if every section is present. Turn a rough product idea into a decision-ready pitch. The output exists to help someone say yes or no, so every section either moves that decision or gets cut. The funnel this optimizes: **acquisition → activation → engagement → retention → monetization → referral.** Adapt the exact stage names to your product's own funnel if it differs. Every pitch names which arrow it's trying to move. A pitch that can't point to one arrow is a solution looking for a problem. ## The two non-negotiables Most weak pitches fail the same two ways, so the skill forces the fix: 1. **Solutions are prototypes, not adjectives.** "A cleaner onboarding" is not a solution, it's a wish. Section 3 must contain things a person can click, look at, or run: a real HTML/interactive prototype, a screenshot, a Figma-style mock, a code stub. If you describe a solution in words, you haven't designed it yet. Build the artifact. 2. **Placement is a diagram, not a sentence.** "This helps during onboarding" tells the reader nothing about what it displaces or what comes before and after. Section 4 must be an actual storyboard/flow diagram (SVG rendered to PNG, or an image), showing the before flow and the after flow with the change marked. See "Diagrams" below. If you find yourself typing a paragraph where a prototype or diagram belongs, stop and make the artifact instead. ## When the solution is thin glue over existing APIs Source: Joe Reeve (ElevenLabs), "How to talk to statues," AI Engineer, Jun 2026. His statue app (photo → OpenAI deep research → voice-design API → agent → phone call, ~30s) was vibe-coded in 2 hours and drew inbound from the British Museum, Christie's, Bonhams, and Tripadvisor competitors (one CEO: "I've had 10 people on this for a year, how did you build this?"). Many strong pitches propose something that's mostly integration: stitching together APIs that are already built to scale. Don't apologize for that or pad the pitch to make the tech look hard. Three moves instead: - **The story about the glue IS the product.** "Telling a good story about the glue is the most important thing, not solving hard technical problems." When the components are commodity, the pitch's job is the narrative and the taste, not a fake technical moat. Section 1 (the one-sentence proposal) and the prototype carry more weight here, not less. - **Scaling is a non-risk, say so explicitly.** In Section 6, when every component is a third-party API designed for volume ("no way I can make a dent in the API volume even if this goes gangbusters") plus a one-shot login/DB layer (Supabase, magic links), name scaling as a solved problem and move the risk budget to where the real risk is. Don't invent scaling risk to look rigorous. - **The real long tail is curation/evals, not engineering.** The hard, durable work is the content layer: getting curators to write the actual narrative instead of "random things you found from Google." If the pitch is a glue product, Section 8's riskiest-assumption and cheapest-experiment should target content quality and evals, not the integration. That's where the moat and the failure mode both live. ## Required structure Produce the pitch with exactly these eight sections, in this order. Keep prose tight; the artifacts carry the weight. **1. Proposal in one sentence.** One sentence. If it needs two, the scope is two proposals. Format: "For [funnel arrow], [do X] so that [metric] improves." **2. What problem are we solving?** The user pain and the business pain, with evidence. Cite the number that's currently bad (drop-off %, conversion rate, retention curve) and where it sits in the funnel. No number → say "unmeasured, need instrumentation first" rather than hand-waving. Pull real data from your product analytics where available rather than inventing it. **3. Solutions considered (prototypes, not words).** At least two candidate solutions, each as a *working artifact*. Build them with: - a dedicated frontend-design skill (or your usual UI-building workflow) or a UI-prototype-exploration workflow for clickable UI prototypes - `product-prototype-gallery` for a gallery of variants - `nano-banana-pro` for a mocked screen when a full build is overkill - a code stub / pseudo-flow when it's a backend or algorithm change Each artifact gets embedded in the Surge page (live `` or screenshot, see Output format). For each, one line on what it is and its main tradeoff. **4. Where in the UX flow (storyboard diagram).** A before/after storyboard of the user flow with the change marked. SVG → PNG via `rsvg-convert`, or an image. Show what screen/step precedes and follows the change, and what it displaces. Never prose. See Diagrams. **5. Expected metric impact (gains AND losses).** Per solution, estimate the delta on the target arrow AND on every arrow it could hurt. A subscribe-prompt that lifts conversion may cut downloads-to-active; name that. Format each as a small list: - Target metric: +X% (basis for estimate) - Collateral metric(s): −Y% or "flat" (why) - Net read: worth it / marginal / no Label estimates as estimates. If you can't estimate, say what experiment would tell you. **6. Biggest risks and how it goes poorly.** The 2-4 ways this fails: user confusion, tech debt, a metric you tank, App Store rejection, a regression. Each risk gets a mitigation. A risk with no mitigation is a reason not to ship, say so. **7. Alternatives, including do-nothing.** Other approaches you rejected and why, plus an explicit **"what if we do nothing"** row: what the funnel does if this ships never. Sometimes nothing is the right call and the pitch should be honest enough to surface it. **8. Final recommendation.** Pick one. Which solution, why it beats the alternatives in one sentence, the single riskiest assumption, and the smallest experiment that de-risks it before full build. A pitch that ends with "it depends" hasn't done its job. ## Diagrams Storyboards and flow diagrams are SVG rendered to PNG, never ASCII: ```bash rsvg-convert -o storyboard.png storyboard.svg # then send_file + echo MEDIA: ``` Use your brand's visual identity (a house style doc if you have one, e.g. `VISUAL-IDENTITY.md` / `STYLEGUIDE.md` at repo root) for fonts and colors so it reads on-brand. Mark the changed step distinctly (color/border) against the unchanged flow. A good storyboard shows before-flow above, after-flow below, same horizontal step positions so the eye catches the diff. ## Output format: deploy the pitch to Surge The deliverable is a **live Surge page**, not a Signal message. A pitch is prototypes plus a storyboard plus metric tables; that only works as a page someone can scroll and click. Build the page, deploy it, and reply with the URL. Build it as one self-contained page and deploy via the `surge-deploy` skill: ```bash mkdir -p pitch-/ # e.g. pitch-subscribe-prompt # write index.html here (the pitch), plus storyboard.png and any prototype screenshots cd pitch-/ surge ./ pitch-.surge.sh # stable subdomain, re-deploy overwrites curl -sS -o /dev/null -w "%{http_code}\n" https://pitch-.surge.sh # 504 first is normal, wait 8s ``` Page requirements: - All eight sections in order, with section 1 and section 8 (recommendation) at the top so a busy reader gets the decision first. - **Embed the prototypes live where possible** (an `` of a clickable HTML prototype beats a screenshot). Fall back to screenshots for mocked or backend solutions. - **Embed the storyboard** as an inline image. - Match your product's design tokens: reuse an existing house style / design system if you have one and copy its `` block rather than inventing one. Self-audit against common frontend-design and UI-polish bans (overused fonts, generic AI aesthetics, weak contrast) before deploy. - Validate tag balance (stdlib `html.parser`) before deploying a multi-section page. After deploy, record the artifact somewhere durable (a shared doc or index) and reply with the live URL, not a wall of text. ## Quality bar Before delivering, check: - Section 3 has real artifacts, not descriptions. (The most common failure.) - Section 4 is an image, not a sentence. - Section 5 names at least one metric that could go DOWN. - Section 7 has a real do-nothing row. - Section 8 commits to one option and names the cheapest de-risking experiment. If any fails, it's not done. The reader should be able to decide from this alone. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [exiao](https://github.com/exiao) - **Source:** [exiao/pm-skills](https://github.com/exiao/pm-skills) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** yes - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-exiao-pm-skills-pitch-creator - Seller: https://agentstack.voostack.com/s/exiao - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.