# Prd Writing

> Write or repair one final PRD from fully confirmed structured context in plain, skimmable technical English. Use only after the PRD interview is complete; never invent missing product decisions.

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

---


# PRD writing

Turn the confirmed product inputs and decisions into the final PRD. This is a rendering step, not another
brainstorm. Write once in normal operation; repair only when deterministic validation names a
specific defect.

## Source of truth

Read the confirmed inputs and requirement paths supplied by the workflow. When the cumulative
decision artifact exists, its answers are authoritative; when it does not, no extra interview
decisions were needed. Do not scan the repository, reopen product decisions, add plausible
features, or infer technical design. If a required answer is absent, stop instead of filling space.

For a decision whose `source` is `user-answer`, use only its `answer`. Its unaccepted `proposal` is
context, not permission to complete a partial answer. Stop without writing if a `must_resolve` fact
is absent, a material value remains vague, or two confirmed decisions conflict.

## Required structure

Start with this compact document header:

```markdown
# <Concise feature name> — PRD

**Feature slug:** `<workflow-supplied slug>`
**Status:** Ready for review
```

Derive the feature name from the confirmed goal without adding scope. Do not add revision history,
decision IDs, authors, or decorative metadata.

Use these exact level-2 headings in this order:

1. `Summary`
2. `Problem and context`
3. `Users and jobs`
4. `Goals and success signals`
5. `Non-goals`
6. `Functional scope`
7. `Constraints and assumptions`
8. `Acceptance criteria`
9. `Dependencies and risks`
10. `Priorities and phasing`
11. `References`

Use identifiers only in `Acceptance criteria`. Write every criterion as a sequential observable
bullet beginning `AC-01:`, `AC-02:`, and so on. Do not put `B1`, `B2`, `FR-*`, `REQ-*`, question
IDs, or other traceability codes in any other section.

Before adding prose, create all eleven headings in the required order. Before completing, check
that every in-scope actor permission, state transition, limit, conflict, override, and recovery rule
from the confirmed decisions has an observable acceptance criterion. Non-goals do not need one.

## Plain technical English

- Put the decision or idea first.
- One idea per sentence; one topic per paragraph.
- Prefer short bullets for scope, non-goals, risks, and acceptance criteria.
- Use active voice and name who does what.
- Use concrete words. Avoid `leverage`, `facilitate`, `robust`, `seamless`, `ecosystem`, and
  other decorative language.
- Define a necessary technical term once. Cut terms the product reader does not need.
- Preserve the user's meaning and terminology.
- State each idea once. No recap paragraphs, filler, marketing claims, or repeated rationale.
- Expand only when precision would otherwise be lost.

## Concision

Use the shortest wording that preserves every confirmed product fact. Remove repetition, filler,
and generic explanation; prefer bullets or compact tables when they make the content easier to
scan. There is no word-count target or ceiling. Never omit, merge, or soften a requirement, edge
case, constraint, risk, or acceptance criterion merely to shorten the document. When precision
needs more context, include it.

## Validate before returning

Run the workflow-supplied validator after writing. Allow its mechanical-fix mode to normalize line
wrapping and acceptance-criteria numbering. If it still reports a defect, repair only that defect
inside this same call and validate again. Do not return success with a failing artifact.

## Repair mode

When the workflow supplies validator feedback, change only the named defects. Do not rewrite
unrelated sections or make the document longer unless the missing precision requires it. Preserve
existing acceptance-criteria IDs when their meaning is unchanged; otherwise restore one unique,
gap-free `AC-01` sequence.

## Safety

Write only the workflow-supplied PRD artifact. Never edit requirements, confirmed context, code,
or run state.

## Output contract

Return `summary`: one short sentence stating that the final PRD was written or which validator
defects were repaired.