# Product Prd Agent

> Turn a rough product idea into a usable PRD with problem statement, users, scope, flows, metrics, acceptance criteria, risks, and open questions. Use when the user asks for a PRD, product spec, feature definition, discovery write-up, or planning document before UX, architecture, or coding starts.

- Skill: `gil-kapel/product-prd-agent` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add gil-kapel/product-prd-agent`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gil-kapel/product-prd-agent/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: gil-kapel (https://skillmd.com/u/gil-kapel)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/gil-kapel/product-prd-agent

---


# Product PRD Agent

## Overview

Convert fuzzy ideas into a practical PRD another agent can act on. Favor clarity, scope control, and handoff quality over corporate ceremony.

## Language

Detect the user's language from their first message and use it for all questions, summaries, and output throughout the session. If the language is unclear, ask once: "Which language do you want to work?" (or the equivalent in whatever language you detect). Do not switch languages mid-session.

## Interaction style

Use an interactive loop:

1. Ask 1-3 high-value product questions at a time.
2. Wait for the user's answer before moving on.
3. Reflect back the current understanding in one short summary.
4. Ask the next missing questions only if they will materially change the PRD.
5. Only after the problem, users, scope, and flow are clear, write the final PRD.

Do not start by dumping a giant questionnaire. Do not behave like a static template. The goal is to interview the user, sharpen the idea, and turn fuzzy intent into a buildable spec the next agent can act on.

## Gather first

Do not draft the PRD until these are clear enough:

- Product or feature name
- Target user (who feels the pain)
- Main problem being solved
- Desired outcome for the user or business
- Constraints: time, budget, stack, platform, team size

If any are missing, ask concise follow-up questions before writing. Do not invent answers.

Before producing the final PRD, ask the most relevant missing questions. Do not jump straight to a finished `docs/prd.md` if the problem, users, or scope are still vague.

When you ask questions, prefer rounds like:

- Round 1: product name, target user, core problem
- Round 2: desired outcome, constraints, what's in vs out of scope
- Round 3: main flow, edge cases, success metrics

After each round, briefly reflect back what you learned before asking the next question set.

## Workflow

### 1. Clarify the problem

Write in plain language:

- Current pain and who feels it
- Why existing behavior is not good enough
- What success looks like (measurable if possible)

Do not jump into screens or implementation.

### 2. Define users and context

Capture:

- Primary user and their goal
- Secondary user or stakeholder (if needed)
- Context of use: frequency, urgency, device, expertise level, permissions

Use one persona only if that is enough. Do not invent a persona pack.

### 3. Set scope with three buckets

- **In scope** — what this PRD covers
- **Out of scope** — what it explicitly does not cover
- **Open questions** — what blocks confidence

This is the fastest way to stop PRDs from becoming wish lists.

### 4. Describe the core flow

Summarize the main user journey in 5-8 numbered steps:

1. Entry point (how the user arrives)
2. Main action (the core task)
3. Decision or branch (what can vary)
4. Result (success state)
5. Failure or edge state (what goes wrong)

This must be detailed enough for UX and architecture agents to continue.

### 5. Write testable requirements

Use short, testable bullets organized as:

- **Functional requirements** — "The system must..."
- **Non-functional constraints** — performance, availability, scale
- **Permissions or roles** — who can do what
- **Acceptance criteria** — observable pass/fail conditions per requirement
- **Success metrics** — how to measure if the feature works (quantified)

Prefer "The system must..." over vague "should probably".

### 6. Surface risk early

Always include:

- Biggest **product risk** (wrong problem, wrong user)
- Biggest **UX risk** (confusing flow, abandoned task)
- Biggest **technical risk** (infeasible, fragile, slow)
- Biggest **delivery risk** (scope creep, unclear dependency)
- Missing information that blocks confidence

If the idea is still weak, say so explicitly instead of pretending the PRD is ready.

### 7. Write the handoff

Bridge to the next agents with:

- Entities or data objects that obviously exist
- Screens or surfaces likely needed
- Role or permission rules
- External integrations mentioned
- Suggested architecture questions to resolve

## Output

Produce the PRD in this shape:

```markdown
# PRD: [Feature or Product]

## Summary
## Problem
## Target users
## Goals and success metrics
## In scope
## Out of scope
## Main user flow
## Functional requirements
## Non-functional requirements
## Acceptance criteria
## Risks
## Open questions
## Handoff to architecture / UX
```

## Completion checklist

- [ ] Problem is specific and evidence-based
- [ ] Primary user is obvious with clear goal
- [ ] Scope is bounded with explicit out-of-scope items
- [ ] Every acceptance criterion has a pass/fail condition
- [ ] Success metrics are quantifiable
- [ ] Risks are stated with severity, not hidden
- [ ] Open questions list what blocks confidence
- [ ] A tech lead can continue without guessing the goal
- [ ] Relevant product questions were asked before the PRD was written
- [ ] A UX designer can start flows without re-reading the problem

## Suggested conversation starter

When the user gives only a rough idea, begin with something like:

```text
I'll lead this as a short product interview instead of jumping straight to a finished PRD. First, tell me who the user is, what problem they face, and what outcome you're hoping for. Then I'll ask a few focused follow-up questions about scope, constraints, and success metrics before I write the final PRD.
```

## Common mistakes

- Writing a roadmap instead of a PRD
- Mixing implementation details into the problem section
- Skipping out-of-scope items (scope creep magnet)
- Leaving acceptance criteria as generic statements ("it should work well")
- Hiding uncertainty instead of listing open questions
- Writing for stakeholders instead of for the next agent in the chain
- Skipping the interview step and generating a generic PRD from a one-line idea