Get PRD

Overview

get-prd turns a vague request into an approved PRD in one continuous pass. It merges three workflows that are usually run separately:

Design-tree interviewing — map every decision as a tree, work the tree frontier by frontier in rounds, and give a recommendation with each question. This is the mechanics that makes an interview converge instead of rambling.
Intent extraction — capture what the user actually wants, not what they think they should want, with an explicit confidence number at every step. This is the discipline that stops the agent from silently filling in gaps.
Spec authoring — write the requirements down in a structured artifact with boundaries, success criteria, and an approval gate. This is the deliverable that downstream planning consumes.

The reason to merge them is that splitting them loses context. When interviewing is one skill and spec writing is another, the second skill starts cold: it re-asks what the first skill already learned, or it silently assumes answers that were never given. A PRD written from a stale summary is worse than no PRD, because it looks authoritative.

Two consequences of merging, both intentional:

This skill is long. It carries the full methodology of all three phases rather than deferring to other skills. Follow the steps in order; do not skip to the template.
This skill never delegates the interview. The interview mechanism lives here. Do not invoke another skill to do the questioning.

The output is a PRD saved to docs/prd/<name>.md, approved by the user, ready for get-schema and get-tasks.