用途
auto 用于端到端的自主任务执行，把三个阶段串成一条无需人工审批关口的链路：figure-out（弄清问题）→ define（定义任务）→ do（执行）。它适合当你希望“定义并执行、不要中途干预”的场景。
主要能力
- 链路串联：在单一任务上依次运行 manifest-dev:figure-out --autonomous（当对话记录缺少共识理解时）、manifest-dev:define --autonomous、以及 manifest-dev:do。
- 自动驾驶式理解：figure-out 的 --autonomous 标志让模型用推荐答案自答，而不是等待用户。
- 可见性与推进：展示 define 的 Summary for Approval 仅用于可见性，随后将其视为已批准并继续执行 /do。
- 任务来源：任务文本取自 $ARGUMENTS；若为空，则从对话上下文推断（把讨论中的任务概括为具体描述）。全新会话、无上下文且无参数时会中止，并提示：No task description provided and no conversation context to infer from。
- 调用方式：/auto <task description> | /auto --babysit <pr-url>。
验证策略
只把顶层使用的 --verification 和 --verifier-model 解析为 /auto 的标志；被引用或作为话题提到的内容仍算任务文本。省略 --verification 表示 per-gate。解析出默认值后，从 ../do/references/ 下加载匹配的兄弟 /do 参考，并在 /define 之前应用其策略校验；模式相关的模型支持和证据来源由该参考（而非 /auto）负责。在交给 /define 之前把解析出的标志从任务中移除，并且只把它们转发给 /do。绝不把这两个选项写入 Manifest。在整链完成契约中携带选定的模式、模型来源以及参考要求的证据/来源措辞。
Babysit 模式
--babysit <pr-url> 会跳过全新综合。它以 --babysit <pr-url> --autonomous 调用 manifest-dev:define，然后用解析出的验证选项调用 /do。PR 生命周期平台根据 PR URL 主机自动检测（github.com → github composition）；非 github 主机则中止。若 /define 产出多仓库 manifest，则单次 /do 调用会遍历所有仓库。
失败处理
- /define 未返回 manifest 路径 → 停止并报告。
- /do 升级（BLOCKED 判据或其他阻碍）→ 原样向用户呈现该升级及其请求的动作。
无人值守启动
在独立运行开始时、串联之前，建立持久的整链目标设定兜底机制。若当前 harness 暴露了目标设定或续跑能力，则直接设定目标；否则打印下方可复制粘贴的完成契约。其完成条件覆盖整条链路，因此续跑不会在第一个阶段后就停止。/auto 作为链路入口点拥有该兜底机制。终端成功条件是结果门控的：manifest 已写入、/do 报告 /done、并且每个 Acceptance Criterion 与 Global Invariant 在选中验证模式下的 manifest gate ledger 中都有新鲜的 PASS 证据。当 figure-out --autonomous 运行时，父契约还把自主 Read 门槛作为 /define 之前的阶段检查点，而不是对一个 /do 证据已通过的链路的事后终端成功判据。figure-out --autonomous 会抑制其独立的 Read 级兜底，因为该父契约拥有此检查点；/define 只产出 manifest 交接；/do 在既有的整链契约下运行，而不是设定或打印更窄的仅 manifest 目标。
运行自主链路执行 <task>，直到 /define 已写入 manifest 且 /do 已报告 /done，并且每个 Acceptance Criterion 与 Global Invariant 在 <选定验证模式与来源> 下的 manifest gate ledger 中都携带新鲜的 PASS 证据。如果先运行 figure-out，则在 /define 之前完成一次全解剖的 Read 检查点：每个承重分支都被压过；Evidence Ledger 明确；假设与已验证和推断的断言分离；独立再推导已运行或明确不可用；对立集合不再变动；置信度、证据与推翻条件已陈述。对于诊断形态的工作，如果 Read 检查点只定位到症状集中的位置，则不算完成：它必须点出产生症状的具体机制——即产生该症状的变量、差异或序列，包括在问题为比较性时说明本案例为何不同——或者通过指出仍然存活的解释、并展示哪些能够区分它们的可行探测已运行、显示了什么、或为何受阻，来赢得一个欠定的 Read。把缺失或薄弱的 Read 检查点视为 /define 之前需要修复的阶段缺陷，而不是在 /do 已有新鲜的全门 PASS 证据之后的事后终端失败。在 /do 期间，为每个 AC/GI 维护一份台账，记录 gate id、gate 文本来源、选定验证模式、评估器来源、显式或继承的 verifier 模型、最新裁决、证据，以及相对于其对象最近一次相关变更的新鲜度；未验证、FAIL、过期、BLOCKED/可操作或待升级的门都是非终端的；某个门通过后其对象发生实质变更会让它过期，直到重新评估，而重读、重看以及外观性或无操作编辑则不会。自己把每个阶段推到真实门槛；不要接受无证据的自证、“看起来完成了”或摘要声明来代替选定模式所需的证据。只升级真正需要你的阻碍。在 Read 检查点（若存在）、manifest 路径、验证/修复循环和阻碍之后记录紧凑的进度检查点。若停滞不前，则在 N 轮后停止。
使用方式
- 基本调用：/auto <task description>，任务文本取自 $ARGUMENTS；为空时从对话上下文推断。
- Babysit 调用：/auto --babysit <pr-url>，跳过全新综合，直接对 PR 执行 define 与 do。
- 验证相关标志：--verification 与 --verifier-model 仅在顶层使用时被解析为 /auto 标志，且只转发给 /do，不写入 Manifest。
适用场景
- 希望一次性定义并执行任务、不要中途审批的自主执行场景。
- 结合 PR 的 babysit 场景（仅 github.com 主机）。
- 需要结果门控、要求每个判据都有新鲜 PASS 证据的严格链路。
限制
- 全新会话、无上下文且无参数时会中止。
- 非 github 主机的 PR URL 会中止。
- 验证模式相关的模型支持与证据来源由 /do 参考负责，不由 /auto 决定。
- 具体支持的模型、价格、平台可用性等细节资料未提供。