v2.8.0 ·
Roadmap items carry their own answers
When I write a roadmap item, I know what I mean. I know which edge of the scope I care about, what the flag should be called, and what the default ought to be. Hours later, when autopilot picks the item up and asks me those same things, the context I had is gone.
The last release taught the agent to check the roadmap item before it asks anything. The audit behind it found that 26 of 92 requirements and design questions were already answered by the item, the prompt or a setting. So the item is where answers work best. The problem was that the item rarely held the answers, because capturing one only asked about the problem and who wants it.
What changed
Capturing an item now asks a few more things, once. Before it writes the file, the agent names at most three choices the build would otherwise stop on: a scope edge, a name or flag a user will see, a default. Each comes with a recommendation, all in one message, and any of them can be answered "skip".
The answers go at the end of the item, one line each, under ## Decisions. A skipped one is not
written. The requirements and design steps read that section before they ask, and cite it when it
answers a question, so a decision made at capture is not asked a second time.
Why so little
Three questions and one message is a deliberate ceiling. A capture that turns into an interview is one people stop doing, and capture friction is what kills an inbox. There are no follow-up rounds, no new field, and nothing checks the section. It is prose an agent reads, not a gate.
What it does not do
An item written by an agent in the middle of other work, or by an unattended run, gets no decisions, because nobody is there to answer. The portable skill a contributor uses without a checkout does not ask them yet either. And an answer written at capture can go stale before the build starts. When it disagrees with something newer, the agent still asks.