offering-the-next-move

Overview

The end of a run is the moment you know the most you will ever know about what should happen next, and the moment that knowledge is most likely to be thrown away. The ledger holds a line that was surrendered. The record holds a ruling that could have gone the other way. Somewhere in the transcript is the thing you found on the way past and did not chase. None of it is in front of your human partner, who gets a summary and an invitation to think of something.

So the run ends with two things rather than one. The summary is not the problem and does not shrink to make room; the option set is a second deliverable sitting under it, built from information only this run has, doing the one thing a summary cannot. A summary tells them what happened. No amount of good prose in it becomes a decision they can make by picking it.

The failure this exists against is not forgetting to ask. It is asking generically: a menu derived from the kind of work rather than from this instance of it, which looks like a considered handoff and carries none of the run's actual information. And it is the quieter version of the same thing, which is the more common one — a close that surfaces every finding correctly, in good prose, and then announces what happens next instead of asking. The reader gets all of the information and none of the decision.

When to use

Any task that produced something is ending — a change, an artifact, an answer someone will act on.
An orchestrated run has reached landing, or an investigation is about to file its report.
The draft ends in prose plus a general invitation to say what comes next.
The options in hand would fit any task of this shape, which means they came from the category rather than from the run.
Not for: the questions that make the work possible in the first place. scoping-before-building asks those one at a time, before anything is built; this runs after, and asks what comes next rather than what this is.
Not for: naming what is unfinished. knowing-when-to-stop owns the explicit handoff and what it owes the reader — this takes that named remainder and makes it selectable.
Not for: how to write the summary the options sit under, which is explaining-technical-work.

Always, and what always means

Every task that produced something ends with an offer. The size of the task is not an exemption: a two-line fix that turned up a second instance of the same bug has more to offer than a week of implementation that turned up nothing.

The boundary is what the turn produced, not how long it took. An exchange that changed nothing is not a run and closes normally. Everything else gets the offer.

A run that failed or stalled gets one too, and it is where the offer is worth the most. What blocked it, what would unblock it, and what is worth doing instead are three real options that nobody outside the run can assemble. knowing-when-to-stop covers stopping while blocked; this is what that stop hands over.

Announcing the next move is not offering it. This is how the rule fails most often, and it does not look like a failure: the closing message names every finding accurately and then ends with what you intend to do about them — tonight I'll rebuild the runner, that's my first job tomorrow, after your meeting send me the pivot year and I'll take it from there. Each of those is a decision taken on the reader's behalf in a sentence shaped like a courtesy. If your closing sentence has you as its subject and a verb in the future tense, the decision never left the room. Options are things they pick, not things you report having picked.

There are four ways the rule gets talked out of, and none of them holds:

The thought	Why it does not hold
"There is obviously nothing left to do."	Then the offer is short and one option says exactly that — and your partner gets to disagree with "obviously," which they cannot do with a sentence you decided not to write.
"They will tell me what they want next anyway."	They will, from a blank page. You are the one holding the list of what this run turned up.
"It is a small task; a menu would be ceremony."	The offer's size tracks what was found, not what was asked. Padding a thin harvest out to four options is the real ceremony — offer the two that are real.
"I already listed the next steps in the summary."	A paragraph is not a set of choices. The reader still has to re-read it, extract the forks, weigh them, and compose a reply. That is the work the offer exists to have already done.

One objection is not a rationalization and deserves a real answer. A harness that ships a question tool usually tells you to reserve it for decisions you cannot resolve yourself — do not ask what you could infer, do not ask what has an obvious default. That rule governs questions that block work, where interrupting to ask something you could have looked up spends your partner's attention to save your own. This is the opposite moment: the work is finished, nothing is waiting on the answer, and the question is not what you should do but which of what this run turned up they want. The first rule does not reach the second, and applying it there does not avoid an interruption — it withholds information.

The report comes first, in full

The offer is added to the closing message, never substituted for it. Write the wrap-up you would have written with this skill switched off — what was done, what the evidence was, what is not done and why, what turned up along the way — and put the offer underneath it.

Nothing gets cut from the report to make room. What goes wrong here is that an agent who would have written four paragraphs writes one, because the options "already cover it" — and that is worth naming because it does not feel like a loss while you are doing it. It feels like editing. But a few words of label and a line of description can say what might happen next and nothing whatever about what happened. Those are two jobs and the offer is only good at one of them.

The test is the reader who ignores the offer completely: they should be no worse off than if this skill had never run. If skipping the menu costs them a fact about the work, that fact was in the wrong place.

Only one order works: the report, then the offer. Options first make the reader choose before they know what they are choosing about, and a menu threaded through the prose is neither a report nor a set of options.

Harvest, do not invent

Options are not generated at close-out. They are collected, from things the run already wrote down, in this order:

Rank	Source	Where it already lives	Why it ranks here
1	A surrendered acceptance line	the ledger	Their own request, unmet. Nothing you noticed on your own outranks something they asked for and did not get.
2	A ruling that could have gone the other way	the run record's rulings	You chose; they never got the choice. The branch not taken is visible only from inside the run.
3	Scope pushed out on purpose	the phase log, `managing-scope-drift`'s record	Out of scope for this run and out of scope are different questions, and only one of them has been answered.
4	Something found and not pursued	the transcript, and nowhere else	Adjacent breakage, a second instance of the bug just fixed, a comment that turned out to be live. Highest decay of anything here: not offered now is lost.
5	The obvious continuation	the plan's remaining tasks	Weakest slot on the menu. They would have asked for this themselves, so it costs them nothing not to be asked.

The ranking rule falls out of the table: would they have thought of this without you? If yes, it is a weak option. A menu built entirely of row 5 is the generic menu — technically responsive, informationally empty. Row 4 is where the value concentrates, for the same reason it decays fastest: the option nobody else could have offered is the one with no home in any file, and it lives exactly as long as this context does.

Harvest before the teardown. Landing deliberately retires the plan and the run record. Assemble the offer while they still exist; tearing down first and then trying to recall what was in them is how rows 1 through 3 quietly become row 5.

Row 4 has no home in any file, which is why it decays fastest — and it is the row a clairvoyance sweep fills. Its discard pile is exactly the set of things that were real, were seen, and were correctly not acted on, each already carrying the one-line reason that makes it offerable. On a run that swept, harvest row 4 from there rather than from recall.

What a real option looks like

An option is an action with a size, not a topic. "Add tests" is a topic — the reader cannot tell what they would be agreeing to. "Cover the retry path — one test, the case the review flagged and nobody closed" is an action they can price.

Two fields doing two different jobs:

Label — the action, in a few words, in verb form. It is read first and is sometimes all that is read.
Description — what it costs, and what changes if they decline. Never a longer restatement of the label; that is the most common way a menu becomes decorative.

Weak	Real
Refactor the parser — the parser would benefit from some restructuring for maintainability	Split the parser's two jobs — about an hour, and it leaves the file the next schema change has to touch in one piece instead of two
Fix remaining issues — address what is left	Handle empty input — the one acceptance line surrendered at proof; ten minutes, and it is the input their importer actually sends

The four never to offer

Work inside the scope already agreed. "Should I also fix the test I broke?" is not a fork, it is an unfinished task in a question's clothing, and offering it launders your own incompleteness into their decision. Finish it, then offer.
A decision you are better placed to make. You have the code in front of you and they do not. Deciding, then saying what you decided and how firmly, beats handing back a judgment that was yours — calibrating-confidence covers marking it honestly.
Anything you would not actually do if it were chosen. Every option is a commitment. A decoy spends a slot and buys a second round of asking.
The same option twice. Two phrasings of "keep going" beside one "stop" is a two-option menu padded to look like three. Padding is the tell that the harvest was thin, and a thin harvest is a short menu, which is a fine thing to be.

Always leave a way to stop

One option always ends the work, and it is a position rather than a leftover. "Ship as is — the surrendered line only affects an input path nothing reaches yet" tells them something they did not have: your read on whether stopping here is defensible. "Nothing further" tells them nothing.

A menu whose every option is more work is a menu manufacturing the work it offers, and it reads as pressure however carefully the options were harvested. The stopping option is what makes the rest of them an offer rather than a queue.

Lead with the option you would take, marked as the recommendation. A menu with no recommendation is unfinished thinking handed over as though it were a choice: you read the code, sat through the failures, and saw what the run turned up, so declining to say what that adds up to withholds the most useful thing you have.

A recommendation is a claim and takes a claim's treatment. One you would abandon at the first sentence of pushback says so in its own description. Offering it at the same weight as one you would defend does not remove the hedge — it moves it into the silence around the recommendation, where the reader cannot see it.

One question, not four

Close-out is one question by default. Two is an interrogation at the exact moment your partner is deciding whether this is finished.

A second question is legitimate only when both of these hold:

The answers are independent. If the second only makes sense given one particular answer to the first, it is a follow-up rather than a second question, and asking it now forces them to answer a hypothetical. Wait, then ask.
Both answers change what you do. If either answer leads to the same next action, you are collecting a preference, not a decision.

The most common legitimate second axis is what next alongside how this lands — genuinely independent, and both change the next action.

Mechanics

Find out what your harness actually gives you before writing a single option into prose. Where there is a structured question tool — AskUserQuestion, an elicitation call, a multiple-choice prompt, whatever yours calls it — the offer goes through it. Not into the message body beside it, and not into a numbered list because that was easier to write.

That is not a formatting preference. An option in a tool is a decision the reader makes by picking it; the same words in a paragraph are a decision they make by retyping them. That gap is the handover itself: a reader who has to reconstruct the option before choosing it has been handed a summary again, whatever the words say.

Once you are in the tool, four constraints hold across implementations, and each one costs you something:

Constraint	Consequence
A handful of options, not a list	The ranking above is triage rather than tidiness — most of what you harvest will not fit
Labels are short, and the header shorter still	Put the action in the label and everything that costs or persuades in the description
Free text stays reachable regardless	Never spend a slot on "something else"; it is already there and the slot is not
One selection unless the tool is told otherwise	Options that are not mutually exclusive need the multi-select flag, or they need to be one option

The prose fallback exists for genuine absence and for nothing else. "A numbered list is basically the same thing" is the rationalization that quietly turns the offer back into the summary it was supposed to sit under. Where the tool really is missing — or where nobody is listening at all: a headless run, a scheduled job, a subagent reporting to a controller rather than to a person — none of the content rules change. Same harvest, same ranking, same recommendation, delivered as a numbered list with "reply with a number," or to whoever reads the report later instead of to a prompt nobody will see. The widget is the delivery; the harvest, the ranking, and the recommendation are the skill.

Where the answer goes

A chosen option is a new request, not a resumption. Run it back through the track selector in orchestrating-work-end-to-end — a finished run does not confer its track on whatever follows, and a chosen option that reopens a surrendered acceptance line routes backward to the phase that owns it rather than forward from wherever you stopped.

The offer goes into the run record before it is retired, because it is part of what the run concluded. The choice usually arrives after that — in a later turn, or never — so it belongs to whatever comes next rather than to the record being closed. Either way the unchosen options are the ones worth keeping: they are the record of what was deliberately not done, for the same reason a skipped phase gets a line saying why. Where landing deletes the record, they move into whatever outlives it — the handoff note, the pull request description, the message to whoever picks this up next.

Common mistakes

Symptom	Real cause
The close names every finding, then says what you will do about them	The next move was announced rather than offered; the information transferred and the decision did not
The report shrank to a paragraph once the options were written	The offer was mistaken for a summary; a reader who skips it now loses facts about the work
A question tool was available and the options went into the message body	The prose fallback is for absence, not for convenience
The menu would fit any task of this shape	Options generated from the category of work; the harvest never ran
Four options, two of which mean the same thing	A thin harvest padded to fill the widget instead of offered short
The reader picks the free-text option nearly every time	The real fork was never on the menu — rows 1 through 4 were skipped in favor of row 5
An option turns out to be something you were already obliged to do	Scope already agreed, handed back as though it were a choice
Every option on the menu is more work	No stopping position, so the menu manufactures the work it offers
Descriptions restate their labels at greater length	The description's real job — cost, and what declining changes — went unwritten
The offer was assembled after the record came down	Harvested from memory; rows 1 through 3 had already been deleted
The chosen option runs as a continuation of the finished run	A new request inherited a track instead of being routed

Red flags

"I'll summarize and let them tell me what they want next."
"There's obviously nothing left to offer."
"This was too small to bother asking about."
"Tonight I'll…", "that's my first job tomorrow", "I'll take it from there" — a closing sentence in the first person and the future tense is a decision that was never offered.
"The options cover it, so the summary can be short."
"A numbered list in the message is basically the same as the tool."
Filling the fourth slot because there is a fourth slot.
A recommendation withheld because both options seem fine — they seem fine to the one person who watched the run.
Offering something you would argue against if they picked it.
"I listed the next steps in the summary" — a paragraph they have to re-read is not a choice.