PRD template for AI coding agents (free, copy and paste)

A product manager pastes a PRD into an AI coding agent. The PRD says invites "should expire after a reasonable period" and that the team "may want to support resending." The agent ships 24-hour expiry and no resend button.

The PRD wasn't wrong. It was written for people, who ask follow-up questions. An agent doesn't ask. It reads every sentence literally and fills every gap with something plausible.

This post gives you a PRD template built for that reader. Its structure follows the spec template in GitHub's Spec Kit, checked on 5 November 2026, with sections added for non-goals and decisions. Copy it, fill it in, and keep it next to the code.

What makes a PRD agent-ready

Five properties separate a PRD an agent can build from and one it will misread:

Property	Why the agent needs it
Numbered requirements with MUST	Each one is a testable statement the agent can check its work against, and reviewers can cite
Given/When/Then scenarios	They turn intent into steps the agent can implement and test
Named edge cases	Unnamed edge cases get whatever behavior is easiest to write
Explicit non-goals	Silence reads as permission. The agent may build what you didn't rule out
Marked open questions	A visible marker tells the agent to stop and ask instead of choosing

Everything else, the research, the market context, the long rationale, can stay in a separate document for people. Link to it.

The template

# PRD: [Feature name]

- Status: Draft | In review | Approved
- Owner: [Name, role]
- Last updated: [Date]
- Related: [Link to research, designs, tickets]

## Problem
[Two or three sentences. Who has the problem, what it costs them today.]

## Users
- [User type]: [what they are trying to do]

## User stories

### US-1: [Short title] (Priority: P1)
[One sentence: as a [user], I want [capability], so that [outcome].]

Acceptance scenarios:
1. Given [starting state], When [action], Then [expected result].
2. Given [starting state], When [action], Then [expected result].

### US-2: [Short title] (Priority: P2)
...

## Requirements
- FR-001: The system MUST [specific, testable behavior].
- FR-002: The system MUST [specific, testable behavior].
- FR-003: The system MUST [behavior] [NEEDS CLARIFICATION: what is unknown].

## Edge cases
- What happens when [boundary condition]?
- What happens when [error or empty state]?

## Non-goals
- [Thing that is out of scope for this version, and why if useful.]

## Success criteria
- SC-001: [Measurable outcome, e.g. 80% of invites accepted within 7 days.]

## Assumptions
- [Something taken as true that, if wrong, changes the requirements.]

## Decisions
| ID | Decision | Owner | Status | Date |
|---|---|---|---|---|
| D-1 | [What was decided] | [Name] | Approved / Replaced by D-n | [Date] |

How to fill in each section

Problem and users. Keep these short. The agent needs enough to make sensible small choices, such as button copy or which error to show, not the whole business case.

User stories with priority. Spec Kit's template ranks stories P1, P2, P3 and asks that each be testable on its own. That lets the agent, and the team, ship P1 first and know it works without the rest.

Acceptance scenarios. Given/When/Then forces you to state the starting state, the action, and the result. "Given an expired invite, When the recipient opens the link, Then they see a page with a Request new invite button" leaves nothing to guess.

Requirements. One behavior per line, each with an ID and the word MUST. IDs matter: a pull request can say "implements FR-002", and a reviewer can ask "where is FR-004?" Spec Kit's template uses the same FR-001 numbering.

Open questions inline. Spec Kit's template marks unknowns inside the requirement, as [NEEDS CLARIFICATION: retention period not specified]. Keep that habit. Then add one line to your agent's instructions: when you reach a NEEDS CLARIFICATION marker, stop and ask.

Edge cases. Write them as questions. Empty states, limits, errors, permissions, and what happens to existing data.

Non-goals. The section people skip and agents need most. If bulk invites are out of scope, say so.

Success criteria. Measurable outcomes, so the team knows whether the feature worked after launch. The agent mostly ignores these; people need them.

Assumptions. Spec Kit's template ends with them for a reason. An assumption that turns out false means the requirements need to change.

Decisions. A short table of the calls made while writing the PRD, each with an owner and status. When one changes, add a new row and mark the old one replaced instead of editing it.

A filled-in example

# PRD: Team invitations

- Status: Approved
- Owner: Priya (PM, Growth)
- Last updated: 5 November

## Problem
Workspace admins add teammates by sharing one login. That breaks our
audit log and blocks SSO customers from adopting the product.

## Users
- Workspace admin: invites and manages teammates.
- Invitee: joins a workspace from an email link.

## User stories

### US-1: Invite by email (Priority: P1)
As an admin, I want to invite a teammate by email, so that they get
their own account in my workspace.

Acceptance scenarios:
1. Given I am an admin, When I enter a valid email and send, Then an
   invite email is sent and the invite shows as Pending.
2. Given a pending invite, When the invitee opens the link within 7
   days, Then they join the workspace as a Member.

### US-2: Expired invites (Priority: P2)
Acceptance scenarios:
1. Given an invite older than 7 days, When the invitee opens the link,
   Then they see a page with a Request new invite button.
2. Given an expired invite, When the admin selects Resend, Then a new
   link is sent and the old link stays invalid.

## Requirements
- FR-001: The system MUST expire invite links 7 days after sending.
- FR-002: The system MUST let an admin resend an expired invite.
- FR-003: Invited guests MUST NOT count toward paid seats.
- FR-004: An invite to an email with an existing account MUST add
  that account directly, without creating a new one.
- FR-005: The system MUST block invites to personal email domains
  [NEEDS CLARIFICATION: which domains count as personal?].

## Edge cases
- What happens if the admin who sent the invite is removed?
- What happens if the workspace is at its seat limit when a Member
  invite is accepted?

## Non-goals
- Bulk invites by CSV.
- Changes to SSO-provisioned users.

## Success criteria
- SC-001: 80% of invites accepted within 7 days.

## Assumptions
- Every invitee can receive email at the invited address.

## Decisions
| ID | Decision | Owner | Status | Date |
|---|---|---|---|---|
| D-1 | Invites expire after 7 days | Priya | Approved | 3 Nov |
| D-2 | Guests don't use paid seats | Priya | Approved | 3 Nov |

The success criterion is an example target. Set yours from your own data.

Where to keep the PRD

Keep the agent-ready PRD where the agent can read it: in the repository, for example under docs/prd/, or in the spec directory your spec-driven tool creates. Then point to it from your agent's instructions, so a session working on invitations reads it before planning.

Keep it current after launch, especially the Requirements and Decisions sections. The first build is easy; the second is where an old PRD does damage, because the next agent reads it as the current truth. For why that happens and how to avoid it, see spec-driven development problems.

Where Lockstep fits

Lockstep can take a PRD like this and turn it into reviewed requirements. Paste the brief, and Lockstep extracts the requirements with their source passages for the owner to approve, keeps open questions marked as open, and produces an implementation brief you can hand to engineering. When the PRD changes, changed requirements go back to review and earlier versions stay available. Once a developer connects their repo, their Claude Code sessions are briefed on the approved requirements that apply.

It doesn't write the PRD for you, and pasted briefs are maintained in Lockstep rather than synced from another document. Session briefings work with Claude Code today. See Lockstep for product teams.

Sources checked 5 November 2026

• https://github.com/github/spec-kit/blob/main/templates/spec-template.md
• https://github.com/github/spec-kit
• https://github.com/lockstep-team-agent/lockstep

Related reading

For the workflow around this template, see spec-driven development for product managers. For checking the build against it, see how do I know engineering built what the PRD said?. For the term, see PRD.