iterate-pr

# 在 PR 上迭代直到 CI 通过 在当前分支上持续迭代，直到所有 CI 检查通过且审查反馈得到解决。 **要求**：GitHub CLI (`gh`) 已认证并可用。 ## 处理流程 ### 第一步：识别 PR bash gh pr view --json number,url,headRefName,baseRefName 如果当前分支不存在 PR，请停止并通知用户。 ### 第二步：首先检查 CI 状态 在查看审查反馈之前，始终检查 CI/GitHub Actions 状态： bash gh pr checks --json name,state,bucket,link,workflow `bucket` 字段将状态分类为：`pass`、`fail`、`pending`、`skipping` 或 `cancel`。 **重要**：如果其中任何检查仍处于 `pending` 状态，请在继续之前等待： - `sentry` / `sentry-io` - `codecov` - `cursor` / `bugbot` / `seer` - 任何 Linter 或代码分析检查 这些机器人可能会在检查完成后发布额外的反馈评论。等待可以避免重复工作。 ### 第三步：收集审查反馈 一旦 CI 检查完成（或至少机器人相关检查完成），收集人工和机器人反馈： **审查评论和状态：** bash gh pr view --json reviews,comments,reviewDecision **内联代码审查评论：** bash gh api repos/{owner}/{repo}/pulls/{pr_number}/comments **PR 对话评论（包含机器人评论）：** bash gh api repos/{owner}/{repo}/issues/{pr_number}/comments 查找来自 Sentry、Codecov、Cursor、Bugbot、Seer 和其他自动化工具的机器人评论。 ### 第四步：调查失败原因 对于每个 CI 失败，获取实际日志： bash # 列出此分支的最近运行记录 gh run list --branch $(git branch --show-current) --limit 5 --json databaseId,name,status,conclusion # 查看特定运行的失败日志 gh run view --log-failed 不要仅根据检查名称假设失败原因。始终阅读实际日志。 ### 第五步：验证反馈 对于每条反馈（CI 失败或审查评论）： 1. **阅读相关代码** - 在进行更改之前了解上下文 2. **验证问题是否真实** - 并非所有反馈都是正确的；审查者和机器人可能会出错 3. **检查是否已解决** - 该问题可能已在后续提交中修复 4. **跳过无效反馈** - 如果该顾虑不合理，请继续处理下一条 ### 第六步：解决有效问题 进行最小化、有针对性的代码更改。只修复真正损坏的部分。 ### 第七步：提交并推送 bash git add -A git commit -m "fix: <descriptive message of "