What should the PRD actually do?
A product requirements document (PRD) describes the product you want to build. It gives the agent enough direction to make useful implementation choices without guessing the most important product rules. A feature list such as “calendar, login, dashboard” does not explain who can book a room, whether bookings overlap, or what happens when two people submit at once.
Keep the document proportional to the app. A personal tool can start with a page. Shared access, payments, approvals, or important saved information require more explicit rules. Mark unknowns as unknowns and ask for recommendations where you need help. You can still leave framework choices and routine engineering details to the agent.
Copy this PRD template
Replace the brackets with your answers. Remove sections that genuinely do not apply. Keep the first release small enough to finish, but include the steps needed to deliver the promised result.
AI app PRD
# Product requirements: [app name] ## Purpose and first user [Who needs this, what problem they face, and the useful result.] ## First complete journey [Starting situation -> user actions -> saved or delivered result.] ## Roles and access [Who can view, create, edit, delete, approve, or share what?] ## Important information [Records that must survive reopening; where ownership matters.] ## Product rules [Rules users rely on. Include limits, approvals, and conflicts.] ## First release and later Now: [complete first outcome and required supporting steps] Later: [features deliberately excluded from this release] ## UI and experience [Frequent tasks, what needs attention, costly mistakes, and any supplied visual references or accessibility needs.] Agent may recommend: [ordinary design/engineering choices] Ask me before changing: [consequential product decisions] ## Failure and recovery [What happens if a save fails, a request repeats, access is denied, or the user leaves halfway?] ## Acceptance checks Given [starting state], when [action], then [observable result]. [Include reopening, another role, and important failure paths.] ## Existing app, if any [Current behavior to preserve, evidence, and how to run it.] ## Open questions [Question, why it matters, and who will decide.]
Filled example: a shared room-booking app
This is an illustrative example, not a customer case or a deployed app. Imagine a small studio whose members need to reserve two meeting rooms without double booking them.
The agent should choose how to enforce the overlap rule in the actual system. The product requirement is the result: conflicting reservations cannot both become confirmed. A calendar that merely hides booked slots is not enough to prove that rule holds.
| Part of the PRD | Example answer |
|---|---|
| User and outcome | A studio member reserves an available room and can reopen the app to see the confirmed booking. |
| First journey | Sign in, choose a room and time, review the details, confirm, then find the booking under My bookings. |
| Roles | Members can create and cancel their own bookings. The studio manager can manage all bookings. |
| Records and rules | Save room, member, start time, end time, and booking status. Active bookings for the same room must not overlap. |
| Conflict | If two members try to book the same slot, at most one booking succeeds. The other sees that the slot is no longer available. |
| Experience | Availability is easy to scan. Confirm room and date before saving. Explain conflicts beside the attempted booking. |
| Release boundary | Two fixed rooms, bookings, cancellations, and a manager view. Recurring bookings and calendar sync are later. |
| Acceptance | Create a booking, reopen in a fresh session, verify it remains, cancel it, and verify the slot becomes available. |
Turn the PRD into the first coding task
Ask the agent to read the requirements, identify the questions that change the build, and recommend the first complete milestone. Avoid asking it to implement every listed feature at once. For the example, the milestone could be reserving a room and finding the same confirmed booking after reopening.
First coding session
Read this PRD and inspect the existing project, if present. Explain the first complete user journey and any unanswered question that materially changes it. Recommend ordinary technical and design choices. Ask me about unresolved product rules before implementing those rules. Build the agreed first journey, including its UI, saved state, access rules, and important failure path. Verify it in the running app and report the steps, result, and remaining limits. Preserve the named existing behavior. Update the implementation note when discoveries change the plan.
Where architecture and tests come in
The PRD names what users need. Architecture explains how the system is divided and where important records and rules belong. A technical plan selects the mechanisms that enforce them. Acceptance checks demonstrate whether the implementation meets the requirement. For a small app these can fit into a short set of notes; a complicated workflow needs more care.
- Can each important rule be connected to the part of the system that enforces it?
- Does the first milestone finish a real user task?
- Do checks include saved state, permissions, and the most consequential failure?
- Are findings from the running app reflected in the current notes?
When a template is enough, and when you need more help
Use the template directly when you can answer the important questions and your agent can inspect and build the app. Structured tools such as GitHub Spec Kit also provide a specification and planning workflow. Driftbreak is useful when the direction itself needs working through: your idea is still unclear, a shared workflow has conflicting rules, or an existing app needs a coherent next step. It connects those decisions to architecture and implementation material; the coding agent or developer still builds and verifies the software.
Sources & further reading
- GitHub Spec Kit
An open-source specification-driven workflow with templates and planning commands. The template in this guide is our own.