AI PRD template: the sections, a prompt for each one, and a worked example

What the template needs to do

A product requirements document has two readers. The builder, who may be a teammate, a contractor or a coding agent, needs to know what to make and when to stop. The reviewer needs to check that what shipped is what was agreed. The template serves both when every requirement is a single, testable statement and every non-goal is written down.

The sections are chosen so that each one is a different kind of question:

Keep the whole thing under two pages. A PRD people do not read is a PRD that does not exist.

The Markdown PRD template

Copy this block into a page, a file in your repository, or an editor. Replace everything in brackets and delete each guidance line once the section is written.

PRD: [Feature or product name]

Owner: [Name]
Status: [Draft / In review / Agreed]
Last updated: [YYYY-MM-DD]
Summary: [One sentence: what it is, who it is for, what it replaces]

**1. Problem**
Today, [who] [does what workaround] when they need to [get something done].
It costs them [time, money or risk you have observed].
Evidence: [interviews, support tickets, sales calls, your own use; say how many]

**2. Goals**
G1. [Metric] moves from [current value] to [target] by [date].
G2. [Metric] moves from [current value] to [target] by [date].
How we will measure: [the dashboard, query or report]

**3. User stories**
US-1. As a [role], when [situation], I want to [action], so that [outcome].
US-2. As a [role], when [situation], I want to [action], so that [outcome].
US-3. As a [role], when [situation], I want to [action], so that [outcome].

**4. Acceptance criteria**
For each story, one or more checks a reviewer can pass or fail.
AC-1a. Given [state], when [action], then [observable result].
AC-1b. Given [state], when [action], then [observable result].
AC-2a. Given [state], when [action], then [observable result].
Priority: [Must / Should / Could] for each story.

**5. Non-goals**
We are not doing [thing] in this release because [reason].
We are not doing [thing] in this release because [reason].

**6. Risks and open questions**
R1. [Risk]. Likelihood [low/med/high]. If it happens: [response].
R2. [Risk]. Likelihood [low/med/high]. If it happens: [response].
Open: [a question that must be answered before build starts, and who answers it]

Two conventions carry most of the weight. Every story and criterion has a stable key (US-1, AC-1a), so a commit message, an issue or an audit can point at it. And every criterion is written as given-when-then, so it is a test before it is code.

A prompt for each section

A single "write me a PRD" prompt produces a confident document with made-up evidence and generic goals. Prompting one section at a time, with the facts you actually have, gives the model less room to invent. These are the prompts we use; the bracketed parts are what you fill in before sending.

1. Problem. "Here are my notes from [N] customer conversations and [N] support tickets: [paste]. Write the Problem section in under 120 words, in the form 'Today, [who] does [workaround] when they need to [job]. It costs them [cost].' Only use costs that appear in the notes. End with an Evidence line that counts the sources."
2. Goals. "The problem is: [paste]. Our current numbers are: [metric, value]. Propose three goals as 'G#. [metric] moves from [current] to [target] by [date]'. Do not invent current values; if you need one I have not given, write TBD."
3. User stories. "Problem and goals: [paste]. Write at most five user stories in the form 'As a [role], when [situation], I want to [action], so that [outcome]'. One role per story. Order by how directly each serves G1."
4. Acceptance criteria. "For each story below, write two or three acceptance criteria as 'Given [state], when [action], then [observable result]'. Each must be checkable by someone who cannot see the code. Flag any story for which you cannot write a checkable criterion." This is the step where a weak story shows itself: if the model cannot write a test for it, neither can you.
5. Non-goals. "Given these stories, list six things a reasonable engineer might assume are included but are not. For each, write 'We are not doing [thing] in this release because [reason]'." Then cut the list to the ones that would actually tempt your team.
6. Risks. "List the four most likely ways this feature fails after launch, technical or commercial. For each: likelihood, and the response we would take. Mark anything you are guessing at."

Ask for one section, read it, correct it, then paste the corrected version into the next prompt. The chain of corrected sections is the real safeguard; the model only ever sees what you have already approved.

Worked example: a booking link for a two-person consultancy

Here is the template filled in for a small, real-shaped feature. Figures are illustrative.

PRD: Public booking link

Owner: Dana
Status: Agreed
Last updated: 2026-10-28
Summary: A public page where a prospect picks a 30-minute slot from our
shared calendar, replacing the email back-and-forth we do today.

**1. Problem**
Today, a prospect who wants a call emails us, and we trade an average of
four messages to agree a time. Across 22 calls last quarter that was about
three hours of founder time, and two prospects went quiet before a time
was set.
Evidence: sent-mail search for the last 90 days; 22 threads counted.

**2. Goals**
G1. Messages exchanged per booked call moves from 4 to 1 by 15 December.
G2. Booked calls per month moves from 7 to 10 by 31 January.
How we will measure: count of threads tagged "scheduling" in the shared
inbox; bookings table in the workspace.

**3. User stories**
US-1. As a prospect, when I open the link, I want to see slots in my own
time zone, so that I do not book at 3am by mistake.
US-2. As a founder, when a slot is booked, I want it on my calendar with
the prospect's details, so that I do not prepare from memory.
US-3. As a founder, when I am on leave, I want no slots offered, so that
nobody books into a week I am away.

**4. Acceptance criteria**
AC-1a. Given a visitor in UTC+9, when the page loads, then times are shown
in UTC+9 and the zone name is visible.
AC-1b. Given a slot already booked, when the page loads, then that slot is
not offered.
AC-2a. Given a completed booking, when I open the calendar, then an event
exists with the prospect's name, email and notes within 60 seconds.
AC-3a. Given an approved leave request covering a day, when the page loads,
then no slots on that day are offered.
Priority: US-1 Must, US-2 Must, US-3 Should.

**5. Non-goals**
We are not doing payment at booking because the first call is free.
We are not doing group events because we have never been asked for one.
We are not doing custom branding because the two of us are the brand.

**6. Risks and open questions**
R1. Double booking if the calendar sync lags. Likelihood medium. If it
happens: a confirmation email with a reschedule link, checked daily.
R2. Spam bookings. Likelihood low. If it happens: require an email
confirmation before the slot is held.
Open: do we offer 15-minute slots as well? Dana decides by Friday.

Notice what the example does not contain: no "delightful experience", no architecture, no screenshots. AC-3a is a test that a reviewer can run in two minutes. The non-goals are the three things a contractor would most likely ask about.

Where to keep it, and what to do with it next

A PRD in a chat window is lost the moment the tab closes. It needs a home with version history, so you can see what changed between "Draft" and "Agreed", and a way to turn its stories into work.

In Atrix, the PRD template is a hosted page with the same sections as the Markdown above, plus a requirements table where each row has a key, one checkable statement, acceptance and a MoSCoW priority. The agent's Develop run goes the other way too: give it a short brief and the "Draft the requirements" step writes the problem, target user, scope, numbered requirements and non-goals into a page, then the next steps propose an architecture and planned issues you can accept into the backlog. The limits are worth knowing: a run costs one of the plan's monthly runs (100 on Builder, 500 on Studio), there is no free plan, and the agent drafts from your brief, so a thin brief gives a thin PRD. The AI agent page lists what each run produces.

If you want the PRD read by a coding agent rather than a person, the sibling post on writing a PRD that Claude Code or Cursor can build from covers the extra constraints.

Common mistakes the template is designed to prevent

• Goals without a current value. "Increase conversions" is a wish. "Move from 2.1% to 3% by March" is a goal. If you do not know the current value, write TBD and find it before build starts.
• Stories that are features in disguise. "As a user, I want a dashboard" has no situation and no outcome. Ask what they are trying to get done.
• Criteria that need the code to check. "The API returns 200" is an implementation detail. "Given a completed booking, when I open the calendar, then the event exists" is what the user sees.
• Empty non-goals. If the section is blank, the scope has not been decided; it will be decided by whoever builds it.
• A risks section that only lists technical risks. "Nobody uses it" is the most common failure and belongs on the list.

FAQ

What is an AI PRD template?

A product requirements document template written so that an AI assistant can draft each section from facts you supply, and so a reviewer can check the result. The one above has six sections: problem, goals, user stories, acceptance criteria, non-goals, and risks, each with a prompt.

Is a PRD for an AI product different from a normal PRD?

The sections are the same. What changes is the acceptance criteria: an AI feature needs criteria for the cases where the model is wrong, slow or unavailable, and a stated accuracy threshold instead of "works correctly". Add a non-goal for the behaviours you will not try to handle in the first release.

How long should a PRD be?

Under two pages for a feature, three or four for a new product. If a section runs longer than that, it is usually a design document or a backlog hiding inside the PRD. Move it out and link to it.

Can I just ask ChatGPT or Claude to write the whole PRD?

You can, and the result will read well, which is the problem. A single-prompt PRD invents evidence and current values because it has none. Prompting one section at a time with your own numbers, and correcting each before the next, keeps the document honest.

What is the difference between this and GitHub Spec Kit?

Spec Kit is a toolkit for coding agents that turns a specification into a plan, tasks and code through commands in the agent's chat. This template is the specification itself, written for a person to agree before that process starts. They fit together: write the PRD, then feed it to the specify step.

Where do acceptance criteria go once the PRD is agreed?

Each one becomes the definition of done on an issue. In Atrix, the requirements table on the PRD page is what the requirements audit checks later: it compares what was planned against the frozen baseline, not the source code. The glossary entry on PRDs covers the terms.

Next step

Copy the Markdown above, or open the hosted PRD template and fill it in with your team. If you would rather start from a brief, the Atrix agent drafts the first version into a page during the 7-day trial.

Sources

ChatPRD pricing and GitHub Spec Kit, both checked in October 2026.