HuntingHydra
Blog / A PRD for AI coding agents

A PRD for AI coding agents
is a list of pages, with the gaps closed.

Claude Code, Cursor and Codex build what you describe. The gaps in the description are what they build wrong. Here is the shape of a spec that leaves none, with the template.

Written by the HuntingHydra team.
· Seven minutes

The agent fills every gap
with a guess.

An AI coding agent never asks the question your spec left open. It answers it. Write “patients can book an appointment with an available therapist” and the agent decides whether that means any therapist or one the patient chooses, decides it in the schema, and you find out at review.

That line reads as finished. So do most lines in most PRDs. Five of them are taken apart on the visual PRD page, and each one hides a decision: which day the open slots are for, whether the patient logs in before or after picking a slot, how long before the appointment the reminder goes, whether payment is online only. None of those are details. Each one is a table column, a page state, or a whole page.

A human developer reads the same line and walks over to ask. The agent has nobody to walk over to, so every gap becomes a decision made without you, and the cost of a wrong one is a rebuild. The job of a PRD for an agent is to leave no gap. That changes its shape.

Write it as pages,
in the order a user meets them.

A feature list is a translation the agent has to do itself. “Booking, reminders, a diary” tells it what exists. It still has to invent which page each one lives on, what is on that page, and what happens when it goes wrong. Agents build pages and tables, so give them pages and tables.

One section per page, in the order a user meets them. On each page, four things:

  • Purpose. One line. What this page is for, and the one decision it carries.
  • On it. The fields and the buttons. Every control, and what it does.
  • States. Open, taken, empty, error. The page when the day has nothing free.
  • Data. What the page reads and what it writes, by table.

Written that way, the line about available therapists cannot survive. You reach “On it” and have to write Therapist: any of the three, or one by name, and the decision is made where the agent will read it. Below is what that looks like drawn, which is the same thing with less room to be vague.

Canvasphysio-booking
Book a slot

Book a slot

Confirm
TherapistAny of the three
DayThursday
Open on Thursday
09:00open
10:30open
14:00taken
ReminderThe day before
PayAt the door, or online

A patient picks a slot before they make an account, never after.

Put the real words in.
Placeholders ship.

Whatever the button says in the spec is what it says in production. Leave it as “CTA” and the agent writes “Submit”. Leave the empty state to the agent and a patient on a quiet Thursday sees “No results found” on a booking page.

Write the button label, the empty state, the error, and the body of every message the product sends. The reminder is the clearest case: Hi Rita, you are with Maya tomorrow at 09:00. Reply C to cancel or R to move it is a spec line, because it decides the channel, the timing, the tone, and two features (cancel, move) in one sentence. “A reminder is sent” decides none of them.

This is also where a PRD stops being a document only the PM reads. A copywriter can write on it. A client can read it and know what their customers will see, before anything is built.

Draw the data
next to the page it feeds.

The agent writes the migration from whatever you gave it, and if you gave it nothing it invents the model. Ids, relations, which table owns the appointment time: every one of those is a guess unless the tables are in the spec.

List the tables and their columns, and put each page’s reads and writes next to the page. The decisions you made on the pages show up here as columns. “The front desk sees all three diaries” is a boolean on the therapists table, sees_all_diaries, and the agent should find it named, next to the page that needs it.

Canvasphysio-booking
The data behind the diary

The data behind the diary

Drawn, not built
bookings
therapist_idone diary each, your answer
starts_atthe slot grid on Book a slot
therapists
sees_all_diariesthe front desk view
patients
phonethe SMS line the clinic asked for

Every column is on the canvas before Devi writes a migration.

Name the unhappy states,
or they are not built.

An agent builds the path you described and nothing beside it. The declined card, the double booking, the ticket nobody is assigned to: if the spec does not name them, the product has no page for them, and the first real user finds the hole.

Ask, for every page: what does it look like when there is nothing here, and what does it look like when the thing the user tried failed. Each answer is a state on that page or a page of its own. On a booking tool that is the empty day, the slot taken while you were choosing, and the cancellation that came too late. Three lines in the spec; three pages that would otherwise be a stack trace.

Two boards you did not ask for: the refund the bank declines, and who is allowed to issue one.

what Nadia adds to a support tool drawn from one sentence, on /product-managers

The template,
for the clinic.

Copy it, keep the headings, replace the clinic. Four pages, three tables, three decisions written down, one question left open on purpose. It is short because the clinic is small; a product with twenty pages gets twenty sections, and that is the right length.

PRD.mdthe clinic, as the agent should get it
# Online booking for a physio clinic
One sentence. What it is and who it is for.
Three therapists. Patients book a slot online and get a reminder the day before.

## Pages, in the order a patient meets them

### 1. Book a slot
Purpose   The page the product exists for. A patient picks a slot before they make an account, never after.
On it     Therapist (any of the three, or one by name) · Day · The open slots for that day · Confirm
Words     Button: "Confirm". Empty day: "Nothing open on Thursday. Friday has four."
States    open · taken (shown, greyed, no click) · empty day · slot taken while choosing
Data      reads therapists, bookings · writes bookings

### 2. Your booking
Purpose   What just happened, and the one next step.
Words     "Thursday 09:00 with Maya. We will remind you the evening before."
States    confirmed · cancelled (up to 24 hours before, free) · moved
Data      reads bookings · writes bookings.status

### 3. Reminder, the day before
Goes out  18:00 the evening before, by email
Says      "Hi Rita, you are with Maya tomorrow at 09:00. Reply C to cancel or R to move it."
Data      reads bookings, patients

### 4. Therapist diary
Purpose   Each therapist sees their own day. The front desk sees all three.
States    own diary · all diaries (front desk) · blocked time
Data      reads bookings, therapists.sees_all_diaries

## Data
patients     id · name · phone · email
therapists   id · name · sees_all_diaries
bookings     id · patient_id · therapist_id · starts_at · status · paid_how

## Decisions already made
Write these down or the agent makes them for you.
- Slot first, account after.
- Reminder by email, the day before. One message.
- Pay at the door, or online. Both.

## Still open
- Is the first visit 45 minutes or 30?

The “Decisions already made” section is the one people skip and the one the agent needs most. The “Still open” section is the honest one: a question you have not answered, written down, is a question the agent will ask you instead of answering itself.

Handing it over,
typed or drawn.

Put the file where the agent starts. In a repo, that is PRD.md at the root, named in the agent’s instructions file so it is read before the first change. In Cursor, paste it into Plan Mode and the agent turns it into a Markdown plan of file paths; check that plan against the pages before you let it build, because that is the last cheap moment to catch a gap.

Or skip the typing. The reason a drawn spec builds better is that a board cannot leave a gap where a sentence can: a field is on the page or it is not, a button has words or it does not, a state is drawn or it is missing. On HuntingHydra, Nadia draws the boards from one sentence, with the data beside them and the unhappy states you did not ask for, you move them until they are right, and Devi builds exactly those. Your own Claude Code or Cursor can drive it over MCP; the setup is on /docs.

Questions.

What should a PRD for an AI coding agent contain?

One section per page a user meets, in order. On each: what is on it, the real words, its states, and the data it reads and writes. Then the tables, the decisions made, and the questions still open.

Is a PRD different for Claude Code, Cursor or Codex?

The shape is the same. Cursor’s Plan Mode turns it into a Markdown plan of file paths; Claude Code reads it from the repo. What changes the result is whether the gaps are closed before the agent starts.

How long should it be?

As long as the product has pages. A one-page tool is a one-page spec. A feature list is shorter and builds worse.

Do I have to write it, or can it be drawn?

Either. Drawn is better, because a board cannot leave a gap where a sentence can. On HuntingHydra, Nadia draws it from a sentence and the build follows the boards.

Type one sentence.
Get the pages back, drawn.

The spec above, as boards you can move, in the same hour.

Three days free, then $20 a month.