Pitch Creator

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 <iframe> 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:

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:

mkdir -p pitch-<slug>/        # e.g. pitch-subscribe-prompt
# write index.html here (the pitch), plus storyboard.png and any prototype screenshots
cd pitch-<slug>/
surge ./ pitch-<slug>.surge.sh                  # stable subdomain, re-deploy overwrites
curl -sS -o /dev/null -w "%{http_code}\n" https://pitch-<slug>.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 <iframe> 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 <style> 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.