AI Coding Agent PRD Template: A Copyable Brief for Cursor and Claude Code
A practical, copyable PRD template for AI coding agents. Define the user problem, keep scope clear, give the agent the right context, and agree on how to verify the result.
Share
AI coding agents can turn a short request into working software quickly. That speed makes a clear product brief more valuable: when the problem, boundaries, and definition of done are vague, an agent can confidently build the wrong thing.
An AI coding agent PRD is a task-specific agreement between the person shaping the product and the person or agent implementing it. It explains who has the problem, what should change, what must stay true, and how the team will check the result. It does not need to prescribe every line of code.
The short answer
Give a coding agent a small, current brief with the user problem, evidence, desired behavior, in-scope and out-of-scope work, relevant source links, and observable acceptance checks. Keep stable project conventions in repository instructions. Keep the feature decision in the PRD.
That split matters. GitHub documents repository-level custom instructions for project context and separate task-specific prompt files. Claude Code documents CLAUDE.md and AGENTS.md as ways to provide instructions across fresh sessions. The exact files and behavior vary by tool, so check what your client actually reads before relying on a file being loaded.
Why a coding agent needs a product brief
A coding agent can inspect a repository and follow project instructions, but it cannot infer which customer problem matters most from the code alone. It also cannot decide which product trade-off the team has accepted unless that decision is stated somewhere it can access.
Practitioner discussions show two versions of this problem. In one Product Management thread, a team describes product documentation as scattered, partly stale, and difficult to interpret; the author is exploring repository files as context for future agents. In a Cursor discussion, a builder describes preparing a master PRD and separate feature PRDs before asking the coding tool to implement. These are self-selected examples, not representative research or proof that one process works for every team. They do make the recurring tension concrete: too little context creates guesswork, while an unmaintained document pile creates its own confusion.
The answer is not to paste the entire product wiki into every prompt. Give the agent the smallest useful set of current decisions, and link to the source when more detail matters.
Keep project context separate from the feature PRD
S
Specky Team
Writing about AI-native product development at Specky.
Use repository instructions for information that applies repeatedly:
What the product and codebase are for
Architecture, frameworks, and existing conventions
Security, privacy, accessibility, and testing requirements
Where source-of-truth product decisions and technical references live
Use the task-specific PRD for the change in front of the agent:
The user and the problem they face
What evidence supports the problem
The behavior the product should provide
What is in scope and what is explicitly out
The success signal and the checks that show the change works
A link is usually better than copying a long document. Name the source, say why it matters, and call out which decision is current. If two sources conflict, tell the agent to stop and ask instead of choosing silently.
Copyable AI coding agent PRD template
Copy this brief into your product workspace or repository. Keep each answer short; link to research, designs, or technical notes when they contain the detail.
1. Decision and user problem
Working title:
Decision owner:
Primary user:
Situation and problem:
Evidence: Link the interview, support thread, usage data, or other source. Separate observed facts from assumptions.
Why address this now:
What we still do not know:
2. Desired outcome
User outcome: What should become easier, safer, faster, or more reliable?
Product signal: What observable behavior would tell us the change helped?
Baseline: What do we know today? If there is no baseline, say so.
Guardrails: What must not get worse, such as error rate, completion quality, privacy, or user control?
Do not invent a target just to fill the field. If the baseline is unknown, instrument the behavior or run a small discovery check before setting a numeric goal.
3. Scope and non-goals
In scope:
Out of scope:
Must not: List actions or side effects that are not allowed.
Dependencies: Name the teams, systems, or decisions this work relies on.
A short non-goal can prevent a coding agent from expanding the request into a redesign, new integration, or broad cleanup.
4. Required behavior
Describe user-visible behavior in plain language. Include the normal path and important states.
Entry point: How does the user start?
Main path: What happens step by step?
Empty, loading, and error states:
Permissions and data handling:
Edge cases that change the decision:
Use numbered requirements when the team needs to refer to them in review. For each requirement, include a reason or source when that context will help the implementer make a trade-off.
5. Product and technical context
Current behavior: Link to the relevant screen, route, or existing workflow.
Relevant decisions: Link to the current product brief or decision record.
Constraints: Name platform, compatibility, latency, privacy, or policy requirements that are actually known.
Repository instructions: Point to the project instruction file or explain how to discover it.
Conflicts: If this brief disagrees with another source, stop and ask the decision owner.
6. AI behavior, if the feature uses AI
Inputs: What information can the model use?
Output: What should the product show or save?
Grounding: What source should support each important statement?
Uncertainty: When should the system say it does not know or ask a person?
Human control: Which actions require review or approval?
Failure handling: What does the product do when the model times out, returns malformed output, or lacks evidence?
Evaluation examples: Link representative cases, including difficult and negative examples.
Avoid requirements such as “make the AI smart” or “be accurate.” State what a user can inspect and what the system must do when it cannot meet the requirement.
7. Acceptance checks
Write checks that someone can observe. For example:
Given [starting condition], when [user action], then [visible result].
Given [missing or conflicting evidence], when [the system responds], then [safe fallback].
Given [a user without permission], when [they open the feature], then [restricted data is not exposed].
Given [a change that affects an existing workflow], when [the relevant regression check runs], then [the prior behavior still works].
Include the checks that matter for this change: automated tests, manual review, accessibility, analytics, or a release check. Do not add a test plan that the team cannot run.
8. Agent execution agreement
Inspect the relevant files and instructions before editing.
Summarize the requirement and list unresolved questions before making broad changes.
Propose a small implementation plan.
Ask before making a material product decision that this brief leaves open.
Implement the smallest slice that satisfies the acceptance checks.
Run the checks named above and report what passed, failed, or could not be run.
Summarize changed behavior, assumptions, and remaining risks.
Filled example: summarize an interview for a product team
This is an illustrative example, not research from a real Specky customer.
Problem: A small product team has interview notes in several documents. Before a planning discussion, the team wants to find recurring problems without losing the participant evidence behind each theme.
Desired behavior: A team member selects a transcript and asks for a draft theme summary. Each theme links to the source passages that support it. The member can edit the summary before sharing it.
In scope: Draft themes, source links, and an editable review step.
Out of scope: Publishing themes automatically, changing the roadmap, or presenting a theme count as a representative estimate of the whole market.
Must not: Invent a quotation, attach a statement to the wrong participant, or claim frequency when the available interviews do not support it.
Acceptance checks:
Given a transcript with a passage about a recurring setup problem, when the draft summary includes that theme, then the reader can open the exact supporting passage.
Given a passage that is ambiguous or lacks enough context, when the model cannot support a theme, then the summary marks it as uncertain rather than filling the gap.
Given a generated summary, when the team member reviews it, then the member can edit it before it is shared.
Given a transcript containing personal information, when the feature processes it, then the product follows the workspace's existing data and access rules.
Before setting a success target, the team would establish a baseline for the time needed to find evidence and the corrections reviewers make. The example does not assume a particular improvement.
A practical handoff workflow
Start with evidence. Link the customer signal or explain that the idea is still an assumption.
Write the decision before the solution. State whose problem matters and what outcome should change.
Add only relevant context. Point the coding agent to current instructions and product sources; do not attach every document.
Ask the agent to restate the brief. Correct misunderstandings and resolve open questions before implementation.
Review the plan. Check scope, affected workflows, data handling, and acceptance checks.
Build in small steps. Keep changes reviewable and pause if new product decisions appear.
Verify and learn. Compare the result with the acceptance checks, then record what the team learned.
Is an AI coding agent PRD different from a normal PRD?
The product questions are the same: who has the problem, what should change, and how will the team know? The handoff benefits from making scope, source context, and checks especially explicit because an agent can act on an ambiguous request quickly. Keep the brief proportional to the size and risk of the change.
How long should a PRD for Cursor or Claude Code be?
Long enough to make the decision and verify the result; short enough that the important constraints stay visible. A small, reversible interface change may need a short task brief. A feature that changes permissions, handles sensitive data, or makes AI-generated claims needs more detail and stronger checks.
Should the coding agent write the PRD?
It can help turn notes into a first draft, organize open questions, or suggest edge cases. A product owner should verify the user problem, evidence, scope, and success signal. Generated prose is not evidence that the team has made those decisions.
Where should the PRD live?
Put it where the team can find and maintain it, then link it from the task or pull request. Repository instruction files can carry stable project context when the chosen tool supports them; they do not replace a feature-specific product decision.
Sources and further reading
GitHub Copilot custom instructions explains repository-level project context and task-specific prompt files, with support varying by client.
A good PRD does not make product judgment automatic. It gives a person or coding agent enough current context to make the next change reviewable, bounded, and connected to the user problem.