How to Write a PRD for AI Coding Tools (With a Prompt)

What a PRD is and why it helps an AI

PRD stands for product requirements document: a short document describing what product you want, what it should do and what is out of scope. On a team, it makes sure everyone understands the same thing before anyone writes code.

The same applies when you work with an AI coding tool. If you ask for 'a to-do app', it fills every gap with its own assumptions. A clear PRD cuts down those assumptions, gives you something to check the result against and works as a reference every time you start a new conversation.

The sections to include

• Goal: the problem the product solves, in one or two sentences.
• Users: who will use it and in what situation.
• Features: what it must do, ranked by priority (must-have, nice-to-have, later).
• Screens or flows: what the user sees and does, step by step.
• Rules and limits: what must never happen, such as one user seeing another user's data.
• Data: what information is stored and which fields are required.
• Acceptance criteria: how you will check that each feature is done.
• Out of scope: what you will not build in this version.

The most useful and most forgotten section is 'out of scope'. Without it, AI tools tend to add features you never asked for.

Acceptance criteria: the part you'll notice most

An acceptance criterion is a statement you can check with a yes or a no. 'The form is easy to use' isn't one. 'If the email address isn't valid, an error message appears and the form isn't submitted' is.

• Write each one as a situation and a result: 'Given X, when Y, then Z.'
• Cover error cases, not only the happy path.
• Aim for at least two or three criteria per important feature.

A prompt to draft the PRD with AI

You don't have to write the PRD from scratch. Tell an AI the idea and let it interview you. Then review the result yourself: the AI proposes, but the decisions are yours.

Act as a product manager experienced with small digital products.

I want to write a PRD for this idea: [describe your product in two or three sentences].

Main user: [who they are].

Before writing anything, ask me whatever questions you need, one at a time, until the goal, the main features and what is out of scope are clear.

Once you have enough information, write the PRD with these sections: goal, users, features by priority, screens or flows, rules and limits, data, acceptance criteria (in 'given, when, then' format) and out of scope.

Don't invent requirements I haven't given you. If something is missing, mark it as 'to be decided'.

How to use the PRD with a coding tool

Don't paste a long PRD and expect everything to come out right on the first try. Use it as a map and build in parts.

• Keep the PRD as a file in the project so it's always at hand.
• Ask first for a build plan in steps and review it before any code is generated.
• Implement one feature at a time, with its acceptance criteria.
• When each one is finished, check the criteria one by one.
• If you change your mind, update the PRD first and then ask for the change.

Here is the PRD for my project:

[paste the PRD here]

Implement only this feature: [feature name].

It must meet these acceptance criteria: [list of criteria].

Don't add anything listed under 'out of scope'. When you finish, explain which files you changed and how I can check each criterion.

Common PRD mistakes

• Writing wishes instead of checkable requirements ('make it intuitive').
• Mixing too many ideas: one PRD, one product, one version.
• Leaving out priorities, so the AI treats everything as equally important.
• Forgetting personal data: if you store information about users, decide what you keep and why, and check the data-protection rules that apply to you through official sources.
• Not updating the document when the project changes.

From a form to a PRD with a template

The PromptNow template for AI-coding PRDs asks for your product, users and features in a form and produces a ready-to-paste prompt with the structure above. It saves you from the blank page, but the content is still yours and worth reviewing.

If you aren't sure what belongs in the first version, start with the template for defining your app's MVP and use that as the base for the PRD.