App PRD generator for AI coding agents

What a PRD is

A product requirements document, or PRD, says what you are building, who it is for and what counts as done. It is not a technical design. It does not say which database to use or how a screen is laid out in code. It says what the product has to do, and why, so that everyone building it makes the same decisions without asking each other every time.

On a team the PRD is usually owned by a product manager and read by designers and engineers. Atlassian's guide to requirements describes the usual parts: the purpose, the user stories, the assumptions, what is out of scope and the questions still open. For a first app built by one person, the same parts apply. They just fit on one page.

Why a coding agent needs one

A coding agent starts every session knowing nothing about your app. It can read the code, but the code does not say who the app is for, which features you decided to drop, or whether you plan to charge for it. If nothing written down answers those questions, the agent either asks you again or guesses, and a guess about scope usually means code you did not want.

The tools agree on where that context goes. Anthropic's Claude Code documentation describes CLAUDE.md as the file Claude reads at the start of every session, and suggests keeping it under 200 lines, because longer files cost context and get followed less reliably. Claude Code also reads an AGENTS.md when the repository has no CLAUDE.md. OpenAI's Codex guide says Codex reads AGENTS.md before doing any work, and agents.md describes the format as a README for agents, read by Codex, Jules, Cursor, Aider and others.

Those files are for how to work in the repository: commands, conventions, where things go. The product decisions belong in a separate file that the instructions file points to. That keeps the instructions short, and it gives you one place to change a decision when it changes. This tool writes both: a PRODUCT.md with the decisions and an AGENTS.md (or CLAUDE.md) that tells the agent to read it first.

What goes in a good one

A useful app requirements document answers a short list of questions, and answers each one specifically enough that someone could disagree with it.

• What it does, and for whom. One paragraph. "An app for people who keep killing their houseplants" is a requirement. "An app that helps people" is not.
• The problem. What goes wrong for the user today. This is what you check every new idea against.
• Core user stories. Three to five, in the form "As a [user], I want [action] so that [outcome]". More than that for a first release is usually a sign the scope is too wide.
• Platforms. iOS, Android or both. This decides which store accounts and credentials you need.
• Integrations. Payments, sign-in, push, analytics, crash reporting. Each one is an account to create and a key to configure, so say which ones are actually in the first release.
• Monetization. Free, a one-time purchase or a subscription, and what the paid tier unlocks. This changes the code, not only the store listing.
• Out of scope. The things you decided not to build yet. Agents are eager, and this list is what stops them.
• Design inputs. A logo, colours, fonts, reference apps, three adjectives. Leave a line empty if you do not have it yet. An invented brand colour tends to end up in the theme.
• A success metric. One number that tells you the first release worked, such as the share of new users who come back in week two.

Some decisions constrain each other, and a good brief does not let them contradict. The common one in mobile apps: Apple's App Review Guidelines (4.8) require an equivalent privacy-focused login option when an app offers third-party sign-in such as Google, which in practice means Sign in with Apple. The generator above applies that rule, and the others below, as you click.

How the NativeExpress setup skill uses PRODUCT.md

NativeExpress ships a PRODUCT.md at the root of the project, and the bundled skills read it before they act. The format is documented on the product brief page. It has seven sections, always in this order: Summary, Audience, Platforms, Features, Integrations, Monetization and Design inputs. Platforms, Features and Integrations are two-column tables with fixed values (yes or no, keep or remove, on or off), read by the first word of each cell.

On a fresh project, the setup skill starts with a discovery phase: six questions in one message, each with a proposed default. Its answers are written into PRODUCT.md. The agent then removes every feature marked remove and every integration marked off before configuring anything, so you do not set up accounts for services the app will not use. If the brief is already filled in, with no TODO line left in any section, the skill skips the interview and takes the decisions as given.

Other readers use parts of it. The design skill reads the Design inputs section. The submit scripts read Platforms to skip a store the app does not ship on, and check the feature and integration rows against the code before building the privacy declaration. Running yarn skills:doctor lists which sections are written and which decisions it read, and warns when the code and the brief disagree.

The rules the docs define are built into the form above. create is Pro-only, so keeping it turns payments on. A free app turns payments and the paywall off and removes create. Google sign-in on an app that ships on iOS turns Apple sign-in on. A section you leave blank keeps its TODO line, so the doctor reports it as unfinished instead of treating a placeholder as your decision.

If you are not using NativeExpress, the PRD.md tab gives you the same decisions as a plain document. Put it in your repository, point your AGENTS.md at it, and your agent has the context it would otherwise ask you for.