# Prd Standards

> Defines PRD structure, user story format with 4 Risks assessment, EARS-format acceptance criteria, and delivery readiness thresholds. Use when writing PRDs, drafting user stories, defining acceptance criteria, or reviewing PRD quality and completeness.

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

---


# PRD Standards

## Purpose

Canonical reference for PRD quality — shared by both authoring (recipe-define) and review (doc-reviewer) workflows. Ensures the author and reviewer apply the same standards.

## Reference Selection

| Task | Read |
|------|------|
| Writing or reviewing a full PRD | `references/prd-template.md` |
| Writing or reviewing acceptance criteria | `references/acceptance-criteria.md` |
| Assessing story readiness or drafting user stories | `references/user-story-guide.md` |

## Relationship to product-principles

4 Risks framework, Confidence Meter (0-10), and OST hierarchy are **defined** in product-principles. This skill operationalizes them in the PRD context — templates, thresholds, and format. For authoritative definitions, always defer to product-principles.

## PRD Structure

A nautilus PRD uses the portions of the standard structure required by its delivery consumer. See `references/prd-template.md` for the available structure.

**Core sections** (include when they carry a delivery decision or required evidence):
- Overview (one-line summary, background)
- Users and Stories
- Functional Requirements (with EARS-format ACs)
- Design Context
- Non-Functional Requirements (including accessibility)
- Success Criteria (tied to Product Outcomes)
- Technical Considerations

**Nautilus extensions** (include at the smallest scope that affects delivery):
- Hypothesis & validation references in Overview
- 4 Risks evidence at the scope that changes delivery readiness
- Design Context derived from design artifacts and prototypes
- Unvalidated assumptions section in Technical Considerations

## User Story Standards

User stories remain grounded in an evidenced persona or user distinction. Record 4 Risks evidence at the smallest scope that changes delivery readiness; shared evidence does not need to be repeated per story. See `references/user-story-guide.md` for the output and readiness rules.

Key rules:
- Reference a specific persona from `docs/product/personas/`, not generic "user"
- Each material risk has evidence available to the delivery decision
- "Validated enough" is judged by cost x risk x reversibility, not a fixed threshold
- Remaining risks are documented explicitly, not hidden

## Acceptance Criteria Standards

Use EARS-format acceptance criteria when its event, state, or conditional form makes the requirement more testable or a downstream consumer requires it. See `references/acceptance-criteria.md` for selection, quality, and traceability rules.

Key rules:
- Use When (event-driven), While (state-driven), or If-Then (conditional) patterns
- Each AC is testable with a clear pass/fail
- User-facing ACs cover relevant states (loading, empty, error, partial, success)
- Accessibility ACs included for UI features