A project's plan tells you what to build. How to build it is your call. This article explains what's in the plan, what isn't, and what to do when your build would differ from it.
What the plan holds
Document | What it holds | What it leaves out |
Summary | The project's outcomes: what a user can do once it ships. | How it works. |
Requirements | The product decisions a coding agent can't make on its own: what the product does, and what the user sees. Rules, and sometimes a mockup, table, or diagram. | How to build it. No code, no architecture, no file names. |
The requirements are written for your coding agent to read with your code open. They state only what would change the build if it were missing. They don't repeat what the product already does.
Plan the build
Start with
grove. Your agent runsgrovefirst in every worktree. If the project isn't assigned yet, Grove tells it to assign the project before it plans or researches.Read the plan. The files are in
.grove/project/. Or rungrove project view P-003to print the summary and requirements.Read your code. Find where the change lands.
Write your technical plan. Decide the approach, the files, and the order of the work. That's yours to decide.
Check it against the outcomes. Each outcome should be covered by your plan, or by something the product already does.
A prompt you can give your coding agent:
Read the Grove project's summary and requirements, then plan how to build it in this codebase. List each outcome and how the plan covers it. Flag anything in the requirements you can't build as written.
Open points in the plan
A requirement can include an Open: line, such as: "Open: does the service price ever vary by day or time? Blocks the confirmation step on price. Product lead decides."
An Open: line is a decision the product lead hasn't made yet. It says what it blocks and who decides.
Build everything the open point doesn't block.
For the part it blocks, don't guess. Ask in a thread. See Ask the product lead instead of guessing.
When your build would differ from the plan
Sometimes the code shows that a requirement won't work as written, or that there's a better way that changes what the user sees.
When that happens, your coding agent should:
Tell you what's different, and why.
Offer to raise a thread for the product lead.
Raise it only if you agree. If you decline, it doesn't bring up that same point again.
Don't change the plan documents to match your build, unless your product lead asked you to. See Update specs and Scratchpad files from your coding agent.
When the plan changes
If your product lead changes the plan while you build, grove tells your agent the project is behind. Run grove project sync P-003, and ask your agent to adjust its plan. See Pick up a project and stay in sync.