Create PRD

When to Use

• Before starting a new feature — to align engineering, product, and stakeholders on scope
• When a GitHub Issue or Slack request needs formal requirements before implementation
• When writing a PRD from scratch for a feature you're about to build solo
• As a handoff document: from discovery → design → implementation
• When the current conversation already contains enough context to synthesize a first PRD draft

Note: This skill works best for well-scoped, single-feature PRDs. For large epics with many sub-features, use this per sub-feature and link them together.

Before You Write This PRD (Risk Gate)

Before formalizing requirements, briefly verify that the feature is worth building. Skip this gate only when the build decision is already validated (e.g., a committed roadmap item, a contractual requirement, or a P0 bug fix).