From PRD to backlog: generating planned issues with AI without losing the thread back to the requirement
Turn a PRD into sized, labelled issues with AI: what to feed it, how to keep every issue linked to its requirement, and what to reject before it enters the backlog.
On this page
To generate a backlog from a PRD with AI, give the agent a frozen version of the requirements, ask for issues that each name the requirement they implement, carry acceptance criteria copied from it, and are small enough for one person in one cycle, then reject every issue that fails one of those three tests before anything enters the backlog. The agent is good at the tedious part, splitting and labelling; you are the only check on whether the split still adds up to the document.
This is the process we use at Atrix for our own product, where the agent writes planned issues from a requirements baseline and a human approves them. It works with any agent that can read a document and create issues, and the rejection rules are the useful part whichever tool you have.
Why the thread back to the requirement matters
A backlog generated from a PRD looks finished on day one: forty issues, neat titles, tidy labels. Two cycles later someone asks "did we build the export limit?" and nobody can tell, because the issue that covered it was split, renamed and merged with another, and the PRD was edited twice in the meantime.
The thread from each issue back to the exact requirement it implements is what lets you answer that question. It is also what lets an agent, or a person, run a coverage check later: which requirements have no issue, which issues point at no requirement, and which requirements changed after their issues were written. Without the thread, "coverage" is a feeling.
So the first rule is: freeze the PRD before generating, and make every issue cite a requirement by id.
Prepare the PRD before you hand it over
An agent will faithfully turn a vague PRD into vague issues. Thirty minutes on the document saves a day of ticket cleanup:
- Number the requirements. R1, R2, R3, or a nested scheme. The agent needs a stable handle to cite. Prose paragraphs are not handles.
- Give each requirement acceptance criteria. Two to four lines in "given / when / then" form or a plain checklist. If you cannot write criteria for a requirement, it is not ready to be an issue, and the agent will invent some.
- Mark non-goals. A short list of what is out of scope stops the agent generating issues for things you are deliberately not doing.
- Freeze it. Save a version, label it as the baseline, and generate from that version only. Later edits produce a new baseline and a delta, not silent changes to issues already in flight.
Our PRD template has these sections in this order for exactly this reason.
The brief for the agent
The brief is short and strict. Ours, lightly edited:
Input: PRD "Booking reminders" v3 (frozen baseline). Requirements R1–R9,
each with acceptance criteria. Non-goals section is binding.
Produce planned issues such that:
- Every issue names exactly one requirement id it implements.
- Every issue copies that requirement's acceptance criteria verbatim,
then adds any technical criteria.
- Every issue is small enough for one person to finish in one cycle;
if a requirement needs more, split it and say how the parts combine.
- Every issue carries one type label (feature, bug, chore) and one
area label from the existing label list; do not create labels.
- No issue implements a non-goal.
- List requirements you could not turn into issues and say why.
Create planned issues only. Do not change existing issues or statuses.
The last line maps to the agent's permissions. Planning runs get work.write for creating planned issues and nothing that touches the live board.
What a good generated issue looks like
| Field | Good | Reject |
|---|---|---|
| Title | "Send reminder email 24h before booking (R3)" | "Reminders" |
| Requirement | R3 | None, or "R3, R4, R5" |
| Acceptance criteria | R3's criteria verbatim, plus "retries once on SMTP failure" | "Works as expected" |
| Size | One person, under a cycle | "Build the reminder system" |
| Labels | feature, calendar | A new label the agent invented |
| Dependencies | "After #212 (template storage)" | Unstated |
The table doubles as the review checklist. Reviewing forty issues against six columns takes about forty minutes, which is faster than writing them and much faster than discovering the gaps later.
Rejection rules: what not to accept into the backlog
Reject, and send back to the agent with the reason:
- No requirement id. The commonest failure. The issue may be sensible, but you cannot trace it. Either it implements a requirement (cite it) or it is a chore (label it so) or it is scope creep (drop it).
- Several requirement ids on one issue. That is an epic, not an issue. Split.
- Acceptance criteria that paraphrase instead of copy. Paraphrase drifts. The criteria in the issue must be the criteria in the PRD, plus technical additions clearly marked as additions.
- "Works correctly" or "as designed" as a criterion. Not testable. Reject.
- Issues for non-goals. The agent read the non-goals and generated them anyway. It happens; reject.
- A size you cannot picture one person finishing in a cycle. If you cannot see the end, neither can the assignee.
- Invented labels or components. The agent should use the label list it was given. New labels are a human decision.
Two rounds is usually enough. If the third round still produces the same failures, the PRD is the problem, not the agent.
Planning the issues into cycles and labels
Once the issues pass, they are planned work, not committed work. In Atrix, project management keeps them in the backlog until a cycle is planned; a cycle is one to four weeks with a goal and a burndown that counts issues, and when a cycle closes, unfinished issues roll into the next one or back to the backlog. There are no story points: the sizing rule above ("one person, one cycle") is the whole estimation model, and it is deliberately coarse.
Labels belong to the workspace and carry a colour. We use one type label and one area label per issue, which is what the brief told the agent to apply. Milestones group issues across cycles when a requirement set has a shipping date.
The requirements audit then compares what was delivered against the frozen baseline and reports coverage and drift: which requirements have shipped issues, which have none, which changed after their issues were written. It compares requirements with the plan, not with the code; whether the code does what the issue says is still a code review.
The same workflow in Linear or Jira: Linear's projects and labels, Jira's epics and components. The thread back to the requirement is a convention in those tools rather than a feature, so put the requirement id in the issue title and keep the PRD in a place with version history.
FAQ
Can AI generate a backlog from a PRD?
Yes, and it does the splitting and labelling well if the PRD has numbered requirements with acceptance criteria and a non-goals list. It does not judge whether the split adds up, so every generated issue needs a human check against a short rejection list before it enters the backlog.
How should generated issues link back to requirements?
Each issue names exactly one requirement id and copies that requirement's acceptance criteria verbatim. The PRD is frozen as a baseline before generation, so later edits produce a new baseline rather than silently changing issues in flight.
How big should a generated issue be?
Small enough for one person to finish inside one cycle. If a requirement needs more, split it and state how the parts combine. This coarse rule replaces story points; Atrix has no points by design, and the burndown counts issues.
What should I reject from an AI-generated backlog?
Issues with no requirement id, issues citing several requirements, paraphrased or untestable acceptance criteria, issues for stated non-goals, issues too large to picture finishing, and invented labels. Send each back with the reason; two rounds usually suffice.
What is a product backlog?
The ordered list of planned work that has not yet been scheduled into a cycle. See the glossary entry on backlogs for how it differs from a roadmap and a cycle.
Does the requirements audit check the code?
No. It compares delivered issues against the frozen requirements baseline and reports coverage and drift. Whether the code does what the issue says is a code review, done by people.
Next step
Number the requirements in your next PRD, add acceptance criteria to each, and freeze it before you ask any agent for issues. The PRD template is laid out for this, and the AI agent page shows what a Develop run returns: requirements, architecture and planned issues, each pointing back at its requirement.