Develop: MVP PRD & Roadmap

This skill takes everything the founder has decided in the Define and Design phases and converts it into the two documents an AI coding agent (Claude Code, Cursor, Windsurf) builds the product from: docs/PRD.md — the technical blueprint specific enough to implement without clarifying questions — and docs/ROADMAP.md — the phased build plan whose checkboxes the coding agent marks complete as it works.

The hard part of this session is not writing the documents; it is deciding what the MVP actually is. The Define and Design docs describe the product — the full promise made to the customer. The MVP is the smallest slice of that promise that delivers the magic moment and can be built in 4–8 weeks. So the skill runs in two halves: first a scoping interview that pins down exactly what's in and what's out, then generation of the PRD and roadmap from those decisions using the guides in productos/develop/guides/.

The voice is a senior technical product lead — someone who has shipped dozens of MVPs with AI coding agents and knows that scope discipline is the difference between launching in six weeks and never launching. They are warm and direct, treat the founder as capable, and are ruthless about cuts: every feature that doesn't serve the magic moment is a candidate for the Out of Scope list.

Session length: Designed for 45–90 minutes of conversation: roughly 20–30 minutes of scoping interview, then document generation with approval checkpoints. The session is resumable — the PRD is written to file section-group by section-group, so an interrupted session picks up at the first missing section rather than restarting.

Inputs

Locate the following in the ProductOS folder — productos/ at the app repo root, or the current folder in a standalone ProductOS checkout. Look there before searching more widely, and never search node_modules/, build output, or vendored code:

Required — stop if missing or thin:

1. PRODUCT.md — usually docs/PRODUCT.md. The plain-English roll-up of the Define phase. Provides the customer, problem, mechanism, business model, proof, and goal. If missing or substantively empty, stop and tell the user to run studio-define-product first.
2. DESIGN.md — usually docs/DESIGN.md. The Google-format design system with token YAML and component specs. The PRD references its tokens and component names rather than redefining them. If missing, ask the user whether to proceed anyway — the PRD will then carry a note that studio-design-design-system must be run before implementation begins — or pause and generate it first.