next-goal

下一个目标

根据仓库证据，发现有充分依据支持的下一个目标范围。使用当前请求或更早请求中选定的明确范围。要求选择下一个目标的请求，即授权你选择范围：选择证据最充分的边界。只有一个可行范围时，除非用户要求先选择或预览，否则就选它。只有在用户指示或授权判断仍无法解决重大不同结果时才提问。

重新验证选定范围，通过就绪门槛，并根据预期变更规模，建议通过 PR 交付或稍后汇总。生成一份简洁且全新的会话路由信封，并附上封闭式执行约定。范围选择不需要单独占用一个用户回合。仅当用户明确要求非推荐的交付提示词（单独要求或与推荐一并要求）时，才生成该提示词。

范围发现与选择必须只读。准备工作是单独授权的阶段，如下所述；完成后，根据更新后的仓库状态重新验证同一边界。返回目标提示词时，将前置条件结果放在 commentary 中，以便最终回复可直接复制到 /goal。在约定中加入 $progress 目标跟踪，以便运行目标的会话初始化持久目标状态。

选择操作

以下是明确的技能指令，不是 shell 命令：

调用方式	授权的操作
$next-goal	选择并返回提示词；默认不修改内容。
$next-goal prepare	选择目标、完成并审查详细计划、提交相关准备工作，然后返回提示词。
$next-goal spawn [model] [reasoning]	完成准备工作，然后根据已准备好的状态创建一个新的 Codex 任务，并在那里启动原生目标。

明确的仅提示词、预览、不提交或等待指令优先于这些默认行为。在引用、示例或技能设计讨论中提及，不构成执行请求。模型参数仅适用于 spawn；不能仅凭模型名称推断用户要求创建任务。保持明确的调用策略不变。

对于 prepare 和 spawn，修改前须阅读 Prepare a goal。准备工作授权制定计划并提交其范围内的内容，不授权实现功能，也不授权一揽子提交现有工作。复用用户已有的决定和授权判断；只有在涉及重大决策且无法自行解决时才提问。

对于 spawn，准备工作前还须阅读 Spawn a Codex goal，以检查能力、目标和参数。此模式明确要求在选定项目中，从当前已准备好的 Git 状态创建一个新任务；这绝不意味着普通子 Agent。模型别名为 astra（GPT-6 Astra，medium）和 luna（GPT-5.6 Luna，max）；spawn 工作流负责确定确切的工具参数和可选覆盖项。未指定模型时，默认使用 astra medium；遵从明确指定的模型和推理参数。

运行步骤 1–3 以确定结果。在 prepare 或 spawn 模式下，随后执行准备工作流，并在就绪门槛前重新验证步骤 1–3。可独立请求的前置编辑或提交，可以在初始发现之前完成，正如现有组合工作流中的做法。整个计划修订和后续答复过程中，保持所选操作不变；不得重复已完成的准备工作，也不得创建重复任务。

1. 确认当前状态

1. 阅读适用的 AGENTS.md 文件，并确定权威且当前生效的 PLAN、TODO、ROADMAP、进度或交接文档。遵循用户指定的文档；否则遵循仓库约定和链接。如果存在并行工作树或限定范围的路线图，请选择当前工作树的规划命名空间；只有在明确要求汇总目标时，才阅读其他范围的内容。如果没有计划，请根据指引、代码、测试和历史记录推断候选事项。
2. 检查 git 状态和近期历史，然后只阅读足够的实现与验证证据，以发现过时的计划声明、已完成的工作、实际前置条件和阻碍因素。
3. 确定候选成果、限制条件、缺失证据和影响重大的未决决策。将用户负责的实现问题留待就绪度检查环节处理，以便每个此类问题都包含委派或修复的选择；目标边界的选择属于接下来的范围选择步骤。

只有在根据仓库验证了当前项目状态、候选成果及其关键缺口，而非仅仅复述计划内容后，才算完成此步骤。

2. 确定范围

首先应用现有的范围选择或已委派的选择，或选定唯一可行的范围。如果边界仍未确定，或用户要求提供选项，请列出简洁且在目标边界上有实质差异的选项。将命名的切片和检查清单条目视为规划单元，而非自动成为选项或停止边界。选项可以在成果或连贯的停止点上有所不同，但不要把相邻工作的每种排列都逐一列出。证据充分时，优先提供 2 到 4 个选项；不要为了凑数而编造薄弱选项。

每个选项只需说明与决策相关的边界：

• 语义成果；
• 包含的结果，概述即可，无须展开为目标契约；
• 在哪个紧接着的成果或里程碑之前停止；以及
• 该选项是否已就绪，或是否存在特定规划缺口，需要在选定后委派或修复。

提供选项时，恰好将一个选项标记为 (Recommended)，并用一句简洁的话说明原因。优先选择可由持续推进目标的 Agent 自主完成的最大有用成果，同时权衡成果价值、连贯性、规划就绪度、阻碍风险以及与后续里程碑的区分度。范围推荐不同于后续的交付推荐。

需要用户选择时，如果结构化选择控件能准确呈现支持的选项，就使用该控件；否则使用编号列表。请用户按编号或名称选择，或提出调整后的边界。不要输出围栏格式的目标提示词。如果没有任何实质性候选事项能立即实施，或无法通过有限委派或规划修复达到就绪状态，请说明不适合使用 /goal 并停止，不要凭空制造选项。将存在规划缺口的实质性候选事项保留在选项中，以便选定后由就绪度检查环节处理；不要提供仍依赖外部授权或未解决外部阻碍的工作。

仅在等待尚未解决的范围选择，或遵照用户先提供选项的请求时，才在此处停止。否则应在同一轮继续。仅交付方式不同，不足以在存在多个实质性不同边界时确定范围。

3. 定稿选定的目标边界

在定稿前，根据当前仓库状态重新验证所选范围。如果仓库发生了会使边界失效的重大变化，则依据适用的委派权限重新确定范围；如果该权限无法解决变化后的选择，则向用户询问。否则，即使用户选择的边界与推荐不同，也应保留用户选定的边界。 无论是在制定选项时，还是在最终确定所选方案时，都要遵循这些边界规则。自然衔接的工作可以纳入某个选项；所选边界调整后，只能在语义闭合所必需的范围内细化。一个目标可以跨越多个子系统和多个连贯提交，只要最终指向同一个有意义的项目状态。

如果同时要求提供两种交付变体，两者所选边界必须相同。在 PR 变体中，应将 PR 视为大型目标中的交付检查点，而不是单独的 /goal 边界。

所选边界必须：

• 明显超出一次普通交互轮次适合完成的工作量；
• 达成具体且可演示的项目成果或用户结果，而不只是前置条件或内部接口；
• 包含足够多已明确的工作，或已明确委派的工作，使持久执行能够跨越多个检查点并发挥价值；
• 在一个有实质影响但未由就绪门槛解决或委派的决策、外部授权、阻碍因素或实质上无关的下一里程碑处停止，而不能仅停在下一个计划标题或可供评审的切片处。

不要超出适用的用户指示或委派的选择权限，扩大较小的所选范围。如果所选方案不够充实，不适合使用 /goal，请说明原因并返回范围选择，而不是悄悄替换方案。对于范围充实但规划尚未完成的所选方案，应继续进入门槛检查。

在就绪门槛检查之前，将所选范围缩减为以下闭合路由约定：

• 成果 — 用一句话说明项目或用户在语义层面将实现的结果。
• 目标状态 — 一个具体且持久的路径：普通工作使用 goals/<stable-slug>.md，隔离工作树规划范围使用 goals/<scope>/<stable-slug>.md。
• 纳入的成果和来源 — 每项获授权成果都要使用简短、稳定的语义标签，并配上提供其实现和验收细节的少量权威文档。标签定义成员范围；路径和队列位置不定义。
• 完成条件 — 一个简洁的判定条件，要求每项命名成果达到其引用的结果及任何适用的完成标准，并且只包含这些来源中尚未涵盖的跨领域验证、评审、时效性和交付条件。
• 排除的工作 — 仅包含紧接着的下一个范围外里程碑，以及用户直接说明的排除项。对于其后的任何工作、无关工作或仅在计划文档中提及的事项，完整边界由权限范围决定。
• 权限 — 仅允许完成纳入成果所需的最小限度工作。若就绪门槛因委派而通过，还应授权执行目标的 Agent 根据最佳判断，在闭合的成果范围内解决剩余决策。将边界外的事项记录下来，留待之后处理；对于超出所选约定和交付生命周期覆盖范围的扩展或外部操作，必须取得用户的明确指示。
• 恢复不变量 — 在每次恢复的轮次、自动继续、上下文压缩恢复或交接时，都必须以目标模式调用 $progress，并在选择或开始更多工作之前恢复指定的目标状态。
• 交付 — 所选生命周期及其技能路由必须纳入约定，以便恢复时保留这些信息。

如果证据尚不足以支持某个字段，应准确记录规划缺口；不要虚构闭合条件。所选范围、其临时约定以及所有证据不足的字段都已准备好接受就绪门槛检查时，边界最终确定即告完成。

目标成员范围应视为闭合。推进路线图、修改 Current、创建计划、创建分支或 PR，或发现评审意见，都不会增加目标工作。项目规划状态描述项目接下来应做什么；只有目标约定描述本次运行获准执行的工作。

4. 通过就绪门槛

在输出目标提示词之前，请确认现有证据支持一个明确的结果、语义明确的纳入结果和权威来源、完成判定条件，以及足够明确的方向，以便自主实施。可逆且由实施者决定的选择可以保持未定。影响重大的用户决策必须获得明确授权委托，或通过规划修复来解决。

当结果明确但仍有影响重大的决策未定时，先检查用户是否已授权委托这些决策，或选择了规划修复。按其指定范围执行该选择。否则，说明具体的规划缺口，并请用户选择：

1. 授权目标运行 Agent 在明确的结果范围内自行判断并解决剩余决策；或
2. 先通过 $interview 修复规划，再使用 $progress 更新规划，然后重新选择目标。

在适用的用户选择解决门槛之前，不得输出目标提示词。授权委托仅适用于有证据支持的结果范围内的决策；它绝不会增加结果、扩大范围或授予外部权限。请在生成的契约 Authority 字段中记录该授权委托，避免目标运行 Agent 仅因引用的计划未确定这些决策而再次询问。

如果用户选择修复规划，请将该答复视为对单独变更阶段的明确请求：使用 $interview 确定影响重大的决策，然后使用 $progress 更新权威规划文档。根据更新后的仓库状态，重新开始当前状态解析，并确保更新后的选择阶段保持只读。规划修复不会取消已选定的范围；请重新验证并保留该范围，除非新证据实质性地改变了其边界，此时应根据步骤 2 重新确定范围。如果没有任何结果可获得明确支持，请说明为何无法授权委托，并要求先修复规划，再进行目标选择。

只有在规划已充分完备，或用户已明确授权委托明确结果范围内的剩余决策时，门槛才算通过。通过后，填写完路由信封中的所有字段。

5. 路由结果

• 当没有充分理由使用 /goal 时，给出基于证据的理由，并省略提示词。不要阅读交付变体说明。
• 当范围仍未确定或用户要求先提供选项时，只返回步骤 2 中精简的选项集、建议和选择问题。不要阅读交付变体说明，也不要输出目标提示词。
• 选定范围后，如果证据表明有充分理由使用 /goal，且通过准备度门槛，则阅读并遵循 prompts/delivery-variants.md。
• 在 spawn 模式下，将一个选定的交付约定传递给 spawn 工作流，而不是返回下方仅含提示词的回复。用户要求两种交付变体，并不意味着授权创建两个任务；创建任务前，先确定要执行哪种生命周期。
• 默认情况下，只以一个未标注的 text 围栏代码块返回推荐的提示词。代码块内仅放入要在 /goal 后输入的正文，围栏前后均不附加说明文字。
• 即使用户明确要求的单一指定交付变体与基于证据的建议不同，也应遵照执行；通过其 Delivery 字段标明输出的变体。
• 当用户明确要求两种变体时，只返回两个 text 围栏提示词代码块，在每个提示词的 Delivery 字段中标明变体，在两个提示词正文中放入相同的已确定范围约定，仅改变交付机制和 Delivery 字段。

回复前，确认范围发现与选择过程保持只读，任何准备工作均处于其获授权的阶段内，且只有在用户要求 spawn 时才创建任务。选择会话绝不创建自己的原生目标或持久化目标文件。对于提示词输出，确认已通过准备度检查，并且只返回用户要求的围栏约定；对于 spawn，则根据 spawn 工作流报告实际启动状态。