How to Write a PRD for AI Coding Agents (Free Template)

A PRD for AI coding agents is a short, testable requirements document. It tells the agent who the change is for, why it matters, what is in and out of scope, which limits apply, and how to prove the work is done.

Your agent is not bad at coding. It is bad at guessing, and a human PRD makes it guess at hundreds of unstated rules every time it opens the file. This guide shows what to cut, what to add, and how long to go, with a free template you can paste into Claude Code, Cursor, or any other agent today.

What is a PRD for AI coding agents?

A classic PRD is written to align people. It persuades, gives background, and leaves room for a designer or engineer to fill gaps with judgment. An agent-ready PRD does the opposite: it closes gaps, because an agent fills them with assumptions.

This document is the core input of spec-driven development. When GitHub released Spec Kit, its open source toolkit for spec-first work, it described a shift from code as the source of truth to intent as the source of truth. The PRD is where that intent gets written down.

Why does a human PRD fail an AI coding agent?

Most PRDs were never meant to be executed. They were meant to be discussed in a meeting, and the meeting filled in what the page left out. Hand that same page to Claude Code or Cursor, and nobody is in the room.

“they're exceptional at pattern completion, but not at mind reading.”

A human PRD breaks down in four ways.

• Ambiguity: Words like fast, simple, and secure mean nothing to a test runner. The agent picks its own meaning and moves on.
• Missing constraints: Human docs assume the team already knows the stack, the folder layout, and the house rules. An agent does not, so it may add a framework or rewrite a module you never meant to touch.
• No acceptance tests: Without pass or fail statements, the agent decides when it is done. That is usually when the code compiles, not when the feature works.
• Too long: A 12-page doc buries the one rule that matters somewhere in the middle. As the research below shows, models are weakest at using exactly that middle.

The same GitHub post makes this diagnosis directly: a vague prompt forces the model to guess at potentially thousands of unstated requirements. The fix is not a smarter model. It is a better page, the main lesson in our comparison of vibe coding vs. spec-driven development.

What does an agent-ready PRD contain?

An agent-ready PRD answers eight questions, in roughly this order. Each one closes a gap the agent would otherwise fill on its own.

• Who it is for: One named user or role. This tells the agent whose experience wins when tradeoffs appear.
• Why we are doing this: The problem and the outcome you expect. Agents make better small decisions when they know the goal behind the task.
• Scope: A short numbered list of behaviors this change must deliver. Three to seven items is a healthy range for one PRD.
• Non-goals: What not to build, refactor, or touch. Human PRDs skip this section most often, and agents need it most.
• Constraints: Language, framework versions, folders in bounds, and performance or security limits. State them as rules, not hopes.
• Acceptance criteria: Testable statements, one per behavior. If a test cannot pass or fail on it, rewrite it.
• Limits on dependencies: Name the libraries the agent may use. Require it to stop and ask before adding anything new.
• Examples: A sample input and expected output for each key behavior. One concrete example beats a paragraph of description.

Anthropic's guide to effective context engineering for AI agents lands in the same place. It warns against vague, high-level direction that gives the model no concrete signal, and against brittle, hardcoded logic at the other extreme. A good PRD sits in between: firm on outcomes and limits, flexible on how the agent writes the code.

How long should a PRD for AI agents be?

Short enough that every line gets used: one to three pages for most features, and never more than 2,000 words for a single section or change. Length is not a style choice here, because it changes how well the model follows the document.

The best-known evidence is the 2023 paper Lost in the Middle: How Language Models Use Long Contexts by Nelson F. Liu and six coauthors. They found models use information best when it sits at the start or end of the input, and worst when it sits in the middle. In one setup, accuracy with the key document in the middle fell below the score the model got with no documents at all.

Newer models have not escaped the problem. In July 2025, Chroma's Context Rot report tested 18 models, including GPT-4.1, Claude 4, and Gemini 2.5, and found performance grew less reliable as input length grew, even on simple tasks. On one memory benchmark, models did markedly better with a focused prompt of about 300 tokens than with a full prompt of about 113,000 tokens.

Anthropic describes this as an attention budget, where every token you add spends a little of the model's focus. Its advice is to find the smallest set of high-signal tokens that makes the result you want likely. For a PRD, that means cutting background, history, and persuasion, and keeping only what changes the build.

This is why Crema Spec's admission check caps every new section or revision at 2,000 words and turns it away if it does not say who it is for and why. The free Crema PRD skill writes to the same shape, so a draft starts inside the limit instead of being trimmed later. Short pieces also fit a 25-minute review cycle, so a person can actually read each one before approving it.

How do you turn a vague requirement into a testable one?

Rewrite every requirement until a test could fail it. A useful pattern is EARS, the Easy Approach to Requirements Syntax, which Kiro uses for the acceptance criteria in its requirements files. Each line takes the form WHEN a condition happens, THE SYSTEM SHALL do a specific thing.

Each rewrite has a trigger, a measurable result, and often a limit. Anthropic gives the same advice for standing rules: write instructions concrete enough to verify, such as a specific indentation width instead of a request to format code properly.

CLAUDE.md vs. PRD: what goes where?

CLAUDE.md, AGENTS.md, and Cursor rules hold standing rules for the whole repo. A PRD holds intent for one change. Mixing them is the fastest way to bloat both.

Per Anthropic's Claude Code memory docs, CLAUDE.md loads at the start of every session, works as context rather than enforced configuration, and should stay under 200 lines per file. Claude Code can also read AGENTS.md when a repo has no CLAUDE.md. AGENTS.md is an open format now stewarded by the Agentic AI Foundation under the Linux Foundation, and its site says over 60,000 open-source projects use it.

Cursor's rules docs describe project rules as files in a .cursor/rules folder that live in version control, and they suggest keeping each rule under 500 lines. Cursor also reads AGENTS.md. None of these files is meant to describe a single feature.

Here is a simple test. If an instruction will still be true in six months, it belongs in CLAUDE.md or AGENTS.md. If it is true only until this feature ships, it belongs in the PRD.

When a PRD rule keeps coming back feature after feature, promote it to the standing file and delete it from the template. Keeping the two apart also prevents spec drift, where old feature specs pile up inside a core doc no one can read.

Free AI PRD template: which sections should you include?

Copy this table into a new markdown file next to your code. Fill each row with one to five lines, and delete any row that truly does not apply. If you want an agent to draft it with you, the MIT-licensed Crema PRD skill is built for exactly this job.

Put who, why, scope, and non-goals at the top, and acceptance criteria and the definition of done near the end. That keeps the most important rules at the start and end of the document, where models use them best.

What are the steps to write an agent-ready PRD?

1. Write one sentence on who the change is for and one on why. If you cannot, the feature is not ready for an agent.
2. List three to seven behaviors in scope, then list at least three non-goals.
3. Add constraints: stack, versions, folders in bounds, and any security or performance limits.
4. Name the allowed dependencies and tell the agent to stop and ask before adding new ones.
5. Rewrite each behavior as a WHEN and THE SYSTEM SHALL statement that a test can pass or fail.
6. Add one input and output example for each key behavior.
7. Cut background, history, and persuasion until the document is under 2,000 words.
8. Move any rule that applies to every feature into CLAUDE.md or AGENTS.md.
9. Have a person read and approve the PRD before the agent starts, and link it in the pull request.

Teams running many agents at once should also record who approved each PRD and why. Our guide to decision records for AI teams covers that step. For the bigger picture, what is a software factory shows where the PRD sits in a full AI coding pipeline.

Writing agent-ready PRDs is the core skill of the product builder role. That makes this template a strong take-home exercise when you hire for it.