用途：把一个 PR 从评审推进到合并。输入为 PR 编号、URL 或留空（留空时通过 gh pr view 解析当前分支的 PR）；若当前分支还没有 PR 则先推送并创建（仅限维护者分支）。目标是所有代码评审发现的问题都被修复、CI 全绿、PR 已合并。
主要能力与流程： 1）加载 PR，读取标题、描述、关联 issue 与 diff 以了解目标；若存在冲突先 rebase 到 origin/main。 2）切换到 PR 分支，在当前工作树中操作，不新建 worktree 或克隆；切换前记录原始分支/提交与未提交改动，用 WIP 提交或带唯一标签的 stash 暂存（不要用裸 git stash）。维护者 PR 直接推送到该分支，不另开修复 PR；外部 fork PR 若维护者可修改则推送 fork 分支，否则停下询问用户。每次推送前确认作者没有新推送。 3）按仓库绝对路径下的 code-review 技能对 PR 变更做审查，收集 must fix、should fix 与 nits 全部发现。 4）修复所有发现，保持 PR 范围，运行 lint 与相关测试，必要时重新生成 OpenAPI/客户端/文档。循环执行“审查→修复→再审查”，直到某次完整审查返回零发现；唯一提前退出条件是步骤 0 的 blocker（修复会违背 PR 目标，如 PR 本身就是裸 SQL 处理器、new advisory lock、返回元组的 API 等），此时立即停止并询问用户。 5）等待 CI 全绿：仓库没有必需状态检查，需针对推送的 head SHA 判断 CI 工作流结果；涉及 API/引擎时 test-api、Core LLM tests、LLM 验收矩阵必须成功；oracle-client 任务已知不稳定可忽略。fork PR 跳过这些任务，需在上游分支跑完整套件后再合并。 6）先恢复工作树到最初状态，再执行 gh pr merge <N> --squash --delete-branch，并删除临时验证分支。报告 PR 链接、修复的发现、有意保留项及门禁的 CI 运行。
限制与注意：gh pr edit 在该仓库会因 GraphQL 弃用静默失败，需改用 REST API；不在维护者 PR 上发评审评论。其他细节资料未提供的部分暂未说明。