持续迭代 PR 至 CI 通过

要解决什么问题

PR 合并前往往卡在两类事：CI 红灯和审查/机器人评论。人工反复 git push、刷新 Checks、翻日志、对照 inline comment，很容易漏掉 pending 的外部检查（Sentry、Codecov、Cursor Bugbot 等），或在机器人还没跑完时就改代码，造成重复劳动。

技能如何工作

本技能把「看状态 → 收反馈 → 查日志 → 验证 → 小改 → 提交推送 → 等 CI」收成一条可重复的闭环，并依赖 GitHub CLI（gh） 与当前分支上已存在的 PR。

核心流程要点：

• 先 CI 后评论：在收集审查反馈前先看 Actions/Checks；对 Sentry、Codecov、Cursor/Bugbot/Seer 及各类 linter，若仍为 pending 则先等待，避免机器人后续再补评论。
• 收集全量反馈：PR 对话、inline 审查、以及自动化工具评论一并纳入。
• 按日志调查失败：不凭检查名称猜原因，用 gh run view --verbose 等读实际日志；外部检查的 link 字段可跳转调查。
• 验证再改：读相关代码、确认问题真实存在、检查是否已在后续提交修复；不合理意见可跳过。
• 最小修复与推送：只改出问题部分；推送后用内置监视或轮询等到检查结束，再决定是否回到「查 CI」。

成功退出条件：必需检查均为通过（bucket: pass），且无未处理的人工审查反馈。同一失败连续三次仍复现、需要产品/架构决策、或与分支无关的基础设施故障时，应停下来向人求助；无 PR 或需 rebase 时立即停止。

适用边界

• 前提：已认证可用的 gh，且当前分支已有对应 PR。
• 关注范围可用 gh pr checks --required 收窄到必需检查。
• 技能目标是把 PR 推到可合并状态，不替代你对业务逻辑与安全风险的最终判断。