PRD template for AI coding agents

Last updated: August 30, 2026

A PRD for an AI coding agent needs five sections: goals, user stories with acceptance criteria, screens and states, edge cases, and an explicit out-of-scope list. The template below is copy-paste ready. It exists to remove the gaps an agent would otherwise fill by guessing, which is why the edge-case and out-of-scope sections matter most.

Why agents need a different PRD

A classic PRD is written to align humans, so it tolerates ambiguity; people ask follow-up questions. An agent doesn't ask, it assumes. Every unstated behavior becomes a silent decision made by the model. So a PRD for an agent optimizes for one property above all: no gap the agent has to fill on its own. Shorter than a corporate PRD, but stricter about edge cases, states, and what not to build.

The template

Copy this into a plan.md next to your code and fill it in:

# Feature: [name]

## Goal
[One paragraph: what this feature does and why it exists.
If you can't write this, stop and decide before prompting.]

## Users
[Who uses this. One line per user type.]

## User stories
[Each story: As a [user], I want [action], so that [outcome].]

- Story 1: ...
  - Acceptance: [observable behavior that proves it works]
- Story 2: ...
  - Acceptance: ...

## Screens and states
[Every screen or UI surface this touches. For each: what it
shows, empty state, loading state, error state.]

- Screen: ...
  - Default: ...
  - Empty: ...
  - Error: ...

## Edge cases
[The section that saves you an afternoon. What happens when:]

- Input is empty / too long / duplicated?
- The user lacks permission?
- The network call fails halfway?
- Two users act on the same data at once?

## Data
[New or changed entities and fields, in plain language.]

## Out of scope
[Explicitly. Anything a reasonable agent might build that you
do NOT want: settings pages, admin views, migrations, i18n...]

## Done means
[A checklist the reviewer can verify without asking you anything.]

Section notes: where agents go wrong

• Goal. Agents anchor hard on this paragraph. If it says "quick pricing page" you'll get quick; if it says "pricing page that converts trials," you'll get social proof and a FAQ. Choose the framing deliberately.
• Acceptance criteria. Write them as observable behavior ("clicking Save shows a toast and the row appears without reload"), not intentions ("saving works smoothly"). Agents can verify the former against their own work.
• States. The default screen always gets built. Empty, loading, and error states are where one-line prompts silently produce nothing. Listing them is half the value of the document.
• Out of scope. Uniquely important for agents: they're eager, and an unconstrained agent will happily add the settings page you never asked for. A "do not build" list is cheaper than deleting code.

From template to built feature

A PRD is step one of spec-driven development; the plan still needs designs and a technical spec before an agent should build it. You can run that whole loop by hand with this template, or automate it: BuildBoard's /create-feature command generates a PRD in essentially this structure from a one-line idea, then /create-mock, /create-plan, and /build-plan carry it through mockups, tech spec, and implementation (the full workflow is in how to plan features for Claude Code).