Feature briefs
In short
A feature brief is the agent’s written proposal for a change large enough that building it straight away would be a guess: what it understood, what it plans to do, and what it needs you to decide.
When a request is small and unambiguous, the agent does it. When it is large, or when doing it would settle a question you have not answered, the agent writes a feature brief instead: a short document stating what it understood, what it proposes to build, and what it needs decided.
Why a document instead of an attempt
Scope is cheapest to change before anything is built. A brief costs one short read; the alternative is reviewing a large diff written from the wrong reading of your request, then paying again to undo it.
It is also the honest form of the agent’s uncertainty. “I can build this two ways and they imply different things later” is useful before the fact and worthless after.
What is in one
- What the agent believes you asked for, in its own words — the first thing to check, because a misunderstanding shows up here.
- The change it proposes, and what it will touch.
- The decisions it cannot make for you: trade-offs, anything that affects data you already have, anything visible to your users.
Deciding
A brief is accepted, changed, or rejected. Accepting it turns it into work; changing it is usually faster than rewriting the original request, because you are editing a shared understanding rather than starting one.
A brief left undecided blocks nothing else, but it does mean the agent is holding back on something it thinks is worth doing.
Where the line sits
Briefs exist for the same reason ownership zones do: some decisions are yours, and the agent is expected to stop and ask rather than choose quietly.
Next: Ownership zones explained · Tasks