1. Name the user and the decision
Open with the person, situation, and decision the feature should improve. “Build a dashboard” is not a useful requirement; “help a support lead find overdue conversations before the daily handoff” gives the planner something to test.
Separate the desired outcome from a proposed solution. This keeps the PRD open to a smaller implementation and makes it easier to reject work that does not change the decision.
- The primary user and situation are concrete.
- The decision or behavior to improve is named.
- The outcome is distinct from the proposed UI or technology.
- A non-goal is recorded.
2. Use a planning Skill for structure, not authority
prd can turn rough notes into a structured product brief. create-implementation-plan is the next role when the brief is approved and must become repository-aware implementation steps. context-map helps when the existing codebase or dependencies are not yet understood.
Keep the roles separate. A polished PRD can still contain a wrong assumption, and a detailed implementation plan cannot silently decide a product priority that the owner has not approved.
3. Turn requirements into checks
For every requirement, write an observable acceptance check: the input, the action, the expected state, and the evidence a reviewer will inspect. Include empty, error, permission, and mobile states when they change the decision.
Mark open questions instead of filling them with confident prose. A short unresolved list is more actionable than a long PRD that hides a dependency on policy, data ownership, or an external API.
- Each requirement has a visible pass condition.
- Critical empty and error states are covered.
- Dependencies and owners are named.
- Open questions have a decision owner and date.
4. Stop before the brief becomes a promise
A PRD should not promise a delivery date, security property, or integration behavior that has not been checked. Keep confidence, evidence, and unknowns separate so the implementation team can plan a technical spike or request a decision rather than guessing.
The best output is a small brief that another person can challenge. Once the scope and acceptance checks are approved, hand off to an implementation plan; do not let the planning Skill quietly start writing production files.