Budget the Session
Decides in one sentence what this session is for, and writes down what it will not touch.
When to reach for it
At the start of a working session — especially an open-ended one where the goal is fuzzy and the codebase has plenty of adjacent things worth fixing.
What changes
- The session opens with a single outcome sentence and a written not-list of 3–5 adjacent things, both agreed before any edit.
- Out-of-scope discoveries land in a parked list with file paths and one-line descriptions, instead of quietly entering the diff.
- A stated abandon signal exists up front, so a session that is not working ends deliberately rather than at exhaustion.
- The closing report says done, partial, or abandoned against the original sentence — not against a goal that drifted to match the result.
Pairs with
- Scope CutTurns a sprawling request into the smallest version that would actually prove the idea.
- Assumption CheckMakes the agent state what it is assuming — and verify it — before it writes a line.
- Constraint SurfaceGets the real limits — deadline, platform, budget, who inherits it — out of you before anything is designed around a guess.
Budget the Session
Before the first edit, agree what this session is for. Takes under a minute and decides whether the next two hours are one thing or six half-things.
1. Write the outcome as one sentence
Form: "At the end of this session, ___ works" or "___ is decided." One outcome. If it needs an "and", it is two sessions.
2. Write the not-list
Name 3–5 adjacent things that are explicitly out of scope, chosen from what is genuinely tempting here: the neighbouring refactor, the failing test that predates this, the dependency upgrade, the naming everyone dislikes, the missing types.
3. Set a budget
Pick one measure and a number: turns, files touched, or wall-clock time. State it. This is the thing that gets checked later, so it has to be countable.
4. Define done and define abandon
- Done — the observable event that ends the session successfully. A passing command, a screen behaving, a written decision.
- Abandon — the specific signal that means stop and revert rather than push on. "Three failed attempts at the same error", "the fix requires changing the schema", "we are past the budget with no working path."
Naming the abandon condition in advance is what makes it possible to act on it, because in the moment there is always one more idea.
5. Park, do not chase
When something out of scope appears, write it down — file path, one line on what is wrong, one line on why it matters — and keep going. The parked list is an output of the session.
6. Report against the budget
At the end: the outcome sentence, whether it was met, the count against the budget, the parked list, and anything from the not-list that got touched anyway and why.
Rules
- Do not expand the outcome mid-session because something adjacent turned out to be easy. Easy is how sessions end with six half-things.
- Do not treat the not-list as "later today". It means not in this session's diff.
- Do not start an enabling refactor silently. Say that the goal now requires it, and re-budget out loud before starting.
- Do not quietly continue past the budget. Stop, report where things stand, and let the next step be a decision rather than a drift.
- Do not rewrite the outcome sentence at the end to match what actually happened. Partial is a real and useful result; a moved goalpost is not.