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.

When to Use

Activate when:

• The /pm:prd command is invoked.
• Turning one feature-area entry from a /pm:spec-harvest feature inventory into a standalone PRD.
• Defining scope boundaries, acceptance criteria, or success metrics before an engineering handoff.
• Reviewing an existing PRD for implementation leakage (tech names, schemas, API shapes) or missing non-goals.

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=) — 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: ] — 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: vinnie357
• Source: vinnie357/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.