Docs Product — product documentation («why» & «what»)

Use this skill to write the product-facing documents: vision, requirements, roadmap, feature catalog. Written from an idea forward — before (or in parallel with) engineering docs.

When to use

• A project needs its product docs: VISION, PRD, ROADMAP, FEATURES.
• User asks for "продуктовая документация", "vision", "prd", "роадмап", "требования к продукту", "product requirements".
• Requirements must become the input for engineering docs.

Do NOT use

• For engineering docs (architecture, ADR, tests, dev guide, map) — that is docs-project.
• For the meta-guide (phases, levels L1/L2/L3, completeness checklist) — docs-system.

Which docs belong here

The golden chain: VISION → PRD → ROADMAP → FEATURES. Vision spawns requirements, requirements spawn the plan and the feature catalog. Nothing is written "from the end".

Order of writing

1. VISION — can you state the product in 1–2 sentences? If not, stop and clarify before writing anything else.
2. PRD — goals/non-goals, stories with priorities, functional + non-functional requirements, acceptance criteria, success metrics (a milestone without a metric is a wishlist).
3. ROADMAP — order the PRD's milestones by value (not effort), each with a target date, features, and proof.
4. FEATURES — the living status board of every feature, ✅/📋 only against reality. This doc hands the product requirements to the engineering side.

Links across the boundary (with docs-project)

Checklist (product side)

• VISION: 1 paragraph; audience named; explicitly listed out-of-scope items.
• PRD: every story has a priority (MoSCoW/P0–P2) and links to a feature.
• PRD: success metrics present (baseline → target) — not "quality" in prose.
• ROADMAP: milestones ordered by value; each has a date/target + a metric.
• FEATURES: ✅/📋 statuses match reality (no wishlist-only catalog).

Rule: product docs answer «why» and «what»; engineering docs answer «how». If a doc has no reader and no question it answers — it does not belong.

Boundaries

• Do not use for implementation/runbook documentation; use docs-project.

Evidence and completion gate

Ground recommendations in the supplied repository or brief. State assumptions, missing inputs, and unresolved risks. Return a concrete artifact or checklist with an owner/action for each open item, then verify that the result answers the requested goal rather than merely repeating the framework.