A project's Requirements document holds the decisions a builder's coding agent can't make by itself. It says what the product does and what the user sees. It never says how to build it. The builder and their coding agent decide that, with the code open.
Each project has its own Requirements. Write them after the project has its outcomes. See Write a project's outcomes.
Start
Open the project. In the sidebar, under Plan, click Requirements. A new document shows Empty.
Click Draft requirements.
You can also ask Grove in the project's chat, such as "Write the requirements for P-002." Or type in the document yourself.
1. Grove sets the agenda
Grove reads the project's outcomes, the initiative's other projects, and your code, if it's connected. It may ask you a few questions first.
Then Grove writes the agenda into the document: one heading for each decision to make, each marked Not yet discussed. Typical headings cover:
Something new the product doesn't have yet: what it is, and what states it has.
A screen or flow that changes: what the user sees, and what they can do.
Who may do what.
Edge cases: empty, failed, at the same time, too many.
What this project leaves to the initiative's other projects.
In the chat, Grove explains each heading. It also names headings it nearly left out, and why they're in. Reorder, add, or remove headings, in the document or in the chat. Grove waits for your reply before it starts.
2. Settle one heading at a time
Grove picks the heading whose answer affects the most other headings, and tells you which one it starts with. You can send it to a different one.
For each heading:
Grove asks you for each decision it needs, one at a time.
Grove writes the section, in place of Not yet discussed.
Read the section. Change it in the document, or tell Grove what's wrong.
When you accept it, or tell Grove to go on, it goes to the next heading.
Where a picture says it better, Grove adds one: a mockup of a screen, a table of who may do what, or a diagram of a flow.
Leave a decision open
You don't have to decide everything now. Grove writes an undecided point as an Open: line in its section. The line says what it blocks and who decides. For example: "Open: does the service price ever vary by day or time? Blocks the confirmation step on price. Product lead decides."
When you decide it, the Open: line becomes a rule. A point that doesn't belong to any section goes under an Open questions heading.
3. Grove checks the document
When every heading is settled, Grove checks the whole document:
It finds rules that repeat, or that conflict with each other.
It reads the document the way a coding agent will, and fixes gaps.
It removes lines that wouldn't change what gets built.
It checks that every outcome is covered, and that every rule serves an outcome.
Grove tells you in one line what the check changed. It asks you before it changes a decision.
When the requirements are ready
The requirements are ready to build when:
No heading says Not yet discussed.
You agree with the decisions.
Every Open: line left is one you've agreed builders can work around.
Then mark the project ready to build. See Mark a project ready to build.
What makes a good rule
One rule, one point. You can check it against the working product.
The condition first, then what happens. For example: "When the chosen time is no longer free, the move is refused and the visit stays as booked."
What the user sees, not how it's built.
No repeats. If another project already decides something, the document links to it.
Grove keeps only lines that change what gets built. It doesn't write the outcomes again, or describe what the product already does.
Related articles
Mark a project ready to build
Ask Grove for diagrams and mockups
Use threads to ask, flag, and decide