agentleFS
christofferbergjchristofferbergj/agent-skills/skills/communication/next-options/SKILL.md

next-options

Skill1 starsChanged 24 days agoMITView on GitHub

End replies with the next step, as one plain line when the agent carries on, or one or two lettered options when the user decides.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    after answering a question or a read-only request, when a follow-up needs their choice.

    line 20
  2. Distinctive:

    when only CI, bots, other people's reviews, or threads you didn't start are left, and nothing you started will wake you.

    line 21
  3. Distinctive:

    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.

    line 23
  4. Very specific:

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

    line 53

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.
  • 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:

FinishedUsual 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 prototypebuild the recommended variant through Pstack's Feature playbook, or /architect for its shape
Implementation with review findings openfix them and re-review
A Clean review without a PRopen a draft PR through /pr
A draft PR with code /thermos hasn't seen/thermos, fix in-scope findings, re-review them with /review-loop, then mark it ready
A draft PRwatch it, or address its review comments

While the /thermos row applies, b is its pass over the whole PR up to mark-ready, then /babysit-and-ship. The pass's fixes, /review-loop's included, and a rebase that keeps patch-ids count as seen. A PR that fits /review-loop's small-diff tier skips the row.

Setup

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.