An AI PRD is a product requirements document you write with an AI model in the loop. You describe the problem, the audience, and the constraints; the AI helps you draft the goals, user stories, scope, and acceptance criteria. The result is still an ordinary PRD — the AI just gets you to a solid first draft in minutes instead of an afternoon staring at a blank page.
That is the obvious use. The more interesting one, and the reason this guide exists, is what happens after you write it. If your PRD is a markdown file, it is not just a document your team reads — it is a spec your AI coding agents can open and execute. This is the pillar for a set of deeper guides on writing requirements with AI:
What is a PRD?
A plain-language definition of the product requirements document, what goes in one, and who it is for.
How to write a PRD
A practical, step-by-step way to write a PRD — with or without AI — that people and agents can act on.
PRD template
A copy-paste markdown template with every section a good PRD needs, and notes on what to put in each.
PRD examples
Real, worked PRD examples for common feature types, so you can see the shape before you write your own.
PRDs for AI coding agents
How to write a PRD an AI agent can actually execute — file format, acceptance criteria, and handing off the spec.
What a PRD is, in one paragraph
A product requirements document (PRD) says what you are building and why, before anyone builds it. It captures the problem, who has it, what success looks like, the scope of the first version, and the acceptance criteria that tell you it is done. It is not a design spec and not a project plan — it is the shared source of truth that keeps a team pointed at the same outcome. If you want the full definition, start with what is a PRD.
Why write a PRD with AI
The blank page is the hardest part. You know the feature in your head, but turning that into clear goals, edge cases, and testable criteria takes time and discipline. This is exactly what a language model is good at.
Give an AI the problem and a bit of context, and it will draft the parts people skip when they are rushing:
- Goals and non-goals — it forces you to say what you are not doing, which is where most scope creep hides.
- User stories — it turns "let users export their data" into concrete stories with a who, a what, and a why.
- Edge cases — empty states, error paths, permissions, the stuff you only remember in code review. AI is unusually good at listing these.
- Acceptance criteria — the testable statements that tell you the feature is actually done.
The AI is not deciding what to build. You are. It is doing the writing you would have done anyway, faster and more completely, so you can spend your time on the judgment calls. That division — the AI drafts, you decide — is the whole game.
What an "AI PRD generator" actually does
If you have searched for an "AI PRD generator," here is what most of them do under the hood, so you can decide whether you need a tool at all:
- You type a one-line description of the feature.
- The tool sends it to a language model with a PRD-shaped prompt.
- You get back a structured document — problem, goals, user stories, criteria.
- You edit it into something real.
You can do all of this in any AI chat with a good prompt, and the how to write a PRD guide gives you one. A dedicated generator mostly buys you a nicer template and a place to keep the output. What it usually does not do is make the PRD useful to the agents that will build the feature — and that is the part worth caring about.
The part everyone misses: the PRD as an executable file
Here is the shift. For its whole history, a PRD has been a document people read. It sat in a wiki or a doc tool, someone read it, and then a human translated it into code.
Now some of the people building the feature are AI coding agents. And an agent does not want a document in a wiki — it wants a file it can open. When your PRD is a markdown file in the same workspace as your tasks and your code, the agent can read the spec, pick up the work, and check its output against the acceptance criteria you wrote. The document stops being a handoff artifact and becomes the actual instruction.
That only works if the PRD is written for it. A few things change:
- It is a file, not a page in a doc tool. Markdown, in the workspace, next to the work.
- The acceptance criteria are concrete. "The export button downloads a CSV of the visible rows" — something an agent can implement and verify — not "exports should feel fast."
- The scope is explicit. Goals and non-goals in plain lists, so the agent builds the thing you asked for and not the thing next to it.
The PRDs for AI coding agents guide goes deep on how to write one an agent can run.
What goes in a good PRD
Whether you write it by hand or with AI, a PRD has the same bones. Here are the sections worth including, and skippable sections you can drop for a small feature:
| Section | What it answers | Skippable for small work? |
|---|---|---|
| Problem | Why are we doing this at all? | No |
| Goals / non-goals | What does success look like, and what are we not doing? | No |
| Users | Who has this problem? | No |
| User stories | What can someone do when this ships? | No |
| Requirements | What the thing must do | No |
| Acceptance criteria | How do we know it is done? | No |
| Design notes | Links to mockups, constraints | Yes |
| Rollout / metrics | How it ships, how we measure it | Yes |
The PRD template gives you a copy-paste version of all of these, and how to write a PRD walks through filling each one.
A workflow that actually holds up
Put the pieces together and a practical AI-assisted PRD workflow looks like this:
flowchart LR
a[Problem in your head] --> b[AI drafts the PRD]
b --> c[You edit + decide scope]
c --> d[PRD lives as a markdown file]
d --> e[Agents read + execute]
e --> f{Meets acceptance criteria?}
f -->|No| e
f -->|Yes| g[Shipped]The AI helps at the front (drafting) and the back (executing). The judgment in the middle — deciding what to build and where the scope ends — stays with you. That is the version of "AI PRD" that is worth building around.
Common mistakes
A few things go wrong often enough to name:
- Letting the AI decide scope. The AI will happily generate an enormous PRD. Your job is to cut it down to the first version. A PRD that tries to do everything ships nothing.
- Vague acceptance criteria. "It should be intuitive" is not testable. If an agent — or a new engineer — cannot verify it, rewrite it.
- Keeping the PRD where the builders can't reach it. A spec locked in a doc tool the agents can't open is a spec that gets ignored. Keep it as a file, in the workspace.
- Writing it once and never touching it again. The PRD is a living file. When scope changes, change the file. The version in the repo is the truth.
Where sfora fits
sfora is a project workspace where humans and AI agents are members of the same team, and where everything — tasks, docs, and yes, your PRDs — is a markdown file. That is the piece a generic AI PRD generator is missing.
When you write a PRD in sfora, it is a real file the agents on your team can open over a Unix-style filesystem. You draft the spec, decide the scope, and drop it in the workspace; an agent reads it, picks up the linked tasks, and builds against the acceptance criteria you wrote. The PRD stops being a document that describes the work and becomes the instruction the work runs on.
You do not need a separate PRD tool and a separate place for your agents to work. In sfora they are the same place. See the docs for how agents read and write files.
- New to PRDs? Start with what is a PRD.
- Ready to write one? Follow how to write a PRD.
- Building with agents? Read PRDs for AI coding agents.