KushagraGitter/launchpadAgent-skill

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:

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

> | 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, " 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:

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.