A PRD template AI coding agents can follow

Copy it into the repository, for example as docs/prd/<feature>.md, and point the agent at the file when the work starts.

# PRD: <feature name>

Status: Draft | Agreed | Building | Shipped
Owner: <name>
Last updated: <date>

## Problem
Who has the problem, what they do today, and what it costs them.
One short paragraph. Link the evidence: call notes, tickets, data.

## Outcome
What is true for the user once this ships, in one or two sentences.

## Scope
In scope:
- <behavior>
- <behavior>

Out of scope (do not build):
- <tempting adjacent feature>
- <refactor that can wait>

## Users and flows
1. <user> does <action> from <entry point>.
2. The product responds with <result>.

Edge cases:
- Empty state: <what the user sees>
- Error: <what the user sees, what is logged>
- Permissions: <who can and cannot do this>

## Decisions already made
- <decision>, because <reason>. Ruled out: <alternative>, because <reason>.

## Constraints
- Use <existing module, library or pattern> in <path>.
- Do not change <public API, schema or file>.
- <performance, security, accessibility or compliance limit>

## Acceptance criteria
- [ ] Given <state>, when <action>, then <observable result>.
- [ ] Given <state>, when <action>, then <observable result>.
- [ ] <test or lint command> passes.
- [ ] No changes outside <paths>.

## Open questions
- <question>. Owner: <name>.
  Until it is answered, stop and ask. Do not guess.

## Context for the agent
- Relevant files: <paths>
- Related docs and designs: <links>
- Run and test locally: <commands>

• Problem and outcomeWrite these for a person first. If a teammate cannot say why the work matters after reading two paragraphs, the agent cannot either.
• ScopeList the behaviors that ship. Then list what looks related and should not be built. The out-of-scope list is the one agents need most.
• Users and flowsNumbered steps from the entry point to the result, plus the empty, error and permission cases. These become tests.
• Decisions already madeEvery choice the team settled, with the reason and the rejected option. Without it, the agent may reopen the decision in code.
• ConstraintsPoint at real paths and modules. A rule like "use the existing date helpers in lib/dates" saves a new utility nobody asked for.
• Acceptance criteriaObservable results and commands that pass or fail. The agent should be able to run or inspect each one.
• Open questionsName an owner for each. The instruction to stop and ask keeps an unanswered question from turning into an assumption.
• Context for the agentLinks and paths, not pasted content, so the agent reads the current version of each source when it needs it.

A criterion helps an agent when it describes a result someone can observe or a command that passes. The Claude Code docs make the same point about instructions: “Run npm test before committing” works better than “Test your changes”.

The numbers and paths in the right-hand column are placeholders for your own.

• Pasting the whole discussion. A Slack thread holds the decision and every rejected idea before it. Write down the decision.
• Mixing what and how. Keep the product intent in the PRD and the implementation design in a technical spec, so each can be reviewed by the people who own it.
• One document for many changes. A PRD per change keeps scope small enough to review and lets each agent start from only what it needs.
• A PRD that never changes. When the build teaches the team something, update the document, so the next session starts from what is true.

Ask the agent for a plan and a task list before it writes code, and review that list against the acceptance criteria. Spec-driven toolkits such as GitHub Spec Kit formalize this order: a specification of what and why, then a technical plan, then tasks, then implementation. Hamster's open-source Taskmaster parses a PRD into tasks with dependencies from the command line or over MCP. The page on spec-driven development covers the loop in more detail.

In Hamster the same sections are split across objects the team works on together. Hamster drafts the Brief from a chat: what will ship and why. The team refines it and records alignment votes. The linked Technical Spec holds the implementation decisions, and the Plan turns the agreed direction into Tasks with acceptance criteria, priority and dependencies.

Coding agents read the result through hamster sync, which writes Briefs and Tasks as markdown into .hamster/ in the repository, or through the Hamster MCP server. On the Team plan, Cloud Agents can deliver a Brief or Task to a pull request without a laptop in the loop.