Writing a PRD an AI Coding Agent Can Build From

A PRD an AI coding agent can build from is short, literal and complete where it matters. It states one goal, who the users are and what they need, what is in scope and what is explicitly not, numbered requirements that each carry acceptance criteria a stranger could check, the constraints the agent must not break, and the questions nobody has answered yet, marked so the agent stops rather than guesses. It leaves out the persuasion a PRD for people often carries, such as market sizing and vision statements, because an agent does not need convincing. It needs edges. Below are the seven sections, a template to copy, a worked example, and how to turn the document into tasks.

Why a PRD for an agent is different

A person reading a vague requirement asks a question. An agent fills the gap with something plausible and carries on, and you find out which guess it made when you test the result. Everything in an agent-ready PRD follows from that. Adjectives such as “fast” or “simple” become numbers or examples. Scope has a matching list of what is out. Anything undecided is labelled undecided.

Anthropic’s Claude Code best practices↗ (opens in a new tab) describe the most useful specs in the same terms: self-contained, naming the files and interfaces involved, stating what is out of scope, and ending with an end-to-end check that proves the feature works. The same holds whichever agent reads the document.

The seven sections

• Goal. One outcome, in one or two sentences, and how you will know it happened. “Customers can book a walk without messaging me” is a goal; “a modern booking experience” is not.
• Users and their needs. Who uses it and what they need to do. The GOV.UK Service Manual’s guidance on user needs↗ (opens in a new tab) is a good discipline here: write the need, not a solution, for example needing a reminder rather than needing an email.
• Scope and non-goals. What this version does, then a list of things it does not do. Non-goals are the section agents benefit from most, because without them a helpful agent adds the obvious next feature.
• Requirements with acceptance criteria. Numbered, one behaviour each, with criteria that can be checked by someone who was not in the room. Given/When/Then and checklists both work; acceptance criteria examples has twenty.
• Constraints. The stack and the parts of the codebase to use, what must not change, privacy and security rules, performance limits. These are rules, not preferences.
• Open questions. Each with who will answer it. The instruction to the agent is to stop and ask when it reaches one, never to decide.
• Done means. The end-to-end check: the sequence a person will run to accept the whole thing.

If requirements keep coming out vague, borrow a fixed sentence pattern. Kiro’s feature specs↗ (opens in a new tab) use EARS notation, “WHEN [condition or event] THE SYSTEM SHALL [expected behaviour]”, which forces every requirement to name a trigger and an outcome you can test.

A template to copy

# [Product or feature name]

## Goal
[One outcome, and how you will know it happened.]

## Users and their needs
- [Type of user] needs to [do what] so that [why].

## In scope
- [What this version does.]

## Non-goals
- [What it does not do, even if it seems obvious.]

## Requirements
R1. [One behaviour.]
    Acceptance:
    - WHEN [condition] THE SYSTEM SHALL [observable result].
    - WHEN [error case] THE SYSTEM SHALL [observable result].
R2. ...

## Constraints
- Stack / code to use: [...]
- Must not change: [...]
- Data and privacy: [...]
- Limits: [numbers, not adjectives]

## Open questions
- [Question] (Owner: [name]). Agent: stop and ask; do not decide.

## Done means
1. [Step a person runs] -> [what they should see].

A worked example

A dog walker who takes bookings by text message wants a small web app, built with an AI agent, so customers can request walks themselves.

# Walk requests

## Goal
Regular customers request walks without messaging. Success: in the first
month, most requests arrive through the app instead of by text.

## Users and their needs
- A customer needs to request a walk for a day and time slot so that they
  know it is booked without waiting for a reply.
- The walker needs to see the week's requests and accept or decline each.

## In scope
- Customer sign-in by emailed link, request a walk, see its status.
- Walker view of the week, accept or decline.

## Non-goals
- Payments, recurring bookings, several walkers, a mobile app, reviews.

## Requirements
R1. Request a walk.
    - WHEN a signed-in customer picks a date and a slot (morning or
      afternoon) and a dog THE SYSTEM SHALL save a request as Pending.
    - WHEN the date is in the past or more than 28 days ahead THE SYSTEM
      SHALL refuse it and say why.
R2. Walker decides.
    - WHEN the walker accepts or declines THE SYSTEM SHALL email the
      customer within one minute and show the new status.
R3. Capacity.
    - WHEN a slot already has 4 accepted walks THE SYSTEM SHALL not offer
      it to customers.

## Constraints
- Existing Next.js app and its Postgres database; no new services.
- Store only name, email, dog name and address. Nothing else.
- Pages load in under two seconds on a phone on 4G.

## Open questions
- Can a customer cancel an accepted walk, and until when? (Owner: walker)

## Done means
1. Customer signs in, requests Tuesday morning -> sees Pending.
2. Walker accepts -> customer gets an email and sees Accepted.
3. Fill Tuesday morning with 4 accepted walks -> it is no longer offered.

Note what the example does not say: no component names, no table design, no library choices beyond the constraints. Those belong in the plan the agent drafts from this, which a person then reviews.

Mistakes that make an agent guess

• A solution dressed as a requirement: “add a calendar widget” instead of the need it serves. The agent builds the widget and misses the need.
• Adjectives: “quick”, “intuitive”, “secure”. Each needs a number, an example or a rule.
• No non-goals. The agent adds recurring bookings because they seemed helpful, and now you have a feature to test, maintain and explain.
• Assumptions nobody wrote down, such as the time zone or who counts as an admin.
• One enormous PRD for a whole product. Split it by release, or by the outcomes someone would accept one at a time.

From PRD to tasks

A PRD is not a work list. The usual next step is a plan and a set of small tasks, each finishable and checkable on its own. Tools can do the split: Taskmaster and Claude Code parses a PRD into a dependency-ordered task file, and GitHub Spec Kit goes from a spec to a plan to tasks.md. Or ask the agent directly, and review its split before any code is written.

On a fenbs board, a good default is one feature task per requirement, since each already has its own acceptance criteria. The note holds the requirement and its criteria, written once; the plan box stays empty until someone knows how it will be built. Open questions go on the Decisions page, where only a person can be the decider, and the tasks that depend on one are linked to it. Priority runs 1 to 10, and Next Up holds what comes next.

Read docs/prd.md. For each requirement R1..Rn, fenbs_search first; if no
task exists, fenbs_create_item with kind feature, the requirement and its
acceptance criteria as the note, and no plan yet.
For each open question, fenbs_add_decision as an open question naming the
owner, linked to the tasks that depend on it.
Do not write code. List what you filed.

A PRD is not the same as a spec

Usage varies, and plenty of teams use the words interchangeably. A useful working distinction: a PRD describes a product or release from the user’s side, the why and the what, and can cover several features. A spec describes one feature in enough detail to implement and test against, and sits next to a technical plan. One PRD often produces several specs. In spec-driven development, the spec is the document each piece of work is checked against; the PRD is where those specs come from and what they must add up to.