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
Decision gist · record as of 2026-07-27
doc-prd creates a Product Requirements Document that translates business goals into product features and user personas. 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.
Use it when
- doc-prd structures PRD content around customer personas, product features, user journeys, and measurable success criteria (KPIs).
- doc-prd defines product capabilities and user requirements at the container level—the intermediate abstraction between high-level business.
Verify before relying
Read SKILL.md below before installing (1 file). Open directory: indexed for reading, not audited.
Install
vladm3105/aidoc-flow-framework/doc-prd · repository language: Python
Open directory. Skills are indexed for reading, not audited. Review a skill's body before installing it.
Frequently 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)
File tree — 1 file
platforms/claude-code-plugin/skills/doc-prd/SKILL.md
Let your AI agent find skills like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 56,283 agent skills by what they can do, searchable in plain language.
wish › “Create a structured PRD that translates BRD goals into product features, personas, and success metrics”
Give your agent the search over MCP, or paste the wish link into any chat. No install? Search from any chat →
Related skills
doc-adr captures a single architectural decision using the Context-Decision-Consequences pattern, positioned as Layer 5 in the specification-driven development flow. It records the rationale, chosen approach, evaluated alternatives, and accepted trade-offs for decisions that bridge container and component design.
doc-tdd generates Layer 7 TDD artifacts that translate component contracts into concrete test cases with quality thresholds. It maps BDD scenarios to unit, integration, functional, and end-to-end tests, establishes coverage targets per type, and sequences the Red-Green-Refactor workflow before implementation begins.
doc-bdd translates EARS requirements into Layer 4 acceptance scenarios using structured YAML (not Gherkin), each with Given-When-Then phases, element-level trace links to upstream EARS, and forward mapping to SPEC sections. Use this after EARS is complete and before ADR/SPEC authoring; for batch generation across multiple documents, the autopilot skill handles orchestration.
Quality-advisor gives live feedback while you create or review SDD documents, catching completion gaps, documentation anti-patterns, tag compliance, and naming issues before submission. It scores sections, detects common problems like missing traceability or broken links, validates cumulative tagging across layers, and returns actionable recommendations to fix issues.
Automates the full ADR lifecycle from source documents (BRD, PRD, EARS, BDD) or free-text prompts through generation, validation, and iterative refinement. Detects whether an ADR exists, routes to generation or review-and-fix accordingly, and maintains the ADR index with passing scores. Supports single or batch processing with configurable quality thresholds and fix iteration limits.
specify-solution guides you through building solution design documents (SDDs) that capture how your system will be built. It structures your architecture decisions as traceable ADRs, validates that every requirement maps to a component, and ensures your design is complete and conflict-free before implementation begins.
More skills project-adopt (MIT) · documentation-criteria (MIT) · deliver-prd (Apache-2.0) · prd (MIT) · product-planner (MIT)