# Prd

> Structured PRD authoring where the PRD is the contract for specs delivered to implementing teams, human or agent. Use when writing a product requirements document, turning a spec-harvest feature inventory into per-feature PRDs, running /pm:prd, or defining scope boundaries and acceptance criteria for an engineering handoff.

- Skill: `vinnie357/prd` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add vinnie357/prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vinnie357/prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: vinnie357 (https://skillmd.com/u/vinnie357)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/vinnie357/prd

---


# PRD Authoring

Author a Product Requirements Document that serves as the handoff contract between product intent and an implementing team — human or AI agent. The PRD states WHAT the feature does and WHY it exists; it never prescribes HOW to build it.

## PRD as Contract

A PRD is complete when the implementing team needs no follow-up questions to start work. Treat every unanswerable question as a defect in the document, not a gap the implementer fills in.

**Non-goals are as firm as goals.** State exclusions positively and explicitly — "does not support X" — never by silent omission. An agent implementer cannot infer a boundary from absence: omitting "do not implement X" from the PRD is how an agent ends up building X. A human team asks follow-up questions; an agent team does not, so write for the stricter reader.

**The PRD stays at the WHAT/WHY altitude.** A PRD is not a software requirements specification. Writing a PRD ensures user-centric context; a separate, downstream implementation spec — authored by a PM or engineer AFTER this PRD, never inside it — is where SRS-level HOW-level agent operating instructions (file layout, framework choice, API contracts) belong.

**Completeness test:** before calling a PRD done, walk every section and confirm a different engineering team with a different tech stack could implement it without contacting the author.

## Two Modes

`/pm:prd` runs `pm-prd-author` in one of two modes:

1. **Interactive** (default) — the `/pm:prd` command session runs the questionnaire (problem, users, goals, non-goals, stories, constraints, phasing) via `AskUserQuestion`, since the spawned `pm-prd-author` agent has no channel to the operator. The agent then composes the PRD from the collected answers, each tagged `[operator-stated]`.
2. **Harvest-grounded** (`--inventory=<path>`) — the feature inventory from `/pm:spec-harvest` is the grounding document. One PRD is authored per major feature area named in the inventory; requirements are lifted from inventory entries and carry their original confidence tags. Sections the inventory cannot answer become Open Questions rows rather than invented content.

## Template Walkthrough

`templates/prd.md` is the skeleton every PRD composes against. Section intent:

| Section | What belongs there |
|---|---|
| Header | Title, ISO date, status, change history — who changed what and when |
| Problem / Opportunity | The problem and why it matters now, not the solution |
| Target Users & Personas | Who is affected, with the primary persona called out |
| Goals & Success Metrics | Outcomes and how they are measured, not features |
| Non-Goals / Out of Scope | Explicit exclusions with a reasoning column — prevents scope creep and agent over-implementation |
| User Stories + Acceptance Criteria | As a X, I want Y, so that Z — with Given/When/Then acceptance criteria per story |
| Data Shapes | Fields and relationships in prose or tables — never DDL, never a schema definition |
| UX & Interaction Requirements | Experiences and interactions — never named frameworks or components |
| Constraints & Dependencies | Business, legal, or sequencing constraints — not technical implementation constraints |
| Release Phasing | What ships first vs. later, and why the split |
| Open Questions | Question, owner, blocking? — for everything the author could not answer |
| Grounding Documents | Links back to the feature inventory or bees issues that grounded this PRD |

## Implementation-Agnostic Rules

Every requirement obeys four not-rules:

- Behaviors, not implementations.
- Data shapes, not schemas.
- Interactions, not APIs.
- User experiences, not frameworks.

**Portability test:** a requirement passes only if a different engineering team with a different tech stack could implement it from the sentence alone.

```
Bad:  "Store the draft in a Postgres jsonb column and debounce autosave via a
      React useEffect hook calling PATCH /api/drafts/:id every 2 seconds."
Good: "The user's in-progress draft persists automatically without an explicit
      save action. Persistence happens frequently enough that a browser crash
      loses no more than a few seconds of work."
```

## Anti-Fabrication

Every requirement traces to a questionnaire answer or a feature-inventory entry — never invented. Tag every requirement with its origin:

- `[operator-stated]` — given directly by the user in the interactive questionnaire.
- `[seen-in-code: <path>]` — lifted from a feature-inventory entry that cites a source file.
- `[inferred — needs verification]` — a reasonable inference not directly stated; must also appear as an Open Questions row.

A section the source material cannot answer becomes an Open Questions row, never fabricated prose.

## References

- `templates/prd.md` — the copyable PRD skeleton with all sections above.
- `/pm:spec-harvest` — produces the feature inventory that grounds harvest mode.