Write PRD
Translate a product decision into a product contract. Keep implementation detail proportional to the decision being made.
Workflow
- Gather the problem, target user, current workflow, desired outcome, evidence, constraints, and decision owner from the conversation and available artifacts.
- Ask only for missing decisions that materially change the product, scope, or success criteria. Otherwise state assumptions and draft.
- Inspect the existing product or repository when relevant so the PRD uses its domain language and does not propose something already present.
- Define goals, measurable success criteria, user flow, requirements, acceptance criteria, and explicit non-goals.
- For AI features, define the human outcome, failure modes, evaluation set, quality threshold, latency/cost boundaries, fallback, and data handling. Mark unknown targets
TBD; do not invent numbers.
- Define rollout, instrumentation, dependencies, risks, and unresolved product decisions.
- Return or save the PRD where the repository already keeps product documents. Do not publish to a remote tracker unless the user asked.
Output
# <Product or Feature> PRD
## Executive Summary
Problem, target user, proposed outcome, and why now.
## Evidence and Current Workflow
Observed pain, existing alternatives, and source evidence.
## Goals and Success Criteria
Measurable outcomes, baselines, targets, and timeframe where known.
## Users and User Flow
Primary user, context, happy path, and important failure paths.
## Scope
In scope:
Out of scope:
## Requirements and Acceptance Criteria
Observable product behavior, ordered by priority.
## AI Requirements
Include only when applicable: evaluation, failure handling, cost/latency, privacy, fallback.
## Rollout and Instrumentation
Release stages, safeguards, events, dashboards, and decision gates.
## Dependencies and Risks
Product, design, engineering, policy, and go-to-market dependencies.
## Open Decisions
Owner and consequence of each unresolved choice.
Quality Gates
- Replace vague words such as "fast", "easy", or "intuitive" with observable behavior.
- Keep product requirements separate from speculative architecture.
- Make non-goals strong enough to prevent scope creep.
- Use
$backlog-ready-spec after the PRD when implementation readiness must be verified.
1---2name: write-prd3description: Write a concise, measurable product requirements document for a new product, feature, or AI capability. Use when a validated product direction needs a shared contract for users, scope, outcomes, requirements, rollout, and risks.4---56# Write PRD78Translate a product decision into a product contract. Keep implementation detail proportional to the decision being made.910## Workflow11121. Gather the problem, target user, current workflow, desired outcome, evidence, constraints, and decision owner from the conversation and available artifacts.132. Ask only for missing decisions that materially change the product, scope, or success criteria. Otherwise state assumptions and draft.143. Inspect the existing product or repository when relevant so the PRD uses its domain language and does not propose something already present.154. Define goals, measurable success criteria, user flow, requirements, acceptance criteria, and explicit non-goals.165. For AI features, define the human outcome, failure modes, evaluation set, quality threshold, latency/cost boundaries, fallback, and data handling. Mark unknown targets `TBD`; do not invent numbers.176. Define rollout, instrumentation, dependencies, risks, and unresolved product decisions.187. Return or save the PRD where the repository already keeps product documents. Do not publish to a remote tracker unless the user asked.1920## Output2122```markdown23# <Product or Feature> PRD2425## Executive Summary26Problem, target user, proposed outcome, and why now.2728## Evidence and Current Workflow29Observed pain, existing alternatives, and source evidence.3031## Goals and Success Criteria32Measurable outcomes, baselines, targets, and timeframe where known.3334## Users and User Flow35Primary user, context, happy path, and important failure paths.3637## Scope38In scope:39Out of scope:4041## Requirements and Acceptance Criteria42Observable product behavior, ordered by priority.4344## AI Requirements45Include only when applicable: evaluation, failure handling, cost/latency, privacy, fallback.4647## Rollout and Instrumentation48Release stages, safeguards, events, dashboards, and decision gates.4950## Dependencies and Risks51Product, design, engineering, policy, and go-to-market dependencies.5253## Open Decisions54Owner and consequence of each unresolved choice.55```5657## Quality Gates5859- Replace vague words such as "fast", "easy", or "intuitive" with observable behavior.60- Keep product requirements separate from speculative architecture.61- Make non-goals strong enough to prevent scope creep.62- Use `$backlog-ready-spec` after the PRD when implementation readiness must be verified.
cogine-ai