Close the brief with named non-goals
End a delegation brief with a named list of the work that is forbidden this session, each exclusion pointed at where it goes instead, so the work you were sequencing later does not arrive unasked.
Use when
- Use this when the work you are delegating sits next to obvious adjacent work that a capable executor would helpfully start building.
- Use this when you are running work in sequenced phases and the next phase is already scoped but not yet due.
- Use this when the executor has no memory of earlier sessions and cannot know what you have already decided to hold back.
The failure
The session delivers your scope plus three things you had deliberately sequenced later. They now exist unspecified, unreviewed, and load-bearing, and the work you actually planned for that phase has to be built on top of them or around them.
The outcome
The brief ends with a named list of forbidden work, each item carrying its destination, and the executor can state what it has been told not to build before it starts.
The Practice — 5 rules
Give the exclusions their own closing section
Put the exclusions in a section of their own at the end of the brief, titled non-goals and marked as hard stops. It is a list, not a paragraph of caveats, and it is the last thing read before the work begins.
Why An exclusion mentioned in passing reads as a preference; a titled closing section reads as a boundary the executor can check itself against.
Name the work that is genuinely next
Enumerate the forbidden work item by item, in the vocabulary the executor will use. The items that matter are not the absurd ones but the reasonable ones: the adjacent feature, the obvious refactor, the phase you have already scoped and are holding back. If you would recognise it as good work arriving unasked, write it down.
Why A capable executor builds the adjacent thing because building it is helpful, and only a named exclusion outranks its own helpfulness.
Point each exclusion at where it goes instead
Where an excluded item has a destination, name it in the same clause — a later phase, a step you will take yourself, a decision still open. "No adoption features; that is the next session." "No package publish; that is a step I take myself." "No bundling; that stays a future decision."
Why An exclusion with a destination reads as sequencing rather than rejection, which stops the executor re-opening the question mid-build.
Restate the standing exclusions every time
Keep a fixed set of exclusions that every brief inherits, and restate them in full rather than assuming them: no new dependencies, no deployment, no touching production data, no new decisions about the frozen specification. Four lines of repetition removes every later argument about what carried over.
Why An executor that remembers nothing of the last session cannot honour a standing rule that was never written into this one.
Permit the thinking, forbid the build
Where an excluded thing is genuinely worth thinking about, permit the thought and forbid the build in the same line: the executor may sketch it or write it up in the session's own notes, and may not implement it. Ask for a short paragraph on each thing it deliberately did not build.
Why A blanket refusal throws away the best observation about the work, made by whoever was closest to it; a bounded one keeps that observation out of the codebase.
Limits — do not use this when
- Do not use it on exploratory work where the point is to discover what should be built; a hard-stop list closes the space you opened on purpose.
- Do not use it as the whole brief — prohibitions without a stated outcome and a proof of done leave the executor unable to finish anything.
- Non-goals bound a session that already has a stated outcome and a proof of done. They do not supply one.
- The list constrains the work, not the executor's judgement about it — an executor who believes an exclusion is wrong should still say so, wherever you have given disagreement to go.
- An exclusion holds for the session it is written in. It is not a permanent decision about the product, and the next brief may lift it.
- A non-goal only binds what the executor can see. Work delegated across several parallel sessions needs the same list in each of them.
Verify — evidence that it helped
- The brief has a section titled non-goals, and every item in it is something you can imagine a competent executor starting on its own.
- Each excluded item that has a destination names it in the same line.
- Before it starts, the executor can list back what it has been told not to build.
- The final message reports the non-goals as held, and each deliberate deferral has its own short paragraph.
- Nothing in the delivery is work you had scheduled for a later session.