How to Turn a Project Idea Into a PRD in Claude Code

You can turn a project idea into a PRD in Claude Code by asking it to research the problem, clarify missing requirements, draft the specification and challenge its assumptions before coding. The Project Launcher plugin supplies that sequence. Start with its PRD-only path when you need a reviewable specification rather than a new project directory.

What problem does Project Launcher solve?

The plugin makes a project-start process explicit: research the problem, clarify missing information, write a PRD and challenge it before implementation. The useful output is a specification a person or agent can review, not a guarantee that autonomous execution will require no further decisions.

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 provides two skills and five commands in the current repository. Skills contain the working instructions; commands provide explicit entry points. You can ask for the process in natural language or use a namespaced command so the intended plugin is unambiguous.

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 visual-plan skill can turn a plan into a review surface with diagrams, file relationships and data contracts where those help. The PRD remains the source specification. Use a visual view to make decisions easier to inspect, not as a substitute for clear acceptance criteria.

What commands does Project Launcher ship?

What happens at each phase of the pipeline?

Each phase should leave evidence for the next: sources, open questions, decisions and acceptance tests. Revisit a previous phase when new information changes the requirements rather than forcing an incomplete answer forward.

1. Research. Ask Claude to inspect the authorized codebase, existing documents and relevant official references first. Connected tools such as a vault or Jira can add context, but they are optional; the assistant should state which sources were unavailable.
2. Requirements interview. Ask the unresolved questions in manageable groups: users, scope, architecture, integrations, constraints and acceptance criteria. The plugin provides a question bank; use the relevant questions rather than asking every possible one.
3. PRD and review view. The plugin provides a structured PRD template. Check the users, scope, exclusions, integrations, failure behavior, data ownership and acceptance tests. A visual plan can accompany it when a diagram or flow makes those decisions easier to review.
4. 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.
5. Project scaffolding. Only after the PRD is reviewed, the scaffold path prepares project instructions and planning documents. Review any proposed dependency or configuration changes. Scaffolding is an additional step, not a requirement for writing a PRD.
6. GSD handoff. The released launcher has a separate typed-provider dependency for its full build handoff. The current README pins GSD 1.42.3 and documents /gsd-autonomous. Its readiness check requires a successful configured provider probe; without that evidence the assistant must not claim the build handoff is ready. The PRD-only path remains the appropriate stopping point when you only need a specification.

Optional integrations extend the research and planning phases, but installing this plugin does not provision a full agency tool stack. Connect only the sources needed for the task and keep credentials out of the PRD. The current plugin has an advisory vault-hint hook; its old standalone SessionStart command banner has been removed.

Example prompts

• Example brief: "Write a PRD for a weekly metrics digest. The reader is our operations lead. Use approved PostHog exports, save a draft to our existing workspace and require approval before Slack delivery. No new database. List missing access and define a test using one sample week." This gives the research and interview stages a concrete boundary.
• For the PRD-only path, use /project-launcher:write-prd followed by the idea and constraints. Review the generated requirements and gap analysis before asking for implementation. Use /project-launcher:launch-project only when you also intend to prepare the project and satisfy its handoff dependencies.
• "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?

The project still needs execution checks after scaffolding. Compare implemented behavior with the approved requirements, run relevant tests, review the diff and record remaining failures. The launcher's suggested post-phase review pattern is guidance; verify that the chosen host and installed tools actually execute it.

Review the research sources and unresolved questions before approving the PRD. Use /project-launcher:grill-prd to challenge failure modes, costs and missing requirements. Use /project-launcher:scaffold-gsd only after the specification is reviewed and you intend to prepare the full project; verify its current dependency and handoff requirements first.

How do you get started?

In Claude Code, add the marketplace with /plugin marketplace add https://github.com/Rhize-Media/rhize-plugins, then /plugin install project-launcher@rhize-plugins and start a fresh session. Run /project-launcher:write-prd with a bounded idea. Keep the README nearby for current dependencies and handoff instructions: https://github.com/Rhize-Media/rhize-plugins/tree/main/project-launcher