define-prd
npx machina-cli add skill hardness1020/VibeFlow/define-prd --openclawdefine-prd
Create PRDs with success metrics for Stage A of the VibeFlow docs-first workflow.
Purpose
This skill creates and validates PRD (Product Requirements Document) for Stage A:
- Define problem, users, and scope
- Set success metrics with baseline → target
- Document requirements, dependencies, and risks
Workflow
Stage A: Initiate
│
├── Create/update PRD
├── Define problem, users, scope
└── Set success metrics
Usage
Create PRD
/define-prd
Creates or updates docs/prds/prd.md with required sections.
Document Requirements
PRD (docs/prds/prd.md)
Required sections:
- Header (version, file, owners, last_updated)
- Summary (3-5 lines)
- Problem & Context
- Users & Use Cases
- Scope (MoSCoW format)
- Success Metrics (baseline → target)
- Non-Goals
- Requirements (functional + non-functional)
- Dependencies
- Risks & Mitigations
- Analytics & Telemetry
Validation
scripts/validate_prd.py— Validate PRD structure and content
References
See assets/:
prd-template.md— PRD template
Manifest Update
After completing Stage A, update docs/workflow-state.yaml:
- Set
stage: A - Set
docs.prd: docs/prds/prd.md
To advance to the next stage: /manage-work advance <ID>
Source
git clone https://github.com/hardness1020/VibeFlow/blob/main/.claude/skills/define-prd/SKILL.mdView on GitHub Overview
define-prd automates the creation and validation of PRDs for Stage A in the VibeFlow docs-first workflow. It guides you to define the problem, users, and scope, and to establish baseline and target success metrics, along with functional and non-functional requirements, dependencies, risks, and analytics. The result is a ready-to-review docs/prds/prd.md that can be validated with a script and advanced to the next stage.
How This Skill Works
Trigger /define-prd to create or update docs/prds/prd.md. The tool assembles the required sections (Header, Summary, Problem & Context, Users & Use Cases, Scope in MoSCoW, Success Metrics baseline→target, Non-Goals, Requirements, Dependencies, Risks & Mitigations, Analytics & Telemetry). Validation is performed by scripts/validate_prd.py to ensure structure and content. After Stage A is complete, update docs/workflow-state.yaml with stage: A and docs.prd: docs/prds/prd.md to prepare for progression via /manage-work advance <ID>.
When to Use It
- When planning a new feature using the VibeFlow docs-first workflow (Stage A).
- When you need to clearly define problem, users, and scope before design.
- When establishing baseline and target success metrics for PRD validation.
- When documenting dependencies, risks, and analytics requirements in the PRD.
- When preparing to advance to the next stage by updating the workflow state.
Quick Start
- Step 1: /define-prd
- Step 2: Populate docs/prds/prd.md with Header, Summary, Problem & Context, Users & Use Cases, Scope, Metrics, Dependencies, Risks, and Analytics.
- Step 3: Run scripts/validate_prd.py to verify structure and content; then update docs/workflow-state.yaml (stage: A, docs.prd: docs/prds/prd.md) to prepare for progression with /manage-work advance <ID>.
Best Practices
- Use the /define-prd trigger to ensure the PRD is created at docs/prds/prd.md.
- Fill all required sections: Header, Summary, Problem & Context, Users & Use Cases, Scope (MoSCoW), Metrics, Dependencies, Risks, and Analytics.
- Define Metrics with a clear Baseline → Target progression.
- Keep MoSCoW scope actionable and avoid overreach; link to related requirements.
- Validate with scripts/validate_prd.py and update workflow-state.yaml after Stage A completes.
Example Use Cases
- Onboarding flow revamp PRD: Problem identified (low activation), Users (new users, trial users), Scope: MoSCoW, Metrics Baseline 5% → Target 20%, Dependencies: analytics platform, Risks: data latency.
- Analytics dashboard refresh PRD: Problem (missing insights), Users (product analysts), Scope: MoSCoW, Metrics Baseline 24h data freshness → Target 2h, Dependencies: ETL job, Risks: data quality.
- Feature flag system PRD: Problem (untested features in production), Users (eng developers), Scope: MoSCoW, Metrics Baseline 0% feature adoption → Target 60%, Dependencies: CI/CD, Risks: rollout risk.
- Mobile push notifications PRD: Problem (low opt-in), Users (mobile users), Scope: MoSCoW, Metrics Baseline 12% → Target 40%, Dependencies: notification service, Risks: user fatigue.
- Search relevance PRD: Problem (poor results), Users (end users), Scope: MoSCoW, Metrics Baseline CTR 0.8 → Target 1.2, Dependencies: indexer, Risks: indexing delays.
