next-options

Next options

The user skims replies and answers a choice with a letter. Follow these rules on every reply to the user for the rest of the conversation, until they ask for normal replies. A delegated task reports to its coordinator in the shape its brief asks for, without options.

Pick the ending

Keep working through reversible steps inside the agreed scope, as /principle-never-block-on-the-human describes. A question asking you to act ("can you…?") is an instruction: do it. A question about which, when, whether, or why gets an answer, and a change it implies becomes option a rather than an edit, made through /pstack-mode unless the mode is on, a coordinator owns the work, or the edit is trivial or agent config. When the turn ends, pick its ending by who moves next.

You move next when something you started will wake you: a subagent, delegated task, workflow, background command, or watch. End with a plain next step: one sentence of what you will do and what it waits on, as in **Next**: I'll write the report when the exploration agent finishes. Add Nothing needed from you. unless the reply already says so. When nothing will wake you, keep working in this turn.

The user moves next when the work waits for their answer. End with lettered options, by Format:

• at a point only the user can pass: a merge, deploy, force-push, or production write; a push to a branch someone else owns, or one that would dismiss an approval; a message to a person; a scope, interface, or product decision; a credential, payment, or physical step; a check that still fails after the root-cause fix; or an approval the active workflow keeps;
• after answering a question or a read-only request, when a follow-up needs their choice; or
• when only CI, bots, other people's reviews, or threads you didn't start are left, and nothing you started will wake you.

When the user's answer is needed while your own work runs, say in one line what is still running, then end with the options.

Nobody moves next when the work is finished. End with Done, without options, and one line naming what is still open, or that nothing is. A finished stage whose next stage waits on the user's go ends with options instead, as Workflow handoffs lists.

Under a full-autonomy grant, such as "run until done" in /pstack-mode, decide each call the grant covers and report it rather than offering it. A scope, interface, or product call the grant leaves to the user gets a default you apply and report with its reason, saying in plain words what they could tell you instead, without a letter to type back. Every other point only the user can pass, from the list above, still waits for them and ends with lettered options.

Format

**Next**

- **`a` → yes: fix the currency column and null dates, then push** · _recommended_
- `b` → no: fix only the currency column

• One or two options, each at most 12 words. A report's a stands alone, and the user steers in their own words; b appears only on a yes-or-no call, such as /reply-shape's decision card, as the no and the smallest option, or as Waiting's /babysit-and-ship. The options are the turn's only question, so the reply doesn't also end on "Should I…?".
• Only real choices: each option waits for the user's pick. Work you will do anyway, even a single remaining step, goes in the plain next step.
• a is the recommendation: bold only its option text and add the italic tag. It serves the session's goal and names every push, post, PR, or issue it creates in a word or two, as in …, then push. The option names the action; its plan stays with you. It creates no issue, messages no person, and changes no PR's state unless the user asked for that this session.
• Each option is a step the user would naturally take next, in plain words that make sense on their own, calling each item it cites by name. Build options on PR, CI, thread, or issue state checked this turn, and drop what that state makes moot.
• Do it yourself: an option is never a step for the user while a CLI, an MCP server such as Executor, or computer control could do it. Hand over only credentials, payment, or physical actions, and say why.
• Waiting: when the next step waits on CI, bots, builds, or other threads, do the next independent work in scope first. When nothing else is left and the PR has checks, bots, or reviews still to report, a is the watch (watch_pull_request in T3 Code); with none, a watch has nothing to wake on. Beside a watch, or an a that marks a PR ready, b is /babysit-and-ship, which takes the PR through verification to merged.
• Manual checks: before you end a turn on a PR watch, including after each wake, run node ~/.agents/skills/next-options/scripts/pr-waiting-on.ts <PR>, or the same script beside this skill where it is installed elsewhere. On verdict: person, such as Chromatic baselines that must be accepted or a deployment that waits for approval, the user moves next even while other checks run: stop the watch (unwatch_pull_request in T3 Code), list each item with its link as something only the user can do, and end with options. A check like this never finishes on its own, so waiting on it stalls the PR.
• Leave out filler such as stop, done, list what's open, or something else, and any option the user passed over in both of the last two lists, including a past a, though not the babysit-and-ship b.

Answers

The user answers with a letter, a letter and a tweak such as a, but keep the name, or their own words. When the reply numbers a list, such as findings, they can answer 3 to discuss item 3, skip 3, or a combination such as a, skip 3; ? asks for the current step and open items. A summary or handoff calls each item by name. These answers never get an option line. Picking an option is the user invoking the skill it names; load a user-invoked one, such as /pstack-mode, from its installed SKILL.md.

Workflow handoffs

When a stage of this library's flows finishes, the usual a is the next stage the user hasn't settled yet:

Finished	Usual a
/grill-with-docs	/pstack-mode when the build fits one session, or /to-spec when it spans several
/to-spec	/to-tickets, after a prototype for any open question that running something could settle
/to-tickets	/implement-spec, or /coordinator for a multi-PR graph
/wayfinder	/to-spec for the destination it charted
A Pstack prototype	build the recommended variant through Pstack's Feature playbook, or /architect for its shape
Implementation with review findings open	fix them and re-review
A Clean review without a PR	open a draft PR through /pr
A draft PR /thermos hasn't reviewed at its head	/thermos over the whole PR, fixing its findings, then mark it ready
A draft PR	watch it, or address its review comments

Setup

To load these rules at the start of every Claude Code and Codex session, follow the setup reference when the user asks.