ci-monitoring

用途

CI Monitoring 用于在创建 PR 之后自动监控 CI 流水线、解决失败、处理评审反馈，并在所有门禁通过后合并 PR。其核心原则是：CI 失败和未解决的评审反馈都是阻塞项。该技能通常由 issue-driven-development 或 autonomous-orchestration 调用，接续 pr-creation 之后，完成 PR 生命周期。

主要能力

等待并检查 CI 状态，支持一次性检查与持续监视。
识别 CI 失败原因，在本地复现、修复并推送，然后重新等待 CI。
在 CI 变绿后，通过 GraphQL 查询 PR 的未解决评审线程。
对每条未解决线程执行：阅读反馈、验证是否适用于当前代码库、修复或延期（附带 issue）或有理有据地反驳、在线程中回复、标记解决、推送修复并回到 CI 检查。
对自动化评审工具（如 Codex、CodeRabbit 等）提出的安全标记认真对待，并对照代码库进行验证。
当 CI 全绿且无未解决评审时，立即执行合并命令并更新 issue 标签，不停止汇报或询问，直接进入下一个 issue。

使用方式

该技能以循环流程运作：PR 创建后等待 CI；若 CI 为红色则修复、推送并回到等待；若为绿色则检查未解决评审；若无未解决评审则合并 PR，若有则逐条处理并回到 CI 检查。

检查 CI 的命令：

gh pr checks [PR_NUMBER]
gh pr checks [PR_NUMBER] --watch

处理 CI 失败：使用 gh run view [RUN_ID] --log-failed 定位失败，本地复现，修复并推送，等待 CI，必要时重复。详细模式参见 reference/ci-failures.md。

处理评审反馈：CI 变绿后，使用 GraphQL 查询未解决线程：

gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $pr) {
      reviewThreads(first: 100) {
        nodes { id isResolved isOutdated comments(first: 1) { nodes { body author { login } path } } }
      }
    }
  }
}' -f owner="[OWNER]" -f repo="[REPO]" -F pr=[PR_NUMBER]

对每条未解决线程（isResolved: false）执行：1）阅读并理解反馈；2）验证是否在技术上适用于当前代码库；3）修复、延期（附带 issue）或有理有据地反驳；4）在线程中回复：gh api repos/.../pulls/.../comments/[ID]/replies -f body="..."；5）标记解决：gh api graphql -f query='mutation { resolveReviewThread(...) }'；6）推送修复，回到 CI 检查。详细命令参见 reference/review-feedback.md。

合并门禁：CI 全绿且无未解决评审时，立即合并：

gh pr merge [PR_NUMBER] --squash --delete-branch
gh issue edit [ISSUE_NUMBER] --remove-label "status:in-review" --add-label "status:done"

不要停下来汇报或询问，继续处理下一个 issue。例外情况：带有 do-not-merge 标签的 PR。

适用场景

由 issue 驱动开发或自主编排流程中，PR 创建后的自动收尾。
需要自动监控 CI 并处理评审反馈的团队或个人工作流。
使用 GitHub CLI 和 GraphQL API 管理 PR 生命周期的场景。

限制

该技能依赖 GitHub CLI（gh）及 GraphQL API 的可用性。
需要仓库具备相应的权限以查询评审线程、回复评论和合并 PR。
带有 do-not-merge 标签的 PR 不会自动合并。
本地测试应先行，CI 用于验证而非发现问题；若 CI 发现本地未发现的 bug，说明本地测试不充分。
关于收费、价格、平台支持等具体信息，资料中暂未提供。

技能介绍

用途

主要能力

使用方式

适用场景

限制