From an idea to a build-ready brief

Write a one-page PRD your AI builder can follow and a real user can test.

AI builders do what the prompt implies and fill gaps with guesses: a login screen, a dashboard, a payment page. A short PRD names who the app is for, what it must do, what it must not do, and how you will know each part works.

Start with a project See the workflow Use the starter brief

Direct answer

A PRD for vibe coding is a one-page brief the AI builder reads before every change. Include the first user and trigger, the one job, at most three must-have behaviors, explicit non-goals, the data and screens, an acceptance check for each must-have and a first-user test. Put it where your tool reads project context: Lovable's knowledge file, CLAUDE.md or AGENTS.md for Claude Code, and AGENTS.md or a referenced file in Cursor. Build one must-have at a time and update the PRD when a decision changes.

Best for: Founders and makers about to build an app from an idea with Lovable, Bolt, Replit, Cursor or Claude Code
Start with: An idea, one person who has the problem, and the builder you plan to use
Strong signal: A first build that passes its acceptance checks, then one real person completing the job
Evidence checked: October 21, 2026

Qualification boundary

Use a PRD when the builder keeps guessing.

A one-line prompt works for a demo. Once you want someone else to use the app, the builder needs the same few decisions every time it changes the code.

Use this workflow when

You are starting a new app or a new major feature with an AI builder.
You can name one person who has the problem, even if you have not spoken to them yet.
You want to stop the builder adding features nobody asked for.
You want a checklist to judge each build instead of clicking around.

Do not count this as proof

You need a full enterprise requirements document with stakeholder sign-off.
You want a generator that writes the PRD without your decisions.
You expect the PRD to prove that people want the app; only people can do that.
You need a security review, compliance sign-off or production-readiness certificate.

Smallest complete workflow

Six decisions on one page, then one build at a time.

Fill the template below in a plain Markdown file. Each step removes one thing the builder would otherwise guess.

01
Name the first user and trigger
Write one specific person and the moment they need the app: 'Roommates who share one fridge, right after someone pays for a grocery run.' If you cannot name one, talk to people before you build.
02
Write one job and at most three must-haves
State the job in a sentence, then list up to three behaviors the app must have for that job. Everything else is later. Three is a limit, not a target.
03
List non-goals explicitly
Name what the first version must not include, such as accounts, payments, notifications, an admin panel or a dashboard. Builders tend to add these by default; written non-goals give you a reason to reject them.
04
Describe the data and screens in plain words
List the few things the app stores and the screens a user moves through. Plain nouns are enough: list, item, who paid, amount. Leave framework choices to the builder unless you have a reason.
05
Give every must-have a check
Write what you will see when it works: 'An item added on one phone appears on the second phone after refresh.' Avoid words like fast, intuitive or modern that cannot be checked.
06
Put it where the tool reads it, then build one piece
Paste it into Lovable's knowledge file, or save it as PRD.md and reference it from CLAUDE.md or AGENTS.md. Ask the builder to plan before building, implement one must-have, run its check, and update the PRD when you change a decision.

Inspectable control

Example approval card — build must-have 1 only

This is an illustrative task card, not a claimed customer result or completed experiment.

Objective: Let two roommates add items to one shared grocery list from separate phones, as must-have 1 of the fictional Splitlist PRD.
Action: Implement must-have 1 in the supplied project. Return the change and the result of each acceptance check for review.
Target: One project and its repository. No login providers, payments, notifications or the other two must-haves.
Acceptance: An item added on phone A appears on phone B after refresh; empty items are rejected; the list fits a 390px screen without sideways scrolling; no other screen changes.
Stop condition: Stop if the data model would need user accounts, which the PRD lists as a non-goal, or if a check cannot be run in the sandbox.

ReviseRejectApprove exact scope

Copyable one-page PRD

Eight headings. One page. Every line checkable.

Illustrative example: Splitlist is a fictional shared grocery-list app. Replace every line with your own decisions; mark anything you have not confirmed with a person as an assumption.

First user and trigger: Roommates who share one fridge, right after one of them pays for a grocery run. Assumption: they already split costs by message.
One job: Know who owes what after each grocery run without a spreadsheet.
Must-haves (at most three): 1. Add items to one shared list from any phone. 2. Mark a run as paid by one person with the total. 3. Show each person's running balance.
Non-goals for version 1: No accounts or passwords (share a private link), no payments inside the app, no notifications, no receipts scanning, no admin panel.
Data: List, item (name, added by), run (paid by, total, date), member (display name). Balances are calculated, not stored.
Screens: Shared list; mark-as-paid form; balances. Mobile first at 390px wide.
Acceptance checks: An item added on one phone appears on the other after refresh. A $42 run paid by A between two members shows B owing A $21. Empty items and negative totals are rejected.
First-user test: Two real roommates use it for one grocery run. Pass: both can say who owes what without asking you. Record what confused them.

Decision scorecard

Judge the PRD by what it prevents and what it lets you check.

A good PRD is short and testable. These signals tell you whether it is doing its job.

One page

The whole PRD fits on one screen or page and names one user and one job.

Assumptions marked

Anything not confirmed with a real person is labelled as an assumption.

Checks pass

Each must-have has a check you can perform yourself, and the latest build passes it.

Scope held

Nothing from the non-goals list appeared in the build, or you removed it.

First-user completion

A real person finished the job without your help. A demo to yourself does not count.

Updated

When you changed a decision, the PRD changed in the same session.

Research proof format

Where each tool reads your project context

Documentation checked October 21, 2026. Tools change their context features often; confirm the current location before relying on it.

Lovable's knowledge file is always part of the context Lovable works with, and the docs say a good one reads like a one-page brief, not a wiki. Plan mode is recommended for anything bigger than a tweak.

Paste the one-page PRD into the knowledge file and plan before each must-have.

Lovable best practices

Claude Code loads CLAUDE.md, or a repository's AGENTS.md, at the start of every session as context, and says specific, concise instructions are followed more consistently.

Keep the PRD short and reference it from CLAUDE.md or AGENTS.md so every session starts with it.

Claude Code memory documentation

Cursor supports AGENTS.md in the project root and subdirectories, and its rules documentation advises referencing files instead of copying their contents.

Keep PRD.md as one file and point to it from AGENTS.md or a project rule.

Cursor rules documentation

Soloop builds from an idea or existing code in a sandbox and keeps an editable Product Doc with the product, target user, problem, advantage and current focus. It does not document a PRD generator.

Use the template on its own, or ask Soloop to help draft it in chat before approving a Build task.

Soloop product manual · updated September 24, 2026

Current product boundary

Plan with what actually runs today.

This is a template and a workflow, not a PRD generator. A clear PRD makes builds easier to check; it does not prove that anyone wants the app. The Splitlist example is fictional.

Template

Free

Copy the eight headings into any Markdown file. No signup is needed.

Drafting in chat

Live

Describe the idea and ask Soloop to question your assumptions and draft the PRD for review.

Product Doc

Live

Keep the product, target user, problem and current focus in Soloop's editable Product Doc.

Build

Live after approval

Soloop can build from an idea or supplied code in a sandbox and return changes and checks for review.

PRD generator

Not a feature

There is no one-click PRD generator; the decisions in the PRD are yours.

Other builders

Your project

Soloop does not edit Lovable, Cursor or Claude Code projects; paste the PRD there yourself.

Continue the loop

Market the app you builtFind the first 20 people who need it after the build.Validate the ideaTest the riskiest assumption before a larger build.Choose the first userCompare segments and exclusions before writing the PRD.Talk to the first userAsk about a recent instance before deciding the must-haves.Compare Bolt.new and SoloopReview app-building, hosting and approval workflows before choosing where to use your PRD.Compare Replit and SoloopCheck development, hosting and approval differences for a build with a defined scope.Compare v0 and SoloopCompare code generation and project workflows before choosing the next build task.Current Soloop capabilitiesReview Build inputs, the Product Doc and approval boundaries.

FAQ

Questions before the next move.

What should a PRD for vibe coding include?

The first user and trigger, one job, at most three must-have behaviors, non-goals, data, screens, an acceptance check for each must-have and a first-user test. That is enough for an AI builder to stop guessing and for you to judge each build.

Where do I put the PRD in Lovable, Cursor or Claude Code?

In Lovable, paste it into the project's knowledge file. In Claude Code, save PRD.md and reference it from CLAUDE.md or AGENTS.md. In Cursor, reference it from AGENTS.md or a project rule. Check each tool's current documentation, because these features change.

How long should a vibe coding PRD be?

One page. Lovable's docs describe a good knowledge file as a one-page brief, and Claude Code's docs say concise instructions are followed more consistently. Put detail into acceptance checks, not background.

Can Soloop write the PRD and build the app?

Soloop can help you draft it in chat, keep the essentials in its Product Doc and, after you approve a Build task, build from the idea in a sandbox. It has no one-click PRD generator, and it does not edit projects inside other builders.

Bring the product you already have

Bring your idea and one person.

Copy this brief and replace the brackets. Start with a project opens Soloop's homepage; paste the brief there. It is not transferred automatically. You can also paste the finished PRD into any other builder.

I want to build [app idea] for [specific person] who [trigger]. Help me write a one-page PRD with: first user and trigger, one job, at most three must-have behaviors, non-goals, data, screens, an acceptance check for each must-have, and a first-user test. Ask me clarifying questions first and mark anything I have not confirmed as an assumption. Do not start a Build task until I approve the PRD.

Start with a project