next-options

后续选项

用户会快速浏览回复，并用字母回答选项。在用户要求恢复普通回复之前，之后的每次回复都遵循这些规则。委派的任务按任务说明要求的格式向协调者报告，不提供选项。

选择结尾

按照 /principle-never-block-on-the-human 中的说明，在约定范围内继续处理可逆步骤。要求你采取行动的问题（例如“你能……吗？”）就是指令：照做。询问选择、时间、是否或原因的问题应予以回答；它所暗示的变更应作为选项 a，而不是直接编辑，除非 /pstack-mode 已开启、工作由协调者负责，或编辑很简单或属于 Agent 配置。当本轮结束时，根据接下来由谁行动来选择结尾。

当接下来由你行动时，表示你启动的某项工作会唤醒你：子 Agent、委派任务、工作流、后台命令或监视任务。以一句简单的话说明接下来的步骤，以及它在等待什么，例如：**Next**: I'll write the report when the exploration agent finishes. 除非回复中已经说明，否则补充 Nothing needed from you.。如果没有任何事情会唤醒你，就在本轮继续处理。

当接下来由用户行动时，表示工作正在等待用户答复。按以下格式列出字母选项：

• 处于只有用户才能推进的关口：合并、部署、强制推送或生产环境写入；推送到他人拥有的分支，或会驳回审批的推送；向某人发送消息；范围、接口或产品决策；凭据、付款或实际操作；根因修复后仍未通过的检查；或当前工作流要求的审批；
• 回答问题或完成只读请求后，需要用户选择后续操作时；或
• 只剩 CI、机器人、他人的评审或你未启动的讨论，且没有任何由你启动的工作会唤醒你时。

如果用户的答复尚待确认，而你自己的工作仍在运行，先用一行说明仍在运行的工作，然后以选项结尾。

当接下来由无人行动时，表示工作已完成。以 Done 结尾，不提供选项，并用一行说明尚未解决的事项，或说明没有未解决事项。已完成的阶段如果下一阶段需等待用户同意，则按照“工作流交接”的规定以选项结尾。

在获得全面自主授权时，例如在 /pstack-mode 中获准“运行直至完成”，应自行决定授权涵盖的各项事项，并报告决定，不要提供选项。对于授权未涵盖的范围、接口或产品决策，应选择默认方案并说明理由，同时明确告知用户可以提出其他要求，不要让用户通过输入字母来选择。上述清单中其他只有用户才能推进的事项仍需等待用户，并以字母选项结尾。

格式

**Next**

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

• 一个或两个选项，每个最多 12 个词。报告中的 a 单独出现，由用户用自己的话引导；b 只在是或否的选择中出现，例如 /reply-shape 的决策卡，作为“否”选项和最简选项，或作为 Waiting 的 /babysit-and-ship。选项是本轮唯一的问题，因此回复结尾不会再出现“我应该……吗？”。
• 只提供真实选项：每个选项都需要等待用户选择。你无论如何都会做的工作，即使只剩一个步骤，也应放在纯文本的下一步中。
• a 是推荐选项：仅将其选项文本加粗，并添加斜体标签。它应服务于本次会话的目标，并用一两个词说清楚它会创建的每个推送、帖子、PR 或 issue，例如 ……，然后推送。选项说明要执行的操作；计划由你负责。除非用户本次会话要求，否则它不会创建 issue、向任何人发送消息，也不会更改任何 PR 的状态。
• 每个选项都是用户接下来会自然采取的一步，用简单明了、独立可懂的措辞表达，并按名称提及其中涉及的每个项目。选项应基于本轮已检查的 PR、CI、讨论串或 issue 状态，并删去因该状态而不再适用的内容。
• 自己动手：如果 CLI、MCP 服务（例如 Executor）或计算机控制可以完成某一步，该选项就不能把这一步交给用户。只有凭据、付款或实体操作才交由用户处理，并说明原因。
• 等待：如果下一步要等待 CI、机器人、构建或其他讨论串，先完成范围内其他独立工作。如果没有其他工作可做，且 PR 仍有检查、机器人或评审结果待报告，那么 a 应为监视（T3 Code 中的 watch_pull_request）；若没有这些事项，监视也就无事可做。在监视选项旁边，或将 PR 标记为可合并的 a 旁边，b 应为 /babysit-and-ship，它会让 PR 经过验证直至合并。
• 手动检查：在以监视 PR 结束本轮之前（包括每次唤醒之后），运行 node ~/.agents/skills/next-options/scripts/pr-waiting-on.ts <PR>，或运行此技能安装在其他位置时所在目录中的同一脚本。若结果为 verdict: person，例如必须接受的 Chromatic 基线，或等待批准的部署，即使其他检查仍在运行，下一步也由用户执行：停止监视（T3 Code 中的 unwatch_pull_request），将每个需要用户操作的项目及其链接逐一列出，并以选项结束。此类检查永远不会自行完成，因此等待它会拖住 PR。
• 省略诸如停止、完成、列出未处理事项或其他之类的填充内容；也省略用户在最近两份选项列表中都跳过的任何选项，包括以前的 a，但 /babysit-and-ship 的 b 除外。

答复

用户可以回复一个字母、一个字母加调整要求（例如 a, but keep the name），或用自己的话回复。若回复引用了编号列表（例如发现项），用户可以回复 3 来讨论第 3 项、回复 skip 3，或回复 a, skip 3 之类的组合；? 表示询问当前步骤和未处理事项。总结或交接时，按名称提及每个项目。这些答复永远不会带有选项行。选择某个选项即表示用户调用了该选项所指的技能；如果它是用户调用的技能（例如 /pstack-mode），就从其安装目录中的 SKILL.md 加载。

工作流交接

当此库的工作流中的某个阶段结束时，通常的 a 是用户尚未确定的下一个阶段：

已完成的阶段	通常的 a
/grill-with-docs	如果构建可在一个会话内完成，则为 /pstack-mode；如果需要多个会话，则为 /to-spec
/to-spec	/to-tickets；对于任何可通过实际运行来解决的未决问题，应先制作原型
/to-tickets	/implement-spec；对于多 PR 图，则为 /coordinator
/wayfinder	针对其规划的目的地使用 /to-spec
一个 Pstack 原型	通过 Pstack 的 Feature playbook 构建推荐变体，或使用 /architect 规划其形态
存在未解决审查意见的实现	修复这些问题并重新审查
没有 PR 的 Clean 审查	通过 /pr 创建草稿 PR
草稿 PR /thermos 尚未对其最新提交进行审查	使用 /thermos 审查整个 PR，修复其发现的问题，然后将其标记为可合并
草稿 PR	持续关注，或处理其审查评论

设置

当用户提出要求时，请按照设置参考在每次 Claude Code 和 Codex 会话开始时加载这些规则。