open-pr

打开一个 PR

准备一个范围精简、可合并的拉取请求（PR），将其设为可供审查的状态并提交，然后持续跟进，直至具备合并条件。返回其 URL 和最终状态。

工作树

阅读仓库说明，确定预期的基准分支、分支策略、PR 工具，以及提交和 PR 约定。如果仓库规定了提交约定或 PR 模板，请遵循仓库的规定，而不是以下约定。如果当前工作树中的更改就是此次 PR 的内容，则使用当前工作树，并在需要时在那里创建预期分支。否则，优先从基准分支创建独立工作树。未经批准，绝不要修补、重置、丢弃或覆盖用户的工作；如果工作树中的 PR 更改与无关工作混在一起，或状态混乱，请停止并询问。

检查状态、已暂存和未暂存的差异、每个未跟踪文件、分支祖先关系、提交范围和远程状态。确认每项更改都属于所请求的 PR。如果范围不明确、存在合并冲突、敏感数据、缺少权限或历史重写不安全，请停止。

提交

规划一组规模适当、顺序合理的提交，清楚呈现更改过程。每个提交都应可独立审查和合并。如果某项修复属于刚创建且尚未共享的提交，请修改该提交；如果修复可以独立成项，则创建新提交。重设共享工作基准或强制推送前，请先询问。

每次提交前，对准确的预期差异运行 deslop。审查前，对完整 PR 差异运行 no-comments。根据已接受的评论发现重新规划，并对产生的更改再次运行 deslop。

提交主题使用 Conventional Commits 格式。将更改范围写为作用域。主题应简短、使用祈使语气；适用时，注明真实的符号名称，且末尾不要加句号。提交正文应说明主题未包含的事实，不能重复主题内容。对每条主题和正文使用 unslop，同时保持 Conventional Commits 语法不变。

每次提交和推送都使用 ship，并说明该次提交所包含的更改。

拉取请求

PR 标题也使用 Conventional Commit 格式。保留冠词，每个动作使用一个普通单词，并且在可以使用直接动词时避免使用 -ing 形式。对标题应用 unslop，但不要改变这种语法。

开头先写一段不带标题的文字，说明问题；如果存在具体的失败案例，也要写明，并说明此次更改如何解决问题。点出关键符号。如果有相关情况，补充一句说明哪些内容不在本次范围内，或重命名的前后名称。不要逐项介绍差异。

然后按以下顺序添加这些章节：

• ## Tradeoffs。说明实际做出的选择、否决的替代方案、已知限制以及可能出问题的地方。如果审阅者可能会有疑问，也要说明哪些内容保持不变。如果没有此修复时基分支会失败，请说明仍需承担的代价。无内容可写时省略此章节。
• ## Verification。说明如何运行每项检查及其严格程度。写明实际路径，例如 CLI 命令、UI 操作流程或针对性测试。说明每项检查的结果，而不只是命令名称。

这些章节之后，如有助于证明某项声明，请附上截图或视频。不要添加 ## Summary 或 ## Test plan 之类的模板内容。对完成后的描述应用 unslop。

优先拆分为五个范围较窄的 PR，而不是一个大型 PR。使用仓库配置的堆叠工具，并让审阅者能看到堆叠顺序。只有独立工作才从基分支创建分支。在进行大量堆叠工作之前，先基于最新的基分支变基。

每个 PR 都应以可审阅状态打开，不要设为草稿。云端 Agent 的 PR 工具默认会创建草稿，因此每次创建 PR 时都要设置 draft: false。如果 PR 仍以草稿状态打开，请运行托管平台的就绪命令，例如 gh pr ready <number>。提及 PR 状态前，先运行 gh pr view <number>。

打开每个 PR 后，都要对该 PR 调用 babysit-pr，并持续跟进，直到 PR 可以就绪或报告阻塞问题。每个 PR 都必须执行此操作，包括堆叠中的每个 PR。仅打开 PR 并不代表完成了此工作流。

打开 PR 的子 Agent 要运行 deslop 和 no-comments，然后也要对该 PR 进行跟进。将人工反馈和含糊不清的发现转达给父 Agent，由其反馈给用户。返回 PR URL 和最终状态。