How to write a PRD for AI coding tools

“Build a simple approval dashboard” contains many decisions. Who can approve? What happens after rejection? Can someone edit a request while approval is pending? Is a displayed total calculated from live data or a sample?

If the PRD leaves those questions open, an AI coding tool still has to choose behavior to produce a working application. You may discover those choices only when the interface looks finished.

Writing PRDs for AI code generation tools means making the intended behavior and its verification explicit. The document should help the agent identify what to build, what to leave alone, and which questions require a decision before implementation.

Separate product intent from implementation choices

The PRD should explain the user, problem, intended outcome, and product rules. A technical plan can then describe how the existing system will implement them.

This separation leaves room for an engineer or coding agent to inspect the codebase. It also avoids turning an early product document into an unsupported architecture mandate.

For example, “Only the assigned approver can accept a request” is a product rule. The particular authorization mechanism belongs in the technical plan, informed by the application's architecture. Both need review, but they answer different questions.

GitHub's Spec Kit provides one example of a process that carries a specification into planning, tasks, and implementation. You can apply the same discipline without adopting a particular toolkit.

Describe one complete user journey

Use a narrow feature to expose ambiguity. In this fictional example, a team wants employees to submit purchase requests for manager approval.

The first release might cover one request type, one assigned approver, and one approval decision. Multi-stage approvals and accounting synchronization are excluded.

Describe the journey from the user's starting condition through the resulting state:

1. An employee starts a draft request.
2. The employee enters the required information.
3. The employee submits it for the assigned manager's review.
4. The manager approves or rejects it.
5. Both users can see the final decision.

Now ask what happens between those steps. Can the employee save an incomplete draft? What happens if a manager has not been assigned? Does rejection require a reason? The journey reveals decisions a screen list alone can miss.

Specify states and transitions

“Add a status field” is weaker than defining how the status changes.

These are illustrative product choices, not universal approval rules. The point is to make the choices visible before code makes them difficult to notice.

Also specify whether editing is allowed in each state. If you have not decided, put that question in a blocking decisions list. Do not hide it behind “standard workflow behavior.”

Include the unhappy path in the requirement

A feature description should cover empty results, invalid input, denied access, unavailable services, and recovery where those cases apply.

For the approval example, a manager may open a request that another authorized action has already finalized. The interface should show the current state rather than falsely implying a new decision succeeded.

Avoid describing only what appears on the screen. A disabled button is useful feedback, but it does not by itself establish the underlying permission rule. Define the rule and require the implementation to enforce it through the appropriate application layers.

Name the required data and its meaning. “Amount” needs a currency and validation rule. “Approver” needs a source and assignment rule. Do not include real credentials or sensitive records as sample inputs; use representative synthetic examples.

Give every requirement a way to prove it works

Attach acceptance criteria to the behavior rather than to the implementation's own description of success.

An example:

Given a pending request assigned to Manager A, when Manager B attempts to approve it, the request remains pending and the application reports that the action is not permitted.

Pair it with the allowed case and any relevant concurrency case. This creates a useful review target even if the agent chooses a different implementation than you expected.

Anthropic describes verification loops in Claude Code as a way to turn repeatable checks into part of the agent's workflow. Your PRD supplies the product-level expectations those checks need to cover. Passing a linter cannot prove that the right person can approve the right request.

Use a compact PRD structure

The following outline is sufficient for many bounded features:

Keep detail proportional to the feature. A small wording change does not need a full system specification. A workflow that changes permissions or records needs more than a screenshot and a headline.

Ask for an implementation plan before a broad build

Once the specification is usable, ask the coding agent to inspect the existing project and propose a bounded plan:

Read the PRD and relevant project instructions. Inspect the existing implementation before proposing changes. Map requirements to the areas affected and to verification steps. Identify contradictions, missing decisions, and assumptions. Propose the smallest complete implementation slice. Do not expand the approved scope.

Review the plan for missing behavior and unnecessary additions. Then implement a slice, inspect the result, and update the specification when a real product decision changes. Avoid maintaining a PRD that describes a different product from the one you are reviewing.

Keep the handoff reviewable

Worklayer can keep product context, a reusable PRD template, and the resulting document in one workspace. Use it to prepare the source material; give your coding workflow the specific approved files and project instructions it needs.

If you are starting from scattered notes, first use the PRD writing guide to establish the problem and scope. Then add the behavioral detail described here.

Before handing over the document, choose one failure case and one excluded feature. If a reader can tell what should happen in the failure case and why the excluded feature must stay out, the specification is beginning to do its job.