A PRD template for AI coding agents
A product requirements document written for people leaves an agent guessing. This one keeps what the agent needs: an ID and a reason for every requirement, the rules it must keep, and a check for done.
In short
A PRD (product requirements document) says what to build and why: the problem, who has it, the requirements and how to tell they are met. For AI coding agents three parts matter more than in a PRD written for people: an ID on every requirement that the agent and the review can cite, the rules of the existing product the work must not break, and a Done when check that can actually be run. Copy the template below. GitMir can check a finished PRD against your product before work starts, and GitMir GoBots writes one from market evidence for a product that does not exist yet.
Copy it, fill it, keep it short
# <Product or feature> — PRD
## Problem
Who has it, what gets in their way today, what it costs them.
## Users
The people who use it, and the person who decides to buy it.
## Requirements
REQ-001 <What the product must do, in one sentence>
Why: <the pain or opportunity it answers, and where it was seen>
Done when: <a check anyone, or an agent, can run>
REQ-002 ...
## Rules it must keep
<Existing rules of the product this work must not break>
## Out of scope
<What this work will not do>
## Open questions
<What still needs a decision, and who makes it>Six sections, each with a job
IDs
The agent, the task and the review can all point at REQ-002 instead of paraphrasing it.
Why
A requirement without a reason is the first to be built wrong and the last to be questioned.
Done when
Acceptance criteria the agent can check itself, written once instead of explained in every prompt.
Rules it must keep
The part people forget, because the rules live in code. GitMir finds them when it checks the PRD.
Out of scope
Agents are generous. This is where you stop them building what nobody asked for.
Open questions
Decisions belong to a person. Listing them keeps the agent from settling them silently.
ChairTime, filled in
A made-up product used across GitMir's demos: recall reminders for small dental practices.
# ChairTime — PRD
## Problem
Small dental practices lose visits when patients who are due for
a check-up are never rebooked; the front desk has no time to call.
## Requirements
REQ-001 Find the patients who are due and have no visit booked.
Why: recall is the first thing to slip (practice owners' forum).
Done when: a patient past their recall date with no booking is on the list.
REQ-002 Text each due patient a link to open slots.
Why: owners want due patients back without front-desk calls.
Done when: a due patient receives one text with a working booking link.
REQ-003 Show the practice the visits that came back.
Why: the owner decides to keep paying by what it brought back.
Done when: a visit booked from a link is counted on the practice screen.
## Rules it must keep
Never text a patient who opted out. One reminder per recall period.
## Out of scope
Payments and insurance.
## Open questions
How many reminders per period? The practice owner decides.Check the PRD against the product
Save the PRD in your GitMir project. Each requirement comes back as already works, contradicts the product — what the PRD says against what the product says — new, or needs a question. Only the new requirements are left to estimate, and each becomes a task with its Done when. After delivery the same document shows which requirements the product actually meets.
Write it, check it, build it
GitMir Intelligence
Checks a PRD against your existing product, requirement by requirement, and tracks what was delivered.
GitMir GoBots
Writes requirements that say why they exist, from a description and market research with sources.
GitMir Market
The evidence behind the Why lines: alternatives, pains by segment and scored opportunities, each with its source.
Asked about PRD template
The problem and who has it, the users and the buyer, requirements with a reason and a Done when check for each, the existing rules the work must keep, what is out of scope, and the open questions with the person who decides them.
Give every requirement an ID, a one-line reason and a Done when check the agent can run, and list the rules of the existing product it must not break. Then give the agent the rules each task touches over MCP while it builds.
GitMir GoBots writes requirements from a description of the product and market research with sources, and each requirement says why it exists. For a PRD you already have, GitMir Intelligence checks it against your code.
A PRD says what to build and why. A spec adds how: design decisions, constraints and the plan of tasks. Agents need both the why and the checks.
As long as its requirements and no longer: one sentence per requirement, one line of why, one Done when. Everything else belongs in the spec or the tasks.
Give your AI the business logic of your product
Connect a repository and ask it in plain words — 10,000 credits to start, no card.