PRD Partner

An agent that creates detailed, actionable Product Requirements Documents for software development teams, covering feature specifications, user stories, acceptance criteria, and technical constraints through structured stakeholder collaboration.

When to Use This Agent

Choose PRD Partner when:

• Defining product requirements for new features or products
• Translating stakeholder conversations into structured specifications
• Creating user stories with detailed acceptance criteria
• Documenting technical constraints and dependencies for engineering teams
• Building consensus on feature scope and prioritization

Consider alternatives when:

• Writing technical architecture documents (use an architecture agent)
• Creating API specifications (use OpenAPI tooling)
• Building project plans with timelines (use project management tools)

Quick Start

Copy
# .claude/agents/prd-partner.yml
name: PRD Partner
model: claude-sonnet-4-20250514
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
prompt: |
  You are a senior product manager. Create detailed, actionable
  PRDs that engineering teams can implement without ambiguity.
  Include user stories, acceptance criteria, wireframe descriptions,
  and technical constraints. Ask clarifying questions when
  requirements are ambiguous.

Example invocation:

Copy
claude --agent prd-partner "Create a PRD for a user notification
  preferences system - users should be able to configure which
  notifications they receive, through which channels, and at
  what frequency"

Core Concepts

PRD Structure

Copy
# PRD: {Feature Name}

## 1. Overview
- Problem statement
- Target users
- Business justification
- Success metrics

## 2. User Stories
- As a [persona], I want [goal] so that [benefit]
- Acceptance criteria per story

## 3. Functional Requirements
- Feature specifications
- User flows
- Edge cases and error states

## 4. Non-Functional Requirements
- Performance targets
- Security requirements
- Accessibility standards
- Scalability expectations

## 5. Technical Constraints
- Platform limitations
- Integration dependencies
- Data migration needs

## 6. Out of Scope
- Explicitly listed exclusions

## 7. Open Questions
- Unresolved decisions needing stakeholder input

User Story Format

Copy
### US-001: Configure Email Notification Preferences

**As a** registered user
**I want to** choose which email notifications I receive
**So that** I only get emails that are relevant to me

**Acceptance Criteria:**
- [ ] User can access notification preferences from account settings
- [ ] All notification categories are listed with toggle switches
- [ ] Changes save immediately without a separate save button
- [ ] User receives a confirmation toast after changes are saved
- [ ] Default state for new users: all notifications enabled

**Edge Cases:**
- User disables all notifications → show warning but allow
- User has no verified email → show verification prompt first

Requirements Priority Matrix

Priority	Label	Definition	SLA
P0	Must Have	Launch blocker	Must ship
P1	Should Have	Important but not blocking	Target for launch
P2	Nice to Have	Enhances experience	Next iteration
P3	Future	Backlog item	Not scheduled

Configuration

Parameter	Description	Default
output_format	PRD document format	Markdown
output_path	File location for generated PRD	prd.md
include_wireframes	Add ASCII wireframe mockups	true
story_format	User story template style	Standard (As a/I want/So that)
priority_system	Priority labeling scheme	P0-P3
include_metrics	Add success metrics section	true
review_checklist	Append review checklist	true

Best Practices

1. Start with the problem, not the solution. The overview section should convince a skeptical reader that the problem is worth solving before describing any features. Include data: "23% of users contact support about notification overload, costing $X per month in support time." A well-articulated problem statement prevents scope creep because every feature can be evaluated against it.

2. Write acceptance criteria that are testable by QA. Each criterion should be verifiable with a specific test: "User can toggle email notifications off → verify no emails are sent for 24 hours after toggle." Avoid subjective criteria like "notifications should be fast" in favor of measurable ones like "notification delivery within 30 seconds of trigger event." QA should be able to write test cases directly from your acceptance criteria.

3. Document what's explicitly out of scope. Unstated assumptions create the most friction between product and engineering. If you're building notification preferences but not building the notification delivery system, say so. If mobile push notification preferences are planned for phase 2, document that. Out-of-scope sections prevent engineers from building features you didn't ask for and stakeholders from expecting them.

4. Include error states and edge cases for every user flow. The happy path is easy. What happens when the API is down? When the user has no internet? When they have 10,000 notifications? Product specs that skip edge cases push design decisions onto engineers who may not have the product context to make them correctly. Document expected behavior for at least the five most likely error scenarios.

5. Keep an open questions section and resolve it before development starts. Unresolved questions during development create blocking dependencies that slow engineering. Track every decision that needs stakeholder input, assign an owner, and set a deadline. Convert resolved questions into requirements. If a question can't be resolved before development, document the assumption you're making and the trigger for revisiting it.

Common Issues

PRD is too vague for engineers to implement. This happens when requirements use ambiguous language: "the page should load quickly" or "the UI should be intuitive." Replace every vague statement with a specific, measurable requirement. Pair written requirements with wireframes or mockups that show exact layout, state transitions, and component behavior. Schedule a PRD walkthrough with the engineering team before development starts.

Scope creeps during development despite a clear PRD. Establish a change request process: any new requirement goes through a quick impact assessment (effort, timeline impact, dependencies) before being added. Use the out-of-scope section as a shield: "that's documented as out of scope for this phase, but it's tracked for phase 2." Tag each requirement with a priority so that if the timeline is compressed, the team knows what to cut.

Stakeholders disagree on requirements after PRD is approved. Surface disagreements early by circulating the PRD draft to all stakeholders with a review deadline. Hold a single review meeting where conflicting requirements are discussed and resolved. Document the decision and the rationale. If consensus is impossible, escalate to the decision-maker named in the PRD and record their decision as final for this iteration.