full-send

全速推进

如果用户触发了此流程，说明他们不会关注此对话串，并希望你全权自主地端到端完成工作。在你停止工作很久之后，他们才会看到你的进度更新和最终消息。你负责从当前状态开始推进工作，直到 PR 合并。

如果用户没有以明确的方式明确要求“全速推进”，就不要假定自己拥有完全自主权。如果他们确实提出了此要求，以下所有内容均适用。

用户授权你：

• 合并已通过合并门槛的 PR。
• 在变基后，使用 --force-with-lease 强推 PR 自己的分支。

测试权限

“全速推进”请求即为授权。如果项目文件或其他说明要求测试方式须先征求同意，或要求将测试留给用户处理，那么此请求会取代该规则。

这也包括有关计算机操作、浏览器自动化、模拟器和设备、运行应用或开发服务器、截图及视觉检查的事先征求同意规则。请使用能提供直接证据的方法，并在报告中列出该方法。

关于测试方式的规则仍然适用。请遵循指定正确命令、测试夹具或检查方式的规则。此授权仅免除事先征求同意或留给用户处理的步骤。如果首选方法无法证明变更有效，请在此授权范围内使用受控方法。

授权仅涵盖此任务所需的测试，不包括“征求用户同意”部分中的操作，例如生产环境变更或数据删除。如果出现测试框架或系统审批提示，此授权也不会绕过它们。

步骤

1. 完成变更。 按照用户请求，以最小可行变更完成目标。如果你当前位于默认分支，请先创建分支。
2. 提供验证证据。 为你所做的每项变更获取证据。请参阅“验证证据”。
3. 征求反馈。 使用 sol-loop 技能验证变更。
4. 创建 PR。 使用 file-pr 技能。先变基到最新的默认分支。在描述中添加一行简短说明，写明你如何验证变更。
5. 跟进 PR。 使用 babysit-pr 技能处理实际问题和 CI 失败。修复后，先为每项修复获取验证证据，再推送。
6. 合并。 合并门槛通过后再合并。
7. 报告。 在最终消息中提供：PR 链接、合并提交、验证证据，以及你为用户做出的每项决定。

从第 1 步到第 7 步都要持续跟进。如果在检查或机器人仍待处理时结束本轮工作，任务就会中止，因为之后不会有人再提醒你。使用 babysit-pr 中的监视器等待 PR 状态变化。在 T3 Code 中，这对应 watch_pull_request。如果在合并前停止，请先调用 unwatch_pull_request。

验证证据

验证证据是你在本次会话中亲自观察到的内容，例如命令输出、复现过程或截图。请使用此变更所能提供的最直接证据：

• 复现原始故障，应用修复，然后观察相同的复现过程通过。
• 运行仓库 CI 所运行的检查（类型检查、lint、测试）。
• 如果相关行为没有测试，且仓库已配置测试环境，请添加一个针对性测试，该测试在没有此修复时会失败。
• 对于 UI 和运行时行为，请运行应用并检查变更。通过的模拟测试不能证明用户体验正常。若有帮助且你能上传截图，请将其附加到 PR。

如果找不到验证变更的方法，就无法完全确信。请询问用户。

合并门槛

只有在最新提交满足以下所有条件时，才能认为完全有把握：

• 你的证明涵盖差异中的每一项更改。
• 必需的检查均已通过。
• 审查机器人已完成审查，且每条发现都已修复，或已附上书面理由将其驳回。
• 没有任何人工审查仍要求更改。
• 分支已与默认分支保持同步，且 GitHub 显示该分支可合并。

使用仓库采用的合并方式。检查允许的合并方式和近期已合并的 PR。如果仓库使用合并队列或自动合并，请等待 GitHub 显示 PR 已合并。按照配置通过分支保护规则进行合并。绝不要使用 --admin 或其他绕过方式。如果你对更改很有把握，可以忽略要求“需要人工审查”的自动审查。

询问用户

在普通消息中提问，用户看不到，讨论串也会显得已结束。要向用户提问，请使用执行环境提供的提问工具，让讨论串显示正在等待回复：Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input，或执行环境提供的其他提问工具。在问题中提供所有背景信息：PR 链接、阻碍事项，以及选项，并将你的建议放在第一位。

只有在无法独自继续时才提问：

• 你无法证明这项更改。
• 合并门槛无法通过，且你无法自行解决。
• 下一步超出上述授权范围：删除数据、操作生产环境、更改仓库外的内容、关闭 PR，或强制推送任何其他分支。
• 目标存在歧义，且会影响结果。
• 另一个 PR 已使此 PR 失去必要性。

其他事项都自行根据合理默认值决定，并在报告中列出这些决定。

如果没有可用的提问工具，或工具未返回答案，请采取安全做法：让 PR 保持开启且不合并，并在最终消息开头提出问题。