Long specs don't get read. Coding agents do read them, but every line costs attention, and the important lines get lost. So Grove keeps requirements short.
The rule
A project's Requirements hold the product decisions a coding agent can't make by itself. Nothing else.
To test a line, ask: without this line, could a good builder, with the codebase open, get it wrong? That means any of these:
They could build it differently.
They could break something that must keep working.
They and the product lead could disagree about whether it works.
If yes, the line is a real decision. Keep it. If no, any good build would do this anyway. Remove the line.
What stays
Rules the product must follow, such as "A customer can't move a visit less than 24 hours before it starts."
What people see, such as the words on a screen, or a mockup.
Choices between reasonable options, such as "Show the old time crossed out."
Decisions that are still open, written as Open, with what they block and who decides.
What goes
How to build it: tables, services, or code. See Product owns the why and what. Engineering owns the how.
Anything the codebase already does the same way everywhere.
Anything the project's outcomes already say. Each fact lives in one place.
Write each rule so it can be checked
Each requirement says one thing, and someone can check it against the running product.
How Grove does this
When Grove drafts requirements with you, it finds the decisions it needs, and settles them with you one section at a time. It removes lines that don't pass the test, and it never repeats what the outcomes say.