# 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.

- **Type:** Skill
- **Install:** `agentstack add skill-vinnie357-claude-skills-prd`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [vinnie357](https://agentstack.voostack.com/s/vinnie357)
- **Installs:** 0
- **Category:** [Communication](https://agentstack.voostack.com/c/communication)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [vinnie357](https://github.com/vinnie357)
- **Source:** https://github.com/vinnie357/claude-skills/tree/main/plugins/pm/skills/prd

## Install

```sh
agentstack add skill-vinnie357-claude-skills-prd
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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](https://github.com/vinnie357)
- **Source:** [vinnie357/claude-skills](https://github.com/vinnie357/claude-skills)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-vinnie357-claude-skills-prd
- Seller: https://agentstack.voostack.com/s/vinnie357
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.