anarlog 的 fix-ready-prs Skill基于 gh CLI 与 GraphQL 的 PR 就绪状态巡检与修复工作流【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog导读本文基于 anarlog 仓库中.agents/skills/fix-ready-prs/SKILL.md这一内部 Agent Skill系统拆解如何对仓库中所有打开的非 draft PR 进行巡检、收集 CI 失败与 Bugbot 审查意见、并在原 PR 分支上完成修复的完整操作流程。文中同时结合.claude/skills/fix-ready-prs/SKILL.md的兼容性入口、RELEASE_AUDIT.md 的 CI 模型说明以及 .github/workflows 下的实际流水线配置帮助读者理解该 Skill 的设计动机、关键命令与可落地的执行步骤。读完本文你将掌握一套可直接复制的PR 巡检 → 失败收集 → 分支修复 → 复检 → 汇报Agent 工作流以及 gh CLI、GitHub GraphQL API、jq 在其中的配合用法。一、Skill 定位它解决什么问题1.1 兼容性入口与权威定义仓库中存在两处与 fix-ready-prs 相关的文件.claude/skills/fix-ready-prs/SKILL.md一段兼容性入口用于 Claude 类工具的技能发现skill discovery其 frontmatter 中description明确描述了用途——Inspect every open non-draft PR for CI failures and unresolved Cursor Bugbot findings, then fix them on the existing PR branches并声明权威、通用的指令存放于仓库根目录下的.agents/skills/fix-ready-prs/SKILL.md该入口文件本身不维护第二份检查清单.agents/skills/fix-ready-prs/SKILL.md约 5KB 的完整操作指令是本文的核心骨架来源。从仓库结构可以看出.agents/skills/下还同列了qa-critical-ux、release-new-version、migrate-to-sqlite、reactive-sqlite-ui等多个内部 Skill而.claude/skills/下则只保留了对应名称的兼容入口二者共同构成 Agent 的技能体系。1.2 Skill 的核心职责边界按 SKILL.md 的表述该 Skill 的职责被严格限定为逐一遍历所有打开且非 draft的 PR在现有 PR 分支上修复 CI 失败和未解决的 Bugbot 审查意见review threads不得为一个已存在的 PR 新建一个替代 PRdraft PR 默认不在范围内除非用户点名要求处理。这种在贡献者自己的分支上打补丁的模式与 RELEASE_AUDIT.md 所描述的 CI 模型一脉相承仓库刻意将重量级跨平台验证从每个 PR中剥离集中到发版前的审计阶段执行让Bugbot → fix → push这条每 PR 级反馈闭环保持低成本、快节奏。二、第一步Inventory——枚举打开的非 draft PRSKILL.md 给出的库存清点命令如下gh pr list --state open --limit 200 \ --json number,title,isDraft,headRefName,headRepositoryOwner,isCrossRepository,url,mergeStateStatus要点拆解--state open只列出打开状态的 PR--limit 200一次性拉取上限 200 个避免仓库 PR 较多时分页遗漏关键 JSON 字段isDraft用于过滤 draft保留isDraft false的条目headRefNamePR 头部分支名后续gh pr checkout依赖它isCrossRepository标识该 PR 的 head 是否来自 fork 仓库这直接决定后续推送分支时的策略详见第四节mergeStateStatus合并状态辅助判断 PR 是否具备合入条件。清点完成后记录下每个 PR 的 number、branch、URL以及 head 是否为 fork。三、第二步Collect failures——收集当前 head 的失败信息3.1 CI 检查的判定标准对每个就绪PRSKILL.md 要求收集当前 head而非历史提交上的 CI 结果与未解决的 Bugbot 线程。两条基础命令gh pr checks n gh pr view n --json statusCheckRollup,headRefOid判定为失败的条件是在当前 head上required 或仓库工作流检查的状态为FAILURE、TIMED_OUT、ACTION_REQUIRED或CANCELLED且没有被更新的运行所取代。同时明确要求不能把仍在进行中的检查IN_PROGRESS/pending当作绿灯应等待其完成或失败后再下结论Re-poll rather than guessing需要忽略的状态与作业包括SKIPPED/NEUTRAL、Netlify 的 header/pages/redirect 检查与被取消的部署预览、Mintlify Deployment 的 skip、以及本仓库在 PR 上刻意跳过的 macOS/Windows/iOS 作业。后者与仓库实际 CI 配置相印证例如 desktop_ci.yaml 等原生桌面构建在 PR 上并不全量跑原生作业见 RELEASE_AUDIT.md 的说明因此这类跳过不应被误报为失败。若某个失败的 job 有日志拉取日志以定位根因gh run view run-id --log-failed3.2 Bugbot 审查线程的收集SKILL.md 特别强调不能只看 Bugbot 检查的结论check conclusion而要看审查线程review threads。因为即使 Bugbot 检查显示绿色仍可能有未解决的评论反之旧的 finding 可能已经被修复。由于 GitHub API 返回的reviewThreads是按最旧优先排序、且没有仅未解决的过滤器所以必须手动分页直到hasNextPage为 false不能停在第一批 50 条线程上。SKILL.md 给出的分页脚本after while :; do if [ -n $after ]; then page$(gh api graphql -f query$THREADS_QUERY -F nn -F after$after) else page$(gh api graphql -f query$THREADS_QUERY -F nn) fi echo $page | jq .data.repository.pullRequest.reviewThreads.nodes[] has_next$(echo $page | jq -r .data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage) after$(echo $page | jq -r .data.repository.pullRequest.reviewThreads.pageInfo.endCursor) [ $has_next true ] || break done对应的$THREADS_QUERYGraphQL 查询query($n: Int!, $after: String) { repository(owner: fastrepl, name: anarlog) { pullRequest(number: $n) { reviewThreads(first: 50, after: $after) { pageInfo { hasNextPage endCursor } nodes { isResolved isOutdated comments(first: 5) { nodes { author { login } path line body } } } } } } }脚本关键点首次调用不带after之后每次把上一页返回的endCursor作为下一页的afterjq同时负责抽取线程内容与分页游标两者都来自同一页响应comments(first: 5)内的author.login、path、line、body字段用于后续判断该线程是否属于 Bugbot 且仍适用于当前 head。3.3 判定需要修复的线程SKILL.md 给出的修复触发条件需同时满足线程作者是cursor或cursor[bot]isResolved为 false评论是 Bugbot 的 finding——通过!-- BUGBOT_BUG_ID:标记或 severity 标题severity heading识别该意见仍适用于当前 headisOutdated为 false或者isOutdated为 true 但同样的 bug 仍存在于代码中。反之已解决的线程、以及代码已经变更的过时 findingoutdated findings whose code already changed应当跳过。3.4 补充非线程形式的评论Bugbot 可能发布尚未形成线程的独立 review commentSKILL.md 要求也对其分页gh api --paginate repos/fastrepl/anarlog/pulls/n/comments gh pr view n --commentsgh api --paginate自动翻页拉取全部评论避免遗漏散落于代码行上的意见。四、第三步Fix on the PR branch——在原 PR 分支上修复4.1 检出 PR 头部分支含 fork对每个有待修复工作的 PR先检出该 PR 的 headgh pr checkout nSKILL.md 特别警告不要执行git fetch origin headRefName或git push origin headRefName。原因在于 fork PR 的头部分支保留在贡献者的远端上origin/headRefName要么不存在、要么是另一个不同分支向origin推送可能创建出一个并非 PR head 的游离分支stray branch。gh pr checkout会正确建立跟踪关系之后git push即可沿该跟踪远端推送。若gh pr checkout或git push无法更新 fork 分支应立即停下并上报不得在origin上另开替代 PR。4.2 修复流程五步从失败日志或 Bugbot 定位处复现问题做出最小改动修复失败或 finding运行被改动路径触发的 CI 工作流对应的本地检查SKILL.md 指向AGENTS.md的 pre-commit 验证约定仓库根目录的 AGENTS.md 及apps/、plugins/等子目录下的 AGENTS.md 均有相关约定在该分支上新增提交不要 amend 他人的提交git push使用gh pr checkout建立的跟踪远端。4.3 边界纪律不要把无关的 PR 修复捆绑到同一条分支上不要 retarget 或关闭 PR若某 finding 是误报false positive保持原样不动除非用户明确要求不要手动 resolve GitHub review 线程——the code change is the fix修复本身应通过代码变更体现而非人工勾选解决。五、第四步Recheck——推送后的复检推送完成后对该 PR 重新执行一次清点确认新 CI 已在运行或为绿色此前的失败已消失、或被新的运行取代此前的 Bugbot 线程已变 outdated或将在新提交上被重新审查。如果复检时出现新的失败或新的 finding也要一并修复直到该 PR 恢复健康。六、第五步Report——汇报与收尾SKILL.md 要求对每个就绪 PR 汇总其状态cleanCI 绿色、无未解决的 Bugbot findingwaiting检查仍在运行fixed已修复注明变更内容与 PR 编号skipped draft被跳过的 draft PR。汇报完毕后不要 merge——合入决策不属于该 Skill 的职责范围。七、结合仓库源码的纵深理解7.1 与 CI 模型的对应关系RELEASE_AUDIT.md 开篇即解释了该 Skill 存在的前提仓库将重型的跨平台验证刻意排除在每 PR 流水线之外集中到发版前审计release audit阶段从而让per-PR feedback fast (so the Bugbot → fix → push loop stays cheap)。也就是说fix-ready-prs 针对的 CI 失败主要是 per-PR 级别的 lint、format、typecheck 与单元/集成测试如 fmt.yaml、lint.yaml、ci.yaml、web_ci.yaml、api_ci.yaml、cli_ci.yaml 等而 macOS/Windows/iOS 原生作业按计划跳过或按调度运行——这也解释了 SKILL.md 中忽略 macOS/Windows/iOS 跳过作业的规则为何是仓库级的既定事实而非临时处理。7.2 与 PR 提交约定的配合.github/PULL_REQUEST_TEMPLATE.md 要求 PR 描述包含Problem / Fix / Verification三段式结构并规定标题应描述预期结果如 Prevent duplicate notes after reconnect而非罗列文件变更。fix-ready-prs 在修复 CI 或 Bugbot finding 时新增的提交同样应当延续这种面向行为结果的提交风格使后续审查者与审计流程能够快速判断修复意图。7.3 Skill 设计上的可复用点从实现细节可提炼出几条通用的 Agent 工作流设计原则权威单一化.claude入口只做发现与跳转真正的清单维护在.agents下避免多份指令漂移显式的分页与幂等reviewThreads与 review comments 均要求分页到hasNextPagefalse杜绝只查前 50 条导致的漏检明确的忽略清单将SKIPPED/NEUTRAL、Netlify、Mintlify 与按计划跳过的原生作业显式列入忽略项减少误报噪音对 fork 的防御性处理用gh pr checkout 跟踪远端推送避免在origin上产生游离分支或替代 PR最小改动 单分支单主题修复限定在原分支、最小变更禁止捆绑无关修复。结语fix-ready-prs 是 anarlog 团队围绕per-PR 快速反馈闭环设计的一个内部 Agent Skill它以 gh CLI 与 GitHub GraphQL API 为工具底座以Inventory → Collect failures → Fix on the PR branch → Recheck → Report五阶段为骨架把 CI 失败与 Cursor Bugbot 审查意见的发现、修复与验证固化成可重复执行的流程。对于在 GitHub 仓库上维护 CI 健康度、或希望为自身项目搭建同类 PR 巡检 Agent 的开发者而言该文档中的命令、GraphQL 查询与边界纪律都是一套可以直接借鉴的实战模板。【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
