pr-status-review

用途

pr-status-review 用于集中审查当前用户作为作者的所有开放拉取请求（PR），把分散在各仓库的 PR 状态汇总成一张表，并给出下一步该推进哪个 PR 的建议。它适合需要同时维护多个 PR、希望快速判断优先级并清理待办队列的开发者。

主要能力

查找你作为作者的全部开放 PR，默认按最近更新排序，最多返回 500 条；也可限定为当前仓库。
为每个 PR 收集三类信号：CI 状态、可合并性（mergeable / mergeStateStatus）、评审与反馈状态（reviewDecision、评论、评审、未解决评审线程数）。
将 CI 检查结果汇总为一个标签：全部通过或跳过为 Passing，任一失败为 Failing，有等待且无失败为 Running，无检查为 None。
判断是否存在待处理反馈：当 reviewDecision 为 CHANGES_REQUESTED，或未解决评审线程数大于 0 时视为 Yes。
可选评论分诊：设置 TYPESAFE_API_KEY 后运行附带脚本，把上次回复之后的新评论发送给 TypeSafe 的 Jev 模型，输出 pending（待处理评论数）、needsAction（需要回复的评论数）、blocking（可能阻塞合并的评论数）以及最新需要处理的评论链接。
可选 CI 失败分析：使用 --ci 时，脚本会把每个 PR 头部提交上失败的检查（每个 PR 最多五个）连同检查摘要和 Actions 作业日志摘录发送给 Jev，返回失败原因（real_failure、flaky_test、infrastructure、base_branch、process_check）以及解除阻塞的下一步（fix、update branch、fix metadata、rerun）。
生成完整报告：不带 --summary 时，脚本会把详细报告写入 ~/Downloads/pr-comment-triage-DATE.md，包含需要处理的近期评论（最新在前）、陈旧 PR 列表（反馈早于 --since，默认 90 天）以及失败检查及其原因表。

使用方式

技能以命令行工作流执行，依赖已认证的 gh。

第一步，查找开放 PR：

gh search prs --author @me --state open \
  --json repository,number,title,url,updatedAt \
  --sort updated --limit 500

若限定当前仓库，改用：

gh pr list --author @me --state open --json number,title,url,updatedAt

第二步，逐个 PR 收集状态：

gh pr checks NUMBER --repo OWNER/REPO --json name,state,bucket 2>/dev/null

gh pr view NUMBER --repo OWNER/REPO \
  --json mergeable,mergeStateStatus,reviewDecision,isDraft,comments,reviews

未解决评审线程数需用 GraphQL 查询：

gh api graphql -f query='
  query($owner:String!, $repo:String!, $number:Int!) {
    repository(owner:$owner, name:$repo) {
      pullRequest(number:$number) {
        reviewThreads(first:100) { nodes { isResolved } }
      }
    }
  }' -F owner=OWNER -F repo=REPO -F number=NUMBER \
  --jq '[.data.repository.pullRequest.reviewThreads.nodes[]
         | select(.isResolved == false)] | length'

可选评论分诊脚本（需要 Node 20+ 和已认证的 gh）：

node ~/.claude/skills/pr-status-review/scripts/triage-comments.mjs --summary --ci [--repo OWNER/REPO]

脚本输出以 owner/repo#number 为键的 JSON 映射，包含 url、pending、needsAction、blocking、newest 等字段；私有仓库会标记 skipped 并跳过分诊。

第三步，按推荐优先级（最可操作在前）构建状态表，列为：PR、Title、CI、Mergeable、Feedback、Next action。PR 需用 URL 链接，草稿需在标题后标注 (draft)，标题截断到约 50 字符。

第四步，推荐一个最值得推进的 PR，优先级顺序为：可合并且已批准且 CI 通过（立即合并）；有变更请求（处理反馈）；CI 失败（修复 CI）；落后或冲突（变基/更新分支）；等待评审（最低优先级，仅提醒评审者）。

适用场景

同时维护多个仓库的多个 PR，需要快速总览状态。
需要判断哪个 PR 最值得优先处理，以释放队列或解除他人阻塞。
希望区分评论中哪些是真正需要回复或可能阻塞合并的反馈。
希望了解 CI 失败是真实问题、不稳定测试还是基础设施问题。

限制

需要已认证的 gh；未认证时需先运行 gh auth login。
评论分诊需要设置 TYPESAFE_API_KEY；未设置或脚本失败时，回退到未解决评审线程数，并需说明这一点。
脚本会跳过私有仓库，因此保密或安全相关工作不会发送到 TypeSafe；公开评论文本以及使用 --ci 时的公开 CI 日志摘录会发送到 TypeSafe 的 API。
当 PR 加载失败或评论/失败检查分类失败时，脚本以非零状态退出，而不是输出部分计数。
作业日志 90 天后过期；更早的运行只能依据检查摘要判断。
该技能只报告和建议，不会自动合并、推送或评论，除非用户明确要求。
关于收费、价格、平台支持范围等更多信息，资料中暂未提供。

技能介绍

用途

主要能力

使用方式

适用场景

限制