Full-lifecycle fundraising assistant for startup founders — guided workflow from readiness assessment through pitch practice with hyper-realistic VC simulations. Eight commands in a sequential flow: /before-fundraising → /product-metrics → /fundraising-strategy → /fundraising-stage → /pitch-deck → /pitch → /due-diligence → /deal-room, with an investor feedback loop that refines your strategy and deck after each pitch. Use this skill whenever the user mentions fundraising, raising money, pitch deck, VC meeting, investor pitch, Series A/B/seed, startup funding, term sheet, SAFE, valuation, dilution, or wants to practice pitching to investors. Also triggers on specific VC names like a16z, Sequoia, Benchmark, YC, Tiger Global, First Round, Accel, Lightspeed. Triggers on "should I raise", "fundraising readiness", "pitch practice", "investor metrics", "fundraising strategy".
A complete fundraising operating system for startup founders. Eight commands in a guided workflow — each step builds on the last, and after pitching you can loop back to refine your approach based on investor feedback.
Step 0: /before-fundraising — Assess readiness, understand your stage
Step 1: /product-metrics — Review your traction numbers (if product launched)
Step 2: /fundraising-strategy — Plan the raise (amount, structure, spending)
Step 3: /fundraising-stage — Create execution plan (optional)
Step 4: /pitch-deck — Build your pitch deck outline
Step 5: /pitch — Practice with simulated VCs, get feedback
↓
Investor feedback loop: refine strategy/deck → pitch again
↓
Step 6: /due-diligence — Prepare for investor DD (data, compliance, legal)
Step 7: /deal-room — Multi-VC process simulation (full fundraise)
When a user first triggers any fundraising command, show this orientation before proceeding:
Fundraising Skill — your fundraising co-pilot:
| Step | Command | What it does |
|---|---|---|
| 0 | /before-fundraising | Assess if you're ready to raise |
| 1 | /product-metrics | Review your traction & key numbers |
| 2 | /fundraising-strategy | Plan how much to raise & how |
| 3 | /fundraising-stage | Create an execution plan (optional) |
| 4 | /pitch-deck | Build your pitch deck outline |
| 5 | /pitch | Practice pitching to simulated VCs |
| 6 | /due-diligence | Prepare for investor due diligence |
| 7 | /deal-room | Multi-VC fundraising process simulation |
Start here: Run /before-fundraising to assess your fundraising readiness.
Then proceed to the requested command.
Every command must run this check before doing anything else. This is how users find out about new releases. Do not skip it.
_UPD=$( ~/.claude/skills/fundraising/bin/fundraising-update-check 2>/dev/null || echo "" )
This is a passive check: it uses a 30-minute cache to avoid hitting GitHub on every
single command invocation, so a newly-published release is discovered within 30 minutes
at most. For explicit user commands like /fundraising-upgrade, pass --force to bypass
the cache entirely and get a real-time answer.
Parse the output:
UPGRADE_AVAILABLE <old> <new> — Ask the user via AskUserQuestion before proceeding:
fundraising-skill v{new} is available (you have v{old}).
- Upgrade now
- Enable auto-upgrade (always stay up to date, never ask again)
- Skip this time
/fundraising-upgrade inline, then continue with the original command.auto_upgrade=true to ~/.fundraising-skill/config, run upgrade, continue.touch ~/.fundraising-skill/skip-session), continue.
The script won't ask again for 4 hours.AUTO_UPGRADE <old> <new> — User previously chose "Enable auto-upgrade." Skip the
prompt. Silently run the upgrade, then continue with the original command.
JUST_UPGRADED <old> <new> — User just finished an upgrade. Show the "What's New"
summary from CHANGELOG.md for the new version.
Empty or error — Skip silently. Never block the user's command for a failed update check. Common reasons: network offline, GitHub rate limit, cache hit with UP_TO_DATE.
Ask one question at a time. Do not dump a numbered form or a list of 5+ questions at the founder in a single message. For each piece of information you need, ask the single question, wait for the answer, acknowledge briefly, then ask the next one. Fundraising prep is a conversation, not a survey.
AskUserQuestion when there's a short list of discrete options (stage, domain, round
type, VC selection). Use a plain question for open-ended answers./product-metrics) should be broken
into logical chunks of 3-5 related questions, each chunk asked conversationally, not dumped
as one form.The exception: the final verdict/output of each command IS a long structured document. That's fine — structured output is good when you're delivering results. The rule applies to data collection, not to the assessment itself.
All commands use this single taxonomy:
| Canonical Stage | User-Facing Labels | VC Tier |
|---|---|---|
pre-seed | "I have an idea", "building MVP" | Seed tier |
seed | "MVP built, early users" | Seed tier |
series-a | "Proven PMF, scaling" | Series A/B tier |
series-b | "Repeatable growth" | Series A/B tier |
growth | "Market leader, Series C/D" | Growth tier |
late-stage | "Series E+, crossover investors, pre-IPO" | Late-stage / crossover tier |
ipo | "Preparing for IPO or recently public" | Public markets |
Every fundraising round lives in its own directory under .fundraising/. Each round has a
single living playbook.md — the complete fundraising guide updated by every command — plus
subdirectories for pitch transcripts and deal-room meeting logs.
This serves three purposes:
.fundraising/
├── {company-slug}-{stage}/ # one directory per round (default scenario)
│ ├── playbook.md # THE living playbook — all stages in one doc
│ ├── pitch-simulations/
│ │ ├── {vc}-{YYYY-MM-DD}.md # full pitch transcript (from /pitch)
│ │ └── ...
│ └── deal-room/
│ ├── meeting-{vc}-round-{N}.md # full meeting log (from /deal-room)
│ └── ...
├── {company-slug}-{stage}-{scenario}/ # optional: comparison scenario
│ └── playbook.md
└── archive/
└── round-{N}/
└── {company-slug}-{stage}/ # entire directory moved here on archive
Directory naming:
{company-slug}-{stage}/ (e.g., acme-seed/, stripe-series-a/){company-slug}-{stage}-{scenario}/ (e.g., acme-seed-aggressive/)company-slug = company name lowercased, spaces → hyphensscenario = short label chosen by the founder (e.g., conservative, aggressive, priced-round)playbook.mdThe playbook is both machine-readable (YAML frontmatter) and human-readable (narrative guide). Every command appends a new section; the document grows as the founder progresses.
Frontmatter (machine-readable state):
---