The PRD prompt: one prompt that writes a product requirements document an AI agent can build from

Copy everything in the block. Replace nothing; the prompt asks you the questions it needs.

You are helping me write a one-page product requirements document (PRD) that an AI coding agent will build a mobile app from. The document is for the agent, not for stakeholders: every sentence must constrain what gets built. No background, no market context, no rationale.

First, ask me these six questions, one at a time, and wait for each answer:
1. In one sentence: what does the app do, and for whom? (Format: "[App] lets [who] [do what] so that [outcome].")
2. Who is the first user — the person who uses it in week one — described as a role and a situation, not a demographic?
3. What are the three to five things that user does in the app, as scenarios: "The user [does X], sees [Y], and then [Z]." Include what they see when there is nothing yet (empty state) and when something fails.
4. What is deliberately NOT in version one? List at least three things you are tempted to include and are leaving out.
5. What data does the app keep, where does it come from, and does it need accounts, payments, notifications, camera, location, or offline use?
6. iPhone, Android, or both — and is there anything the app must match (an existing design, a brand, a backend, a regulation)?

Then write the PRD with exactly these seven sections, in this order, each as short as it can be while still deciding something:

1. One sentence — the answer to question 1, verbatim.
2. First user — one paragraph, role and situation.
3. Scenarios — a numbered list, each in the form "The user [does X], sees [Y], then [Z]." Include the empty state and one failure scenario. These become acceptance tests; write them so that a tester could check each one as pass or fail.
4. Out of scope for v1 — a bulleted list. Each item is a feature the agent must not build even if it seems natural.
5. Data and integrations — what is stored, what comes from outside, and which of accounts / payments / notifications / camera / location / offline are required. If none, say "none".
6. Platform and constraints — iPhone, Android or both; native; anything it must match.
7. Success in week one — one measurable sentence: what has to be true for v1 to count as working.

Rules: use the user's words from my answers where possible; do not invent features I did not mention; if an answer was vague, write the most conservative interpretation and flag it with [ASSUMPTION]; keep the whole document under one page.

What you get back is under a page, and every line in it is a decision. The next sections say what each decision is for.

The one sentence is the criterion for everything after it. In a build tool, it becomes the project description and the first line of the PRD file; every later prompt (“add a filter”, “make the list sortable”) is checked against it — by you and, in a structured tool, by the plan the agent writes. If a feature request needs a second sentence, it is v2.

The first user is a role in a situation, because that is what an agent can build for. “Busy parents” builds nothing; “a parent who has thirty seconds at school pickup and one hand free” decides the size of the tap targets, the number of steps to the main action, and whether the app needs a widget. Product managers already write this way in discovery notes; the prompt asks for it in the PRD because the agent reads the PRD, not the notes.

The scenarios section is the one the build agent uses most. In the form “the user does X, sees Y, then Z” each scenario is a checkable statement, which is what an acceptance criterion is. In Modaal, when Plan is on, the feature spec the agent writes before code has a User Scenarios section and a Testing Strategy section, in the docs’ own words; the scenarios you wrote go into the first and come back out of the second as the tests the build has to pass.

Two scenarios the prompt forces that PMs skip when writing for humans: the empty state — what the user sees before there is any data — and the failure — what happens when the network is gone or the input is wrong. Both are screens the agent has to build; leaving them out means the agent invents them, and invented empty states are the ones users meet first.

If you already work in user stories with acceptance criteria, paste them as the answer to question 3; the prompt rewrites them into the scenario form without losing the criteria.

The out-of-scope list is the section that saves the most tokens and the most weeks. A build agent given an app description will build what seems natural — login, settings, a profile screen, sharing — unless told not to. Each item in this list is a feature the agent must not build in v1 even if it seems natural, which is exactly the list a product manager keeps in the “later” column of the backlog.

Downstream this list bounds the first plan: in a spec-driven tool the plan for feature one is written against the PRD, and an item in section 4 cannot appear in it. The spec-driven development page has the mechanism; the short version is that a wrong direction is caught at plan price rather than build price.

Data and integrations becomes the schema and the dependency list. “Keeps a list of workouts with date, duration and heart-rate zones; syncs with Apple Health; no accounts” tells the agent to use local storage and HealthKit and to skip authentication entirely. The six checkboxes in the prompt — accounts, payments, notifications, camera, location, offline — are the six capabilities that each add a permission, a framework and a store-review question; naming them in the PRD means the plan includes them and the review does not surprise you.

Platform and constraints is where the native decision is recorded. “Both, native” in a tool that builds from one project means the logic is written once and each platform gets its own screens; “must match the Figma file” means the design is an input — design-to-code tools covers what survives from the file and what the PRD has to supply. A constraint like “must use our existing Supabase backend” is one sentence here and days saved later.

The last section is one measurable sentence, because it is the sentence you will read on the Friday after launch. “Five people from the pilot group log a workout on three separate days” is checkable; “users find it valuable” is not. It does not go into the build; it goes into what you do after the build, which is the part no tool does for you: test the app with real users before the store listing, not after.

Lovable’s page for product managers describes the PRD as an input to “create a custom internal tool or prototype a feature” — the document goes in, a web prototype or an internal tool comes out, and the FAQ on the same page asks “Do I need an engineer to go live?”. That is the honest shape of the web route: the PRD becomes something to look at and align on, and the production build is a second project.

In a native build tool the same PRD is the first artefact of the app that ships. In Modaal the Refine flow “writes a structured PRD to PRD.md” at the root of the project, the feature spec is written from it, and the code is Swift/SwiftUI and Kotlin/Jetpack Compose that stays in your Xcode and Android Studio projects. The Free plan covers one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually and adds both platforms and TestFlight/App Store distribution — details on /pricing. The difference for a product manager is not the prompt; it is what the document is allowed to become. Modaal for product managers is the page for that.