PRD Drafter

What it takes in

The inputs you provide on each run, validated before anything executes.

3 tasks, run in order.

Each task passes its result to the next. Here's what each does and what it produces.

1. 01
   Distill the brief. From {{featureIdea}}, extract the core problem statement, the target users and the job they are trying to do, goals and explicit non-goals, and 3 to 5 measurable success metrics. If {{userContext}} is provided, ground the users, business rationale, and metrics in it. If {{constraints}} is provided, record every constraint as a hard boundary the PRD must respect. Do not invent users, metrics, or constraints the inputs do not support; where something is unknown, say so explicitly. Present this as a short, readable brief, never JSON.

   Expected output

   A short, readable product brief using headings and bullets, with no JSON and no code blocks: Problem Statement (2 to 3 sentences), Target Users (who they are and the job they are trying to do), Goals (bullets), Non-Goals (bullets), Success Metrics (3 to 5 measurable metrics), and Known Constraints (the recorded hard boundaries, or a note that none were provided).
2. 02
   Draft the PRD. Using the brief from Task 1, write a complete, review-ready PRD for {{featureIdea}}. Include: an overview, the problem and why now, user stories written as 'As a ..., I want ..., so that ...' each with concrete, testable acceptance criteria, functional requirements grouped by area, edge cases and error states, open questions for the team, and a launch checklist. Respect every constraint recorded in Task 1. Where a decision cannot be made from the inputs, add it to Open Questions instead of guessing. Present as a readable document, never JSON.

   Expected output

   A readable, review-ready PRD with no JSON and no code blocks, using these headed sections: Overview, Problem (including why now), User Stories (each in 'As a ..., I want ..., so that ...' form with Acceptance Criteria bullets), Functional Requirements (grouped by area), Edge Cases (including error states), Open Questions, and Launch Checklist (checkbox-style bullets).
3. 03
   Red-team the PRD. Review the PRD from Task 2 the way a hard-nosed reviewer would. List the 5 hardest questions a design, engineering, or leadership reviewer would ask about this PRD: the ones most likely to stall approval. For each, either answer it directly and convincingly from the inputs and the PRD, or flag it as an open risk with a concrete recommendation on how to resolve it before the review. Present readably, never JSON.

   Expected output

   A readable section titled Reviewer Red-Team with no JSON and no code blocks, containing exactly 5 numbered entries. Each entry has: Question (the hard reviewer question), and either Answer (a direct answer grounded in the inputs and the PRD) or Flag (why it cannot be answered yet plus a concrete recommendation to resolve it before review).