A PRD for Lovable
goes in two places, and neither is the first message.

Most PRDs for Lovable are pasted into the first chat message, and by the tenth message they are gone. Lovable builds from what it can see, and what it can see in a long chat is the last few turns. The decision you made on line forty of the PRD is not one of them, so the fifteenth prompt gets a fresh guess.

Lovable has two places built for this. Project knowledge is persistent: its docs list “the application purpose, database schema, architecture decisions, or domain terminology” as what belongs there, up to 10,000 characters, remembered across every conversation. Plan mode is where the next change is thought through before code: it writes a structured plan to .lovable/plan.md, nothing changes until you approve it, and approving switches to Build.

So the PRD splits. What is always true goes in Project knowledge. What gets built next goes through Plan mode, one page at a time. The shape of the whole spec is in the first post; this one is where each half goes in Lovable.

Put here what every future prompt should already know. The one-sentence purpose. The words you use and the ones you refuse. The tables, with their columns. The decisions you have made, so no plan re-opens them. The questions still open, so no plan closes them for you.

Keep it under the 10,000-character limit by leaving the pages out. Pages change; this does not. For the clinic it is under 1,500 characters and it looks like this.

## What this is
Online booking for a physio clinic with three therapists. Patients book a slot online
and get a reminder the day before. The front desk sees every diary; a therapist sees their own.

## Words we use
board not screen · slot not appointment · therapist not provider
Buttons say what happens: "Confirm", "Hold this slot", "Move it". Never "Submit".

## Data
patients     id · name · phone · email
therapists   id · name · sees_all_diaries
bookings     id · patient_id · therapist_id · starts_at · status (held, confirmed, cancelled, moved) · paid_how

## Decisions already made
- A patient picks a slot before they make an account, never after.
- Reminder by email, 18:00 the evening before. One message: "Hi Rita, you are with Maya
  tomorrow at 09:00. Reply C to cancel or R to move it."
- Pay at the door, or online. Both.
- Cancel free up to 24 hours before.

## Still open
- Is the first visit 45 minutes or 30? Ask before building the diary.

Workspace knowledge is the same idea across every project: coding standards, the libraries you prefer, naming. When the two conflict, Lovable’s docs say project knowledge wins, which is the right way round: the clinic’s decisions beat the house style.

Give Plan mode one page from the PRD and read what comes back before you approve it. The plan it writes is prose, and it costs a credit, so it is worth reading like a spec: does it name the empty day, does it grey the taken slot, does it write a row with status “held”. If a state is missing from the plan it will be missing from the build. Fix it in the plan, where the fix is a sentence, and then approve.

Plan page 1, Book a slot. Use Project knowledge for the data and the decisions.

On it: Therapist (any of the three, or one by name) · Day · the open slots for that day,
each with its time and therapist · a button that says "Confirm".

States: open · taken (shown, greyed, no click) · empty day, which says
"Nothing open on Thursday. Friday has four." · the slot was taken while choosing.

Reads therapists and bookings. Writes one row to bookings with status "held".

Write the plan for this page only. Do not plan the diary or the reminder yet.

The last line matters. Plan mode will happily plan the whole product from one message, and the corrections then compound across pages you have not checked. The second post is the case for one page at a time; here is the page, drawn, so the plan has something to be checked against.

Lovable’s own guide says prompt by component, not page, and it is right about Lovable. The plan covers the page. The Build prompts that follow are the components on it, one at a time: the slot grid, then the Confirm button, then the empty state. Each prompt has the three parts their docs name: what to build, where it goes, and what must stay untouched.

The third part is the one people skip. Their docs say it plainly: without boundaries a small request can ripple into parts of the app that already work. Name what stays untouched every time, and a change to the slot grid stays a change to the slot grid.

What to build
The slot grid on Book a slot: one card per open slot for the chosen day, showing the time and
the therapist's name. Taken slots are shown greyed and cannot be clicked.

Where it goes
Under the Therapist and Day fields, above the Confirm button.

What must stay untouched
The Therapist and Day fields, the Confirm button, and the bookings table.

Lovable’s guide says design with real content. The PRD is where the real content comes from.The button label, the empty-day sentence, the body of the reminder: written in Project knowledge once, they are in every plan and every build without being asked for again. A placeholder in the knowledge is a placeholder on the page.

This is also the part of the spec a copywriter or a client can read without knowing what Plan mode is. The words are in one place and they are the words that ship.

Everything above is easier when the PRD is boards instead of paragraphs. A board cannot leave the gap a sentence can: the empty day is drawn or it is missing, the button has words or it does not, and the data board next to the page is the schema. Reading a Lovable plan against a board takes a glance; reading it against a paragraph takes a re-read.

On HuntingHydra, Nadia draws the boards from one sentence, with the words on them, the states you did not ask for, and the data beside them. Use them as the plan you check Lovable against, or let Devi build exactly those boards. Either way the spec exists somewhere it cannot scroll away. Setup is on /docs.