open-pr 是一个用于编码智能体的技能，用途是在已提交的工作上针对仓库配置的基础分支发起拉取请求（PR），并持续关注其检查项直至全部变为绿色或交由用户处理。技能明确要求：绝不合并 PR。
使用前提 技能要求在使用前满足：工作区干净、处于已命名的主题分支、且至少有一次不在基础分支上的提交。若存在用户尚未提交的预期改动，应留给用户自行提交后再继续。基础分支需从 docs/agents/branching.md 读取，该文件与 implement-copy 使用同一事实来源；若文件缺失或含义不明确，应检查 git branch -r，提出可能的集成分支并请用户确认，绝不猜测 PR 目标。
准备分支 停留在主题分支上，拉取最新的远程基础分支：
git fetch origin git merge --no-edit origin/<base-branch>
若仓库存在明确的 rebase 政策，则遵循该政策。若集成出现冲突，按两个分支的意图解决冲突，并在继续前完成 merge 或 rebase。集成后对仓库相关自动化检查各运行一次；失败只重跑一次，以区分偶发与缺陷。能定位命名的缺陷则修复；其他情况（无法解释的重复失败，或重跑通过）应暂停并逐字报告两次输出，由用户决定。需运行覆盖用户可见行为的全部手动测试，或在检查需要用户访问权限或判断时，为用户保留编号手动测试脚本。两种情况都应给用户一个可复现的手动测试脚本，其中每一步都写明其预期的可观察结果。随后将主题分支推送到 origin，并检查是否已有开放的 PR；若有则返回该 PR，而不是创建重复的 PR。准备完成的判定条件为：git status 干净、git merge-base --is-ancestor origin/<base-branch> HEAD 成功、每项检查已通过或已暂停并报告、远程主题分支包含 HEAD。
构建 PR 正文 检查 origin/<base-branch>...HEAD 的完整 diff 与提交。从用户请求、分支名、提交信息以及仓库 issue 跟踪惯例中解析 issue 关系；绝不臆造 issue 编号，也不声称本工作关闭了某个 issue（当事实并非如此时）。
查找代码评审记录：implement-copy 在该分支某次提交正文最后留下的 Code review 段，取携带该段的最新提交。PR 的 ## Code review 段逐字保留该记录，并以一条标记开头，指名被评审的提交及其后未覆盖的非合并提交，例如：Reviewed at <sha>; 2 commits since are unreviewed. 或 Reviewed at <sha>; nothing since. 没有记录时，该段写作 N/A — no review recorded for this branch.
在仓库根目录、docs/ 或 .github/ 下不区分大小写搜索名为 pull_request_template.md 的单模板文件，以及 .github/PULL_REQUEST_TEMPLATE/ 下的可选 Markdown 模板。若只有一个适用模板，则以其标题、顺序和清单作为确切结构；遵循其中的注释作为指令，替换其占位符，并在提交正文中省略说明性注释。当模板没有代码评审记录段时，询问用户是否在模板中添加 ## Code review；若否，则仅在本 PR 正文中把该段追加到模板各段之后。若有多个可能的模板，询问用户适用哪一个。若没有仓库模板，则读取默认 PR 模板，展示给用户，并询问是将其添加为 .github/pull_request_template.md、先做定制，还是仅用于本 PR；用户选择后继续。对仓库模板的任何更改（无论是添加默认模板还是向现有模板添加段落）都应在 PR 打开前提交并同步。
每个适用段落都要依据证据填写。区分已运行的自动化检查与用户仍需执行的手动测试脚本。仅对本 PR 完成的工作使用 GitHub 关闭语法；将相关工作和新解除阻塞的工作单独列出。当某必需段落不适用时，标注 N/A 并附简短原因。
打开 PR 将最终正文写入临时文件，然后显式指定 head 与 base 创建 PR：
gh pr create --base <base-branch> --head <topic-branch> --title <title> --body-file <body-file>
仅当用户或仓库工作流要求时才使用 draft。
跟踪检查 对新 PR 或返回的 PR 跟踪其检查项，直到没有待处理项：
gh pr checks <pr> --watch
推送后检查可能需要一分钟才注册，因此只有在仓库没有任何在拉取请求上运行的工作流时，“no checks reported” 才意味着没有 CI。若 watch 超出命令超时，仍视为进行中，应再次启动。对每个红色检查，从其失败日志（gh run view <run-id> --log-failed）进行分诊，做出与准备阶段第 4 步相同的偶发或缺陷判断。已在日志中命名缺陷的无需重跑；其他任何红色检查只重跑一次（gh run rerun <run-id> --failed）。
缺陷是指可追溯到本 PR diff 的失败。修复它，通过覆盖它的本地检查，提交、推送，在修复改变 PR 正文所述内容时更新 PR 正文，然后再次跟踪。偶发是指本 PR 未造成的失败：重跑后无需改代码即变绿，或同一检查在 <base-branch> 上本身也是红色。此时应暂停并交给用户：PR URL、检查项、失败测试、失败日志片段原文，以及证明本 PR 无责的证据。询问是在本 PR 中修复还是为其开单，然后执行所选方案：在该分支上修复并再次跟踪，或按仓库 issue 跟踪惯例开单并在 PR 正文中列为相关工作。若红色检查既无法归入缺陷也无法归入偶发，或重复出现且原因无法命名，则以同样方式暂停，并逐字提供两次输出。
跟踪完成的判定条件为：没有待处理检查、每个红色检查都已分诊、每个偶发或无法归类的失败都有用户决定，包括重跑后变绿的偶发。
报告 报告内容包括：PR URL、基础分支与主题分支、代码评审记录的标记或其缺失、已运行的本地检查、每个 PR 检查的最终状态、打开后修复的每个缺陷、每个偶发及用户决定与所开的工单、留给用户的手动测试，以及关闭、相关和新解除阻塞的 issue 链接。