用途
open-pr 用于把一个改动整理成范围窄、可落地的拉取请求，打开后就绪并持续跟进到合并就绪状态，最后返回 PR 的 URL 和最终状态。它强调“小步、可评审、可落地”，并倾向于用多个窄 PR 代替一个大型 PR。
主要能力
- 读取仓库说明，确定目标基线分支、分支策略、PR 工具以及提交和 PR 约定。仓库已有约定或 PR 模板时，优先遵循仓库约定。
- 检查工作树：状态、暂存与未暂存差异、每一个未跟踪文件、分支祖先关系、提交范围和远端状态，验证每项改动都属于目标 PR。
- 提交规划：规划小而有序、能讲述改动故事的提交，每个提交可独立评审和落地。对属于刚创建且未共享提交的修复使用 amend；可分离的改动新建提交。对共享工作进行 rebase 或 force-push 前需先询问。
- 质量检查：每次提交前对准确的目标差异运行 deslop；评审前对整个 PR 差异运行 no-comments；对已接受的评论发现所导致的改动重新规划和运行 deslop。
- 提交信息：使用 Conventional Commits，以改动区域作为 scope，主题简短、祈使语气，必要时点出真实符号，不加句末句号；正文说明主题中不存在的事实，不重复主题。对每个主题和正文应用 unslop，但不改变 Conventional Commit 语法。
- 推送：对每个提交和推送使用 ship，并指明属于该提交的改动。
- PR 标题：同样使用 Conventional Commits 格式，保留冠词、每个动作使用一个普通词、能用直接动词时避免 -ing，并对标题应用 unslop 但不改变语法。
- PR 正文：以无标题段落开头，说明问题（有具体失败案例时一并给出）以及改动如何应对，点出关键符号；必要时补充超出范围的内容或重命名两侧的说明。随后按顺序添加 ## Tradeoffs（真实取舍、被拒方案、已知限制、可能破坏之处，无可说时省略该节）和 ## Verification（每项检查的运行方式与严格程度，给出真实路径如 CLI 命令、UI 流程或针对性测试，并说明每项检查的结果而非仅命令名）。之后可附能证明主张的截图或视频。不添加 ## Summary 或 ## Test plan 样板。对完成的描述应用 unslop。
- 就绪状态：每个 PR 都以 ready 而非 draft 打开。云代理 PR 工具默认 draft，因此每次创建 PR 调用都要设置 draft: false；若仍为草稿，运行宿主就绪命令，例如 gh pr ready <number>。引用 PR 状态前先运行 gh pr view <number>。
- 跟进：打开每个 PR 后，为该 PR 调用 babysit-pr，并跟进到就绪或报告阻塞；对每个 PR（包括堆叠中的每个 PR）都执行。仅打开 PR 并不算完成此工作流。
- 子代理：打开 PR 的子代理运行 deslop 和 no-comments，并同样负责 babysit；将人类反馈和模糊发现转交父级给用户。
使用方式
技能文本未提供具体的安装命令或调用示例，暂未提供。可从其描述的流程理解：先读取仓库说明确定约定，再检查工作树与差异，规划提交并运行 deslop / no-comments，使用 ship 逐提交推送，按 Conventional Commits 撰写标题正文，以 ready 状态打开 PR，随后调用 babysit-pr 跟进，最终返回 PR URL 与最终状态。
适用场景
- 需要把一个或一组相关改动整理成单个窄范围、可评审、可落地的 PR。
- 需要在打开 PR 后继续跟进评论、检查与合并就绪状态。
- 需要遵循仓库既有提交约定、PR 模板和分支策略的团队协作环境。
- 需要成组堆叠 PR（stack）时，按仓库配置的堆叠工具保持顺序可见，独立工作才从基线分支分叉，并在大量堆叠工作前 rebase 到最新基线。
限制
- 不得在未经批准的情况下补丁移除、重置、丢弃或覆盖用户工作；工作树混入无关改动或状态混乱时应停止询问。
- 在范围不清、合并冲突、敏感数据、缺少权限或不安全历史改写时应停止。
- rebase 共享工作或 force-push 前需询问。
- 技能文本未说明其支持的具体平台、命令行工具依赖、是否收费或价格、安装方式，暂未提供。
- 技能文本未提供实际效果、性能或成功率的量化说明。