# Prd

> Product Requirements Document — specify and verify before implementing

- Skill: `andrem-sec/prd` (Agent Skill)
- Install (CLI): `npx skillmds@latest add andrem-sec/prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/andrem-sec/prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: andrem-sec (https://skillmd.com/u/andrem-sec)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/andrem-sec/prd

---


# PRD Skill

Define what to build and how to verify it before writing a line of code. The output is a confirmed specification that plan-first uses as its source of truth.

## What Claude Gets Wrong Without This Skill

Without a PRD, implementation begins on an implicit spec. The spec lives only in the user's head and Claude's initial interpretation. When they diverge — and they always diverge on complex features — the mismatch is discovered at the end of implementation, not the beginning.

## The Acceptance Criteria Quality Gate

Auto-generated acceptance criteria are deliberately generic. They must be replaced with task-specific, independently verifiable criteria before the PRD is confirmed.

**WRONG (scaffold — reject these):**
```
- Implementation is complete
- Code compiles without errors
- Feature works as expected
```

**RIGHT (specific, verifiable):**
```
- POST /api/orders returns 201 with order ID when payload is valid
- POST /api/orders returns 422 with field-level errors when required fields are missing
- Order is written to orders table with status="pending" and timestamp within 1s of request
- Test file exists at tests/api/test_orders.py and all tests pass
```

The test: can you write a passing/failing test for this criterion without asking any clarifying questions? If yes, it is a good criterion. If no, refine it.

## PRD Format

```
## PRD: [feature name]
Date: [date] | Status: DRAFT → CONFIRMED

### Goal
[One sentence — what problem does this solve?]

### Scope
In: [explicit list of what is included]
Out: [explicit list of what is excluded]

### Acceptance Criteria
1. [Specific, verifiable criterion]
2. [Specific, verifiable criterion]
3. [Specific, verifiable criterion]

### Dependencies
- [What must exist before this can be built]

### Open Questions
- [Anything that needs resolution before starting]

### Confirmation
Confirmed? (yes / modify / no)
```

## Pipeline

After PRD is confirmed, pass it directly to plan-first. The plan should reference the acceptance criteria by number.

## Anti-Patterns

Do not start implementing while the PRD is still in DRAFT status.

Do not accept criteria you cannot write a test for. Push back and refine until each criterion is independently verifiable.

Do not include implementation details in the acceptance criteria — specify behavior, not mechanism.

## Mandatory Checklist

1. Verify each acceptance criterion is specific and independently verifiable
2. Verify no generic scaffold criteria survived (implementation complete, code compiles, etc.)
3. Verify scope has both an "In" and an "Out" section
4. Verify open questions were surfaced before confirmation (not discovered during implementation)
5. Verify the user explicitly confirmed the PRD before plan-first was invoked