Project Launcher Plugin for Claude Code: PRD to Scaffold
On this page
Project Launcher is a Claude Code plugin that runs a six-phase pipeline — research, requirements interview, PRD plus visual plan, critical gap analysis, project scaffolding, and GSD v2 handoff — turning a rough project idea into a stress-tested spec and a ready-to-build directory, instead of the scattered docs and half-configured folders that usually pass for "starting a project."
What problem does Project Launcher solve?
Starting a project usually means a half-written doc, a few Slack messages, and a folder someone mkdir'd and never finished configuring. Project Launcher replaces that improvisation with a fixed, repeatable sequence: research the problem first, ask only the questions research couldn't answer, write a spec detailed enough for an autonomous agent to build from, and stress-test it before anyone writes code.
We built this plugin because at Rhize Media we kept re-litigating the same setup work every time we started a new automation, web app, or content system — research done inconsistently (or skipped), a PRD that looked complete but had obvious holes, and a project directory that needed manual cleanup before GSD v2 could safely take over. Project Launcher is one plugin inside Rhize plugins for Claude Code, our public marketplace, and it's the one we reach for anytime "let's build this" needs to turn into something an autonomous agent can actually execute against.
How does Project Launcher work?
Project Launcher works through two skills and five commands. Skills are reference knowledge Claude loads automatically when your request matches a trigger phrase — you don't invoke them directly. Commands are actions you run explicitly with a slash prefix, and each one executes a specific slice of the pipeline, so you can run the whole thing or jump in partway through.
The project-launcher skill holds the full six-phase methodology: where to source research (vault, codebase, docs, MCP servers), the interview question bank, the PRD template, the gap-analysis categories, the CLAUDE.md/.planning/ scaffolding structure, GSD v2 installation, and the handoff checklist. It also knows which MCP servers and skills to reach for at each phase, and it safety-gates any additional skill it suggests once scaffolding starts — refusing anything rated HIGH or CRITICAL risk rather than silently adding an unvetted skill because it looked relevant to your stack.
The second skill, rhize-visual-plan, activates automatically inside Phase 3 right after the PRD draft exists, and it's also usable on its own for any risky or multi-file plan that deserves a real review artifact instead of a chat wall of text. It knows the Rhize plan.mdx component vocabulary — <Diagram>, <FileMap>, <DataModel>, <ApiEndpoint>, <Wireframe>, <Canvas>, <Decision>, <OpenQuestions> — and the rhize-plan CLI for live preview and self-contained HTML export. When a plan doesn't need diagrams (architecture-only or copy-only work, for instance), it deliberately skips the visual surface rather than forcing chrome onto something that doesn't need it.
What commands does Project Launcher ship?
| Command | What it does |
|---|---|
| /launch-project <project idea> | Runs the complete 6-phase pipeline: research → interview → PRD + visual plan → gap analysis → scaffold → GSD handoff. Leave off the idea and Claude asks what you want to build before starting Phase 1. |
| /write-prd <project idea> | Runs phases 1-4 only — research, interview, PRD + visual plan, gap analysis — and stops before scaffolding. For when you want a stress-tested PRD but aren't ready to commit to a directory yet. |
| /grill-prd <path to PRD> | Runs Phase 4 (critical gap analysis) standalone against a PRD you already have, whether it came from /write-prd or somewhere else. Produces a -v2 version with resolved gaps incorporated. |
| /scaffold-gsd <path to PRD or project dir> | Runs phases 5-6 — creates the project directory, CLAUDE.md, .planning/ docs, installs GSD v2, and runs the handoff checklist. Assumes an approved, gap-tested PRD already exists. |
| /visual-plan <PRD path, plan, or task description> | Invokes rhize-visual-plan directly on any plan — not just a project-launcher PRD — producing a reviewable plan.mdx with diagrams, wireframes, and file maps. |
What happens at each phase of the pipeline?
Each phase produces exactly what the next phase needs, so you never repeat yourself between research, the interview, and the PRD.
- Research. Before asking you anything, Claude checks your Obsidian vault, scans related codebases, pulls external docs, and queries whatever MCP servers are relevant — Jira, Slack, DataForSEO, Google Drive, and more — so it shows up to the interview already informed.
- Requirements interview. Claude asks only what research couldn't answer, in batches of 5-10 questions grouped by theme: architecture, constraints, integrations, scope, quality bar. The question bank behind this phase covers 65 questions across 11 domains, so the batches you actually see are a targeted subset, not the whole bank.
- PRD + visual plan. Claude writes the full Product Requirements Document — a 14-section spec that's the machine-readable source GSD builds from — then renders it into
plan.mdx, the human-friendly review surface with diagrams, file maps, and data contracts. You review and approve the visual plan, not the raw PRD.
- Critical gap analysis. The PRD gets stress-tested for failure modes, missing error handling, scalability assumptions, security gaps, and cost estimates before anyone scaffolds anything. This produces PRD v2, and the visual plan refreshes to match it.
- Project scaffolding. Claude creates the actual project directory:
CLAUDE.md,.planning/(PROJECT.md,REQUIREMENTS.md,ROADMAP.md,STATE.md), the GSD v2 framework, and deliverable directories. If the project uses the Rhize Next.js stack, scaffolding also offers hookify guardrails — a starter rule set that blocks direct pushes to main and leaked secrets — which is worth accepting.
- GSD v2 handoff. A final checklist confirms the PRD, the approved plan, and the scaffolded directory all agree, then Claude briefs you on how to kick off
/gsd:autonomous.
Underneath all six phases sits a fairly deep integration list: MCP servers for Obsidian, Firecrawl, Context7, DataForSEO, Slack, Google Drive, Atlassian, Sentry, PostHog, Sequential Thinking, Serena, and n8n (both the builder and executor), plus external skills like grill-me for the gap analysis, write-a-prd for PRD generation, tdd for phases 5-6, and prd-to-issues for turning an approved PRD into GitHub issues. A SessionStart hook loads the command menu automatically, and a PreToolUse hook watches for PRD, requirements, research, and roadmap files being written — if you have an Obsidian vault, it nudges Claude to also save the artifact there using second-brain methodology (wikilinks, tags, MOC links). Hooks fail silently and never block your work; the vault check is purely path-based.
Example prompts
- "I want to build a tool that syncs our Slack standup notes into Notion" — Claude starts Phase 1 research on both platforms' APIs before asking you anything.
/launch-project a Slack bot that posts weekly PostHog metrics to #product— runs the full pipeline end to end, from research through GSD handoff, for a well-scoped automation idea.- "let's plan a new n8n workflow project for lead enrichment" — Claude recognizes the automation project type and pulls the automation-specific interview questions instead of generic ones.
Who should use Project Launcher?
Anyone who regularly starts new projects — automations, web apps, content systems, integrations — and wants the research-to-scaffold setup work done consistently instead of reinvented each time. It's built for the moment right before code gets written: you have an idea, or a rough plan, and you need it turned into something specific enough that an autonomous agent (or a teammate) can build from it without guessing. It's also useful on its own terms if you just want a PRD stress-tested (/grill-prd) or a messy plan turned into a real review artifact (/visual-plan), without running the rest of the pipeline.
What keeps a launched project honest after scaffolding?
Scaffolding hands off to GSD v2, but Project Launcher's influence doesn't stop at the handoff checklist. After each GSD phase, the autonomous Claude runs a fixed post-phase verification pattern: /sc:reflect on whether all tasks were implemented and then /simplify your code changes where needed for an optimal solution. That means every phase of autonomous build work gets checked against the original plan and cleaned up before the next phase starts, rather than accumulating drift that only surfaces at the end.
A few habits make the rest of the pipeline hold up in practice. Let Phase 1 finish before you answer anything — if Claude jumps straight to questions without mentioning what it found in your vault or codebase, research was skipped, and it's worth asking it to redo that step first. Run /grill-prd even on a PRD you're confident in; the value isn't catching typos, it's forcing answers on failure modes and cost questions you'd otherwise discover mid-build, at a far more expensive point in the process. And don't feed /scaffold-gsd a PRD that hasn't been through gap analysis — the scaffolding command assumes it's reading the stress-tested version, so skipping straight there just relocates the same gaps into autonomous execution instead of catching them before it starts.
How do you get started?
Install the plugin from the Rhize plugins marketplace — Rhize-Media/rhize-plugins — with /plugin marketplace add https://github.com/Rhize-Media/rhize-plugins in Claude Code, or through Settings > Plugins > Add Marketplace in Cowork. From there, /launch-project <your idea> is the fastest way to see the whole pipeline in action. For more on how Project Launcher fits alongside the rest of the catalog, see Rhize plugins for Claude Code and the broader work at rhize.media.
Frequently Asked Questions
Do I have to run the full six-phase pipeline every time?
What's the difference between the PRD and the visual plan?
Why does gap analysis matter if my PRD already looks solid?
What if /scaffold-gsd won't proceed?
Want this working in your business — not just on paper?
Book a 15-min call and we'll map exactly where your business depends on you, and what to fix first. No pitch — you leave with a plan either way.
Book a 15-min callGet insights like this in your inbox
Join our newsletter for actionable SEO, marketing, and growth strategies — no fluff, just results.
No spam. Unsubscribe anytime.