--- title: "How to Turn a PRD Into Agent Tasks" description: "A PRD is not a task list. Here is where to cut one into agent sized tasks, the dependency order that prevents rework, and what every task has to carry with it." canonical_url: "https://builderscamp.com/guides/other/how-to-turn-a-prd-into-agent-tasks" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Guilherme Salgueiro" publisher: "Builders Camp" guide_class: "other" --- # How to turn a PRD into agent tasks **TL;DR:** Turning a PRD into agent tasks means cutting at seams the agent can verify, then ordering the cuts so nothing gets built against something that has not settled yet: data shape, then logic, then surface, then anything spanning all three. Every task carries three things, an outcome, a check, and a boundary, and a task missing the boundary is how a small change quietly becomes a refactor. ## What makes a task executable by an agent rather than just readable? A requirement is written so a person can agree with it. A task is written so a machine can finish it and someone can tell, without reading the code, whether it did. That is the whole gap, and most of the work of turning a PRD into agent tasks is closing it. The practical test is one sentence long: can you state the check that proves this task is done, in a single sentence, with no "and" in it? "The invoice endpoint returns a 404 with a JSON error body when the invoice id does not exist" passes. "Invoices work properly" does not, and neither does "build the invoice page and wire it to the API", which is two tasks wearing one number. Anthropic's own guidance on building effective agents frames the same split as a deliberate trade. Prompt chaining decomposes a task into a sequence of steps where each call handles the output of the last, and the stated reason for doing it is to trade latency for accuracy by making each individual call an easier problem. More steps take longer. Each step is likelier to be right. ## Where do you cut a PRD, and why the seams matter Cut along things that can be verified independently, which is almost never the same as cutting along the PRD's own section headings. A requirements list is organised by what a reader needs to understand; a task list is organised by what can be finished and checked in isolation. In practice that means cutting vertically rather than horizontally wherever you can. A task that delivers one complete, thin path through the system, one record created, stored, read back and displayed, is verifiable end to end by a person clicking once. A task that delivers "all the data models" is verifiable only by reading code, and it hides the integration problem until later, when it is expensive. The exception worth naming: the first cut is usually horizontal on purpose. Something has to establish the data shape before anything else can be built against it, and that task's check is not a user-visible behaviour but a schema that exists and a migration that runs. ## The dependency order that stops rework Order the cuts so that nothing gets built against a decision that has not settled. In most features that means four bands, in this sequence: the shape of the data, the logic that reads and writes it, the surface a person touches, and then anything that only makes sense once all three exist, such as permissions spanning several screens or an export covering every record type. The reason this ordering is not arbitrary is that rework flows in one direction. Change a schema after three screens read from it and you have four tasks to redo; change a screen after the schema is settled and you have one. Agents make this worse than it used to be, not better, because they will happily build all three screens in the time it used to take to build one, which means an unsettled decision underneath propagates further before anyone notices. Write the order down as a numbered list with the dependency named on each line, not just implied by position. "Task 4 depends on task 2's error format" is the kind of sentence that stops a parallel run from producing two incompatible answers. ## Which tasks only look independent? Two tasks are parallel when they share no files and no unresolved decisions. The file part is easy to check. The decision part is where people get caught. Consider two screens that both display a list and both need to handle the empty case. Neither touches the other's files. But if nobody has decided what an empty state looks like, each will invent one, and you will end up reconciling them later at the cost of a third task. The rule that holds up: any decision that more than one task depends on gets made before either task starts, even if making it takes ten minutes and feels premature. Once that is done, real parallelism is available and worth using. [Parallel worktrees](https://builderscamp.com/guides/glossary/parallel-worktrees) let separate agent runs work on genuinely independent branches of the same repository without stepping on each other, and [multi-agent orchestration](https://builderscamp.com/guides/glossary/multi-agent-orchestration) covers coordinating the results. Anthropic's orchestrator-workers pattern is the version where you cannot predict the subtasks in advance, a central model breaks the work down and delegates, which fits exploratory changes better than it fits a feature you have already specified. ## What every task has to carry with it Three things, and a task missing any one of them will cost you a review cycle: - **The outcome.** What is true when this is finished, stated as behaviour rather than as an instruction. "A user with no invoices sees an empty state with a link to billing", not "add an empty state component". - **The check.** How anyone verifies it without reading the diff. A command that passes, a screen that shows a specific thing, a response body with a specific shape. Anthropic's prompt chaining pattern calls the programmatic version of this a gate, placed between steps so drift is caught mid-run rather than at the end. - **The boundary.** Which files or areas the task may touch, and what it must not change. This is the one people skip, and skipping it is how a two-line fix arrives as a diff touching eleven files because the agent noticed something adjacent it could improve. Context travels with the task too. A [Product Requirement Prompt](https://builderscamp.com/guides/glossary/product-requirement-prompt) is the packaging for exactly this: the requirement, the codebase context, and the execution steps in one bounded packet, scoped to a single feature rather than a whole product. ## Where does this break down? When the PRD itself has not decided something. Decomposition is unforgiving that way: an ambiguity a human engineer would have resolved with a two minute conversation becomes a task the agent completes confidently in a direction nobody chose. You find out at review, having paid for the work. Builders Camp's AI Agents bootcamp builds its practical challenge on the downstream version of this failure. A three agent pipeline replaces a manual weekly customer health report, a classifier, a summary writer and a report compiler, and it sends a false churn alert on the company's largest account. Each agent did its job. The pipeline had no gate between the classification and the message that went out. Decomposition without verification between the pieces produces exactly that outcome, faster. ## Who this is for, and who it is not for This fits a product manager or technical lead handing specified work to coding agents and wondering why the output needs so much rework. Builders Camp's Building with Claude Code bootcamp covers the surrounding system across 1 week and 2 live sessions, including when a Product Requirement Prompt beats a traditional PRD, multi-agent orchestration across worktrees, and the hooks and quality gates that enforce the checks rather than reminding people to run them. Its practical challenge puts you inside a team that shipped a broken deploy because nobody defined what done meant, and asks you to design the operating model that would have prevented it. Delivery-heavy product managers usually meet the planning half of this inside the Product Delivery Specialist Track. It is not the right page if the spec itself is unsettled. Decomposing an undecided PRD produces a task list that looks organised and encodes guesses, and the cheaper fix is upstream, in the [PRD](https://builderscamp.com/guides/templates/prd-template) itself. ## Number the tasks, then delete the ones nobody asked for Once the list exists, run one pass backwards: for each task, name the requirement it serves. Tasks that point at no requirement are the decomposition's own inventions, and they are common, because breaking work down is a generative act and generative acts add. Deleting those three or four tasks before anything runs is the cheapest hour in the whole process, and it is the step people skip because a longer plan feels more thorough than a shorter one. [See the Building with Claude Code bootcamp](https://builderscamp.com/bootcamps/building-with-claude-code?utm_source=guide&utm_medium=organic&utm_campaign=how-to-turn-a-prd-into-agent-tasks) For coordinating several runs at once, see [multi-agent orchestration](https://builderscamp.com/guides/glossary/multi-agent-orchestration). For the delivery skills underneath the planning, see the [Product Delivery Specialist Track](https://builderscamp.com/tracks/product-delivery). ## Frequently asked questions ### How big should a single agent task be? Small enough that you can state the check that proves it worked in one sentence. If the verification sentence needs an 'and' in it, you have two tasks. Anthropic's guidance on prompt chaining makes the same trade explicitly: splitting work into a sequence of easier calls buys accuracy at the cost of latency. ### Should the agent do the decomposition itself? For work where you genuinely cannot predict the subtasks, yes, which is what Anthropic calls the orchestrator-workers pattern: a central model breaks the task down and delegates. For a feature you already understand, doing it yourself is faster and produces a plan you can argue with before any code exists. ### What belongs in every task, without exception? The outcome, the verification, and the boundary. What should be true when this is done, how anyone can check it mechanically, and which files or areas the task is allowed to touch. Missing the third is how a small task quietly refactors something adjacent. ### What is the right dependency order? Data shape first, then the logic that reads and writes it, then the surface a user touches, then anything that depends on the whole thing working. Ordering it the other way produces a screen built against a schema that changes underneath it, which is the most common source of rework. ### Which tasks can actually run in parallel? Tasks that share no files and no assumptions. Two screens reading the same finished data layer are genuinely parallel. Two tasks that both need to decide how errors are represented are not, even though they look independent, because whichever finishes second will contradict the first. ### How do you stop an agent from running past the task? State the stop condition and the out of scope list in the task itself, then check the diff against the boundary rather than against your memory of what you asked for. A programmatic check between steps, what Anthropic's prompt chaining pattern calls a gate, catches drift earlier than a review at the end does. ### Does this replace the PRD? No. The PRD is where the scope decision lives and the task list is where execution lives, and collapsing them loses the record of what was deliberately left out. Keep both, and make each task point back to the requirement it serves so an orphan task is visible. ## Sources - [Anthropic: Building effective agents](https://www.anthropic.com/research/building-effective-agents) - [ASDLC.io: Product Requirement Prompt (PRP)](https://asdlc.io/concepts/product-requirement-prompt/) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.