launchpad

# LaunchPad — idea → validated plan → buildable context This skill reproduces the LaunchPadAI agent pipeline without its backend. You play each specialist agent in turn, write each output to disk, and feed earlier outputs into later ones. The value of the pipeline comes from three things — keep all three even when abbreviating: 1. **Specialist framing.** Each step has a distinct role with a distinct bias (the Assumption Challenger is a skeptic; the Opportunity Mapper looks sideways at substitutes). Writing each step separately, in its role, produces sharper work than one blended "analyze this idea" pass. 2. **Evidence grounding.** Research steps use web search and cite URLs. Fabricated competitors, market numbers, or funding rounds destroy the value of the whole plan, because every downstream phase inherits them. If search is unavailable or returns nothing useful, say so and label figures as estimates. 3. **Context continuity.** Each phase reads the prior phases' final documents. The PRD must reflect the personas and risks found in Validation; the architecture must implement the PRD's MVP scope, not a generic app. ## Phases | # | Phase | Steps (→ = depends on) | Final doc(s) | Reference | |---|-------|------------------------|--------------|-----------| | 0 | Discovery | problem → assumptions → opportunity → brief | `BRIEF.md` | `references/discovery.md` | | 1 | Validation | market, competitors, feasibility, personas (independent) → synthesis → benchmark | `VALIDATION_REPORT.md`, `BENCHMARK.md`, `benchmark.json` | `references/validation.md` | | 2 | PRD | requirements, user stories (independent) → prioritization, UX flows → PRD | `PRD.md` | `references/prd.md` | | 3 | Coding Context | architecture, schema (independent) → tasks, rules file → package | `CODING_CONTEXT.md` + rules file | `references/coding-context.md` | Read only the reference file for the phase you are running — each contains the role and deliverable spec for every step in that phase. ## Getting started 1. **Collect the project inputs.** You need: project name, the raw idea (a few sentences is fine), and optionally domain, target audience, and founder background (the benchmark scores founder-market fit — without background, score it conservatively and say why). Ask once for anything missing that matters; don't interrogate. 2. **Decide scope.** Default: run Phase 0 → 1, then pause. If the user asked for a specific phase ("just write a PRD"), start there — but check for prior-phase docs first. If none exist, either run a compressed version of the missing earlier phases (say so) or proceed with the idea alone and flag in the output which inputs were assumed rather than researched. 3. **Create the workspace** in the current directory (unless the user names another place): ``` launchpad/<project-slug>/ 00-discovery/ problem.md assumptions.md opportunity.md BRIEF.md 01-validation/ market-size.md competitors.md feasibility.md personas.md VALIDATION_REPORT.md benchmark.json BENCHMARK.md 02-prd/ requirements.md user-stories.md prioritization.md ux-flows.md PRD.md 03-coding-context/ architecture.md schema.md tasks.md CLAUDE.md|.cursorrules CODING_CONTEXT.md project.md name, idea, domain, audience, founder background, feedback log ``` Write `project.md` first. If a workspace for this project already exists, reuse it — read what's there and continue rather than starting over. ## Running a step Every step's prompt is conceptually: ``` Project: <name> Idea: <raw idea> Domain / Audience (if known) --- Prior Phase Context --- final docs of earlier phases (see below) --- Prior Step Outputs --- outputs of the steps this one depends on --- User Feedback --- if re-running after feedback --- Your Task --- role + deliverable spec from the reference file ``` **Prior phase context** (replaces the platform's pgvector retrieval): - Validation reads `BRIEF.md`. - PRD reads `BRIEF.md`, `VALIDATION_REPORT.md`, `BENCHMARK.md`, and `personas.md`. - Coding Context reads `PRD.md` and `feasibility.md`, plus `BRIEF.md` for scope. **Every output file starts with a metadata header**, then the full analysis: ```markdown > **Headline:** <the single most important finding, as a complete specific sentence — the "so what", not the topic> > > **Key takeaways** > - <most important finding> > - <second> > - <third> (max 5) ``` Final/synthesis docs (`BRIEF.md`, `VALIDATION_REPORT.md`, `PRD.md`, `CODING_CONTEXT.md`) also add a scorecard of 3–5 metrics inside that header: ```markdown > | Metric | Value | | > |---|---|---| > | Problem severity | 8/10 | 🟢 | > | Competitive density | High | 🔴 | ``` (🟢 strong/positive, 🟡 moderate/uncertain, 🔴 weak/concerning.) The header exists so a reader skimming 20 documents gets the conclusion of each in five seconds. **Research steps** (marked 🔎 in the references): run several targeted web searches — not one generic query — e.g. competitor names + pricing, "<problem> reddit", market reports with years. Cite inline as `[1]` with a `## Sources` list of URLs at the end. **Parallelism.** Steps marked independent can run as parallel subagents if the Agent tool is available — give each subagent the project inputs, the prior-phase context file paths, its section of the reference file, and the output path. Otherwise run them sequentially yourself. Either way, synthesis steps run only after their inputs exist, and they read the full files, not summaries. ## The benchmark score After `VALIDATION_REPORT.md`, write `benchmark.json` (schema in `references/validation.md`), then run: ```bash python3 <skill-dir>/scripts/benchmark_score.py launchpad/<slug>/01-validation/benchmark.json "<Project Name>" ``` It recomputes `overall_score` with the fixed weights (so scores are comparable across projects and not hand-waved), rewrites the JSON, and writes `BENCHMARK.md` next to it. Be calibrated: most ideas land at 4–6 and the 40th–65th percentile. A benchmark where everything is 8+ is a sign of cheerleading, not analysis. ## Between phases After each phase, stop and give the user a short summary in chat: the final doc's headline, the scorecard, the verdict (Validation), and the 2–3 things most likely to change their mind. Then ask whether to continue, revise, or stop. Don't barrel through all four phases unasked — a "Needs Rethinking" verdict should be a real decision point, and the user may want to pivot the idea before a PRD is written around it. If the user gives feedback on a phase, append it to the feedback log in `project.md`, re-run only the affected steps plus the phase's synthesis step with the feedback in context, and overwrite those files. ## Finishing When Coding Context completes, tell the user which files to copy into their new repo: `CODING_CONTEXT.md` and the rules file (`CLAUDE.md` for Claude Code, `.cursorrules` for Cursor, `AGENTS.md` for other agents — ask which tool they use if unclear; default to `CLAUDE.md`), plus `tasks.md` as the build backlog.