doc-prd
doc-prd generates a Product Requirements Document as Layer 2 of the SDD workflow, converting business requirements into product capabilities, user personas, and measurable success criteria. It structures features and acceptance criteria at the container level, sitting between upstream BRD and downstream EARS artifacts.
doc-prd creates a Product Requirements Document that translates business goals into product features and user personas.
AI-generated summary based on this skill's SKILL.md
Install
vladm3105/aidoc-flow-framework/doc-prd · repository language: Python
git clone https://github.com/vladm3105/aidoc-flow-framework
cp -r aidoc-flow-framework/platforms/claude-code-plugin/skills/doc-prd ~/.claude/skills/doc-prdnpx skillfed install vladm3105/aidoc-flow-framework/doc-prdFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do I write a PRD from a BRD?
doc-prd translates your Business Requirements Document into a structured Product Requirements Document by mapping BRD goals to product features, user personas, and success metrics. The skill guides you through defining container-level capabilities and acceptance criteria that bridge upstream business intent with downstream EARS specifications, maintaining full traceability across the SDD workflow.
What should a doc-prd include for personas and success metrics?
doc-prd structures PRD content around customer personas, product features, user journeys, and measurable success criteria (KPIs). It helps you author customer-facing messaging alongside technical requirements, ensuring personas are tied to specific capabilities and success metrics validate that features deliver business value.
What is the product container level requirements in doc-prd?
doc-prd defines product capabilities and user requirements at the container level—the intermediate abstraction between high-level business goals and detailed EARS specifications. This layer captures what the product must do and for whom, without prescribing implementation details, making it the ideal staging point for architectural elaboration and downstream requirement decomposition.
How does doc-prd fit into the SDD workflow?
doc-prd operates as Layer 2 of the SDD workflow, positioned between upstream BRD and downstream EARS, BDD, and ADR artifacts. It validates traceability by ensuring every business requirement maps to product features and acceptance criteria, and every feature can be traced forward into detailed specifications and architectural decisions.
Can doc-prd help elaborate architectural topics for ADR decisions?
Yes. doc-prd translates architectural topics from the BRD into technical evaluation options suitable for Architecture Decision Records. It structures these elaborations within the PRD so downstream ADR authors have clear context, trade-offs, and constraints to inform their architectural choices.
What PRD document structure and templates does doc-prd provide?
doc-prd offers section templates and guidance for creating a complete PRD: business context, personas, features, user journeys, acceptance criteria, success metrics, and architectural considerations. Each section includes best practices for maintaining clarity and traceability, helping you produce a professional, actionable PRD that stakeholders and engineers can follow.
SKILL.md
rendered from the published skill — quoted content, verbatim
doc-prd
Purpose
Create a Product Requirements Document (PRD) — Layer 2 of the SDD flow. A PRD defines product features, personas, success metrics, and acceptance criteria at the C4 Container level (what the product does, not how).
Layer: 2 (Container level). Upstream: BRD. Downstream: EARS → BDD → ADR → SPEC → TDD → IPLAN → Code.
One PRD per BRD iteration cycle (MVP → PROD → new MVP). New scope gets a new PRD; link cycles
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 1 file
platforms/claude-code-plugin/skills/doc-prd/SKILL.md