define-prd

Create and validate Stage A PRDs with required sections and MoSCoW scope formatting.

8|Updated Sep 22, 2025
One-click install
npx skills add https://github.com/hardness1020/VibeFlow --skill define-prd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: define-prd
Source: https://github.com/hardness1020/VibeFlow/tree/main/.claude/skills/define-prd
Command: npx skills add https://github.com/hardness1020/VibeFlow --skill define-prd

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and assets (resource) components.

What problem does it solve?

Stage A PRDs are often inconsistently structured and hard to validate, causing misalignment between problem definition, users, scope, and success metrics. This skill automates the creation and validation of PRDs to ensure a consistent, reviewable foundation for feature work in the VibeFlow docs-first workflow.

Core Features & Use Cases

  • Generate or update docs/prds/prd.md with all required sections (Header, Summary, Problem & Context, Users & Use Cases, Scope, Success Metrics, Non-Goals, Requirements, Dependencies, Risks & Mitigations, Analytics & Telemetry)
  • Validate PRD structure and content using the included validation script to catch missing sections, header metadata, and formatting issues
  • Use Case: teams produce Stage A PRDs that drive design, testing, and alignment across stakeholders before committing to implementation

Quick Start

Issue the /define-prd command to generate or update docs/prds/prd.md.

Frequently Asked Questions about define-prd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a product requirements document with success metrics and MoSCoW scope?

To create a product requirements document, use the /define-prd command to generate docs/prds/prd.md with required sections like Problem, Scope, and Success Metrics. It automatically enforces MoSCoW-based scope formatting to gate progress and maintain traceability.

What is Stage A in a docs-first workflow and when do I need to validate it?

Stage A in a docs-first workflow defines the foundational problem, users, scope, and success metrics before implementation. You need to validate it using a structure validator to catch missing header metadata and formatting issues, ensuring stakeholder alignment.

How do I validate PRD structure and required sections before committing to implementation?

You validate PRD structure by running the included validation script against docs/prds/prd.md. This catches missing required sections, header metadata, and formatting issues to ensure a reviewable foundation for feature work.

Does the VibeFlow PRD template support non-goals and risk mitigation tracking?

Yes, the VibeFlow PRD template supports non-goals and risk mitigation tracking. It generates sections for Non-Goals, Risks & Mitigations, and Dependencies alongside Requirements and Analytics to maintain comprehensive traceability.

What is the best way to align stakeholders on feature scope using MoSCoW formatting?

The best way to align stakeholders is enforcing MoSCoW-based scope formatting within your PRD. This gates progress by categorizing requirements strictly, ensuring design and testing teams share a reviewable, consistent foundation.

Why does my PRD validation fail when updating docs/prds/prd.md?

PRD validation fails when required sections like Header, Summary, or Success Metrics are missing, or if header metadata and MoSCoW scope formatting are incorrect. The validator enforces these constraints to prevent misalignment.