Write a PRD

Problem to Solve

Product plans often get stuck between a complete idea and an unclear execution path: no sharp goal, scope, dependencies, risks, or acceptance metrics. PRDs can become feature descriptions without codebase context or implementation path, causing repeated alignment loops during engineering review.

How It Works

write-a-prd-new turns a product idea into an actionable plan and selects Quick, Standard, or Deep Dive mode based on complexity. Key steps include:

• Clarify the goal: identify the problem, target users, why now, and success criteria.
• Explore current state: inspect repo or product context for existing features, reusable modules, data models, integration points, and risk hotspots.
• Shape the solution: define core user flow, functional requirements, edge cases, roles/permissions, empty/failure states, and metrics.
• Plan implementation: split module responsibilities, inputs/outputs, dependencies, testability, and phased scope.
• Produce the PRD: generate a document with background, goals, non-goals, user stories, MVP, technical notes, risks, testing strategy, and rollout plan.

Boundaries and Notes

This skill fits turning new features, workflow improvements, or multi-module requirements into an engineering-reviewable PRD or GitHub issue. It is not a generic design system, and it does not replace user research, architecture review, security, or compliance decisions. If requirements remain highly ambiguous, clarify goals, constraints, and success metrics first.