Back to Details

pr-babysitter

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Babysitter

PR照看工具

  • IS: keeping one open PR moving: conflicts, CI across GitHub Actions/Buildkite/Vercel/Fly.io, inbound review comments, and merge readiness, as a background monitor or as one-shot fixes.
  • IS NOT: opening or editing the PR (
    pr-creator
    ), reviewing the diff for bugs (
    pr-reviewer
    ), applying a local 
    pr-reviewer
    report (
    tidy
    ), or npm release PRs (
    autoship
    watches its own release CI; never babysit a release or Version Packages PR it drives).
  • 功能： 持续推进单个已打开PR的进程：监控冲突、跨GitHub Actions/Buildkite/Vercel/Fly.io的CI状态、 incoming评审评论以及合并就绪状态，支持后台监控或一次性修复。
  • 不包含： 打开或编辑PR（使用
    pr-creator
    ）、评审差异以查找bug（使用
    pr-reviewer
    ）、应用本地
    pr-reviewer
    报告（使用
    tidy
    ），或处理npm发布PR（
    autoship
    会自行监控其发布CI；请勿照看由它驱动的发布PR或Version Packages PR）。

Mode Selection

模式选择

InvocationMode
"babysit", "watch this PR", "monitor", "keep it green"Monitor: Phase 1 once, then phases 2-5 on every event or tick
"fix CI", "why is CI red", "loop on CI"One-shot Phase 3 loop
"resolve conflicts", "rebase onto main", "update the branch"One-shot Phase 2
"address the comments", "reply to the reviewers", "triage review comments"One-shot Comment Triage Workflow
"is it ready", "what is blocking the merge"One-shot Phase 5 report
Standing rules, every mode:
  • No setup questions. Auto-detect the PR, the CI platforms, and the defaults (poll every 2 minutes, auto-resolve noise, no auto-merge), then start. Overrides arrive inline: "poll every 5 minutes", "enable auto-merge".
  • Skip closed or merged PRs. Skip drafts (
    isDraft
    ) unless asked.
  • Comment triage runs autonomously; the plan file is an audit trail, not an approval gate.
  • Speak only on transitions. A quiet poll says nothing.
调用指令模式
"babysit"、"watch this PR"、"monitor"、"keep it green"监控模式：先执行第一阶段一次，之后在每次事件触发或定时检查时执行第2-5阶段
"fix CI"、"why is CI red"、"loop on CI"一次性第三阶段循环
"resolve conflicts"、"rebase onto main"、"update the branch"一次性第二阶段
"address the comments"、"reply to the reviewers"、"triage review comments"一次性评论分类工作流
"is it ready"、"what is blocking the merge"一次性第五阶段报告
所有模式通用规则：
  • 无需设置问题。自动检测PR、CI平台及默认配置（每2分钟轮询一次、自动解决无效问题、不自动合并），然后启动。可通过内联指令覆盖默认值：“每5分钟轮询一次”、“启用自动合并”。
  • 跳过已关闭或已合并的PR。除非明确要求，否则跳过草稿PR（
    isDraft
    为真）。
  • 评论分类自动执行；计划文件仅作为审计跟踪，而非审批关卡。
  • 仅在状态发生变化时通知。无变化的轮询不发送任何消息。

Reference Files

参考文件

FileRead when
references/monitoring-setup.md
Phase 1: watch ladder detail, Monitor watch script, cron fallback, state file format, defaults
references/merge-conflicts.md
Phase 2: 
mergeStateStatus
table, rebase workflow, lockfile and generated-file resolution, abort criteria
references/ci-platforms.md
Phase 3: 
gh pr checks
fields and exit codes, per-platform log and retry commands, Buildkite auth chain, failure classification
scripts/fetch-comments.sh
Comment triage: run 
${CLAUDE_SKILL_DIR}/scripts/fetch-comments.sh {N}
first. One JSON document of every review, thread, and issue comment; 
--help
prints the output shape
references/github-api.md
Comment triage: script output contract, manual GraphQL/REST fallback, thread accounting, anchor ladder, awaiting-reply rule, reply and resolve
references/bot-patterns.md
Comment triage: reviewer detection, severity mapping, merge gates, noise markers, dedup, false positives
references/fix-plan-template.md
Comment triage: plan file format and the legal ignore reasons
references/verification-gate.md
Before any commit: lint, type-check, test, 
knip
, stray-artifact sweep
references/git-resilience.md
A git command hangs or fails transiently (fsmonitor wedge, stale 
index.lock
, network blip)
evals/evals.json
Only when changing this skill; never during a PR task
文件读取时机
references/monitoring-setup.md
第一阶段：监控层级细节、监控脚本、cron备选方案、状态文件格式、默认配置
references/merge-conflicts.md
第二阶段：
mergeStateStatus
表格、变基工作流、锁文件与生成文件冲突解决、终止条件
references/ci-platforms.md
第三阶段：
gh pr checks
字段与退出码、各平台日志与重试命令、Buildkite认证链、故障分类
scripts/fetch-comments.sh
评论分类：先运行
${CLAUDE_SKILL_DIR}/scripts/fetch-comments.sh {N}
。输出包含所有评审、线程和issue评论的JSON文档；
--help
可查看输出格式
references/github-api.md
评论分类：脚本输出约定、手动GraphQL/REST备选方案、线程统计、锚点层级、待回复规则、回复与解决
references/bot-patterns.md
评论分类：评审者检测、严重程度映射、合并关卡、无效标记、去重、误报处理
references/fix-plan-template.md
评论分类：计划文件格式及合法忽略原因
references/verification-gate.md
提交前：代码检查、类型校验、测试、
knip
、清理冗余产物
references/git-resilience.md
Git命令挂起或临时失败（fsmonitor阻塞、过期
index.lock
、网络波动）
evals/evals.json
仅在修改此技能时使用；PR任务执行期间绝不使用

Monitor Loop

监控循环

Phase 1 runs once in the foreground and starts the watch. Every event or tick then runs phases 2-5, diffs against the state file, and speaks only when something changed.
Copy this checklist to track progress:
text
PR babysit progress:
- [ ] Phase 1: Initialize (detect PR, pick watch mechanism, snapshot state)
- [ ] Phase 2: Conflict check
- [ ] Phase 3: CI check (diagnose, fix, gate, push)
- [ ] Phase 4: Comment check (triage new comments)
- [ ] Phase 5: Readiness check (report transitions, write state file)
第一阶段在前台执行一次并启动监控。之后每次事件触发或定时检查时执行第2-5阶段，与状态文件对比差异，仅在发生变化时通知。
复制以下清单跟踪进度：
text
PR照看进度：
- [ ] 第一阶段：初始化（检测PR、选择监控机制、快照状态）
- [ ] 第二阶段：冲突检查
- [ ] 第三阶段：CI检查（诊断、修复、关卡、推送）
- [ ] 第四阶段：评论检查（分类新评论）
- [ ] 第五阶段：就绪检查（报告状态变化、写入状态文件）

Phase 1: Initialize

第一阶段：初始化

  1. gh pr view [N] --json number,url,title,state,isDraft,headRefName,baseRefName,headRefOid,mergeable,mergeStateStatus,reviewDecision
    . No PR for the branch: say so and stop.
  2. gh repo view --json owner,name
    for the calls that need 
    owner/repo
    .
  3. Detect CI platforms from 
    gh pr checks --json name,link
    (dispatch table in Phase 3).
  4. Pick the watch mechanism: first rung that applies.
RungAvailable whenBehaviour
Harness PR subscriptionA PR-subscription tool is exposed (cloud sessions: 
Claude_Code_Remote:subscribe_pr_activity
; GitHub MCP server: 
github:subscribe_pr_activity
), or the web session's Auto-fix toggle is on		GitHub pushes review comments, CI failures, and check-suite success into the session. GitHub sends nothing when the base branch advances, so pair it with a slow Monitor poll (10 minutes) on 
mergeStateStatus
. If the tool reports a PR Steward already watching, this session gets no events: say the PR is already covered and offer the one-shot modes instead of double-fixing
Monitor tool
Monitor
is in the tool list		Start the watch script from the monitoring reference with 
persistent: true
. Quiet polls never wake the agent; each emitted line runs phases 2-5
Cron
CronCreate
is in the tool list
*/2 * * * *
running phases 2-5; every tick wakes the agent. Recurring tasks expire after 7 days
NoneNeitherDo not claim monitor mode. Run the matching one-shot mode, or say this runtime cannot keep polling
  1. Snapshot state to 
    .claude/pr-babysitter/babysit-pr-{N}.md
    : mechanism and ID, head SHA, mergeability, check states, open and awaiting-reply thread counts, review decision. This folder is never staged.
  2. Confirm in five lines: PR, watch mechanism and ID, detected CI, current state, defaults in effect.
  1. 执行
    gh pr view [N] --json number,url,title,state,isDraft,headRefName,baseRefName,headRefOid,mergeable,mergeStateStatus,reviewDecision
    。若当前分支无对应PR，告知用户并停止。
  2. 执行
    gh repo view --json owner,name
    获取需要
    owner/repo
    的调用所需信息。
  3. 通过
    gh pr checks --json name,link
    检测CI平台（第三阶段有调度表）。
  4. 选择监控机制：按优先级选择适用的方式。
层级可用条件行为
Harness PR订阅存在PR订阅工具（云端会话：
Claude_Code_Remote:subscribe_pr_activity
；GitHub MCP服务器：
github:subscribe_pr_activity
），或Web会话的自动修复开关已开启		GitHub将评审评论、CI失败及检查套件成功事件推送到会话。当基准分支更新时GitHub不会发送事件，因此需搭配慢速监控轮询（10分钟）检查
mergeStateStatus
。若工具报告已有PR管理员在监控，则当前会话不会收到事件：告知用户PR已被监控，并提供一次性模式而非重复修复
监控工具工具列表中包含
Monitor
从监控参考文档启动监控脚本，设置
persistent: true
。无变化的轮询不会唤醒代理；每条输出行都会触发第2-5阶段执行
Cron工具列表中包含
CronCreate
设置
*/2 * * * *
定时执行第2-5阶段；每次定时检查都会唤醒代理。 recurring任务7天后过期
无以上均不可用不启用监控模式。运行匹配的一次性模式，或告知当前运行时无法持续轮询
  1. 将状态快照保存到
    .claude/pr-babysitter/babysit-pr-{N}.md
    ：包含监控机制及ID、头部SHA、可合并性、检查状态、未关闭及待回复线程数、评审决策。该文件夹永远不会被暂存。
  2. 用五行内容确认：PR信息、监控机制及ID、检测到的CI、当前状态、生效的默认配置。

Phase 2: Conflict Check

第二阶段：冲突检查

gh pr view --json mergeable,mergeStateStatus
. 
DIRTY
resolves; 
BEHIND
updates; 
UNKNOWN
means GitHub is still computing, recheck next tick; anything else moves on.
bash
git fetch origin {base} && git rebase origin/{base}
git push --force-with-lease --force-if-includes
  • Clean rebase: push, notify.
  • Conflicts only in lockfiles, generated files, or changelogs: regenerate per the reference, continue the rebase, push.
  • Conflicts in source logic, migrations, or API contracts: 
    git rebase --abort
    , then notify with the files and what each side changed. Human intent decides those.
Bare 
--force
is never used. A refused lease means someone else pushed: abort and notify rather than overwrite their commits. More than one author on the branch means a rebase rewrites their commits: merge 
origin/{base}
instead.
执行
gh pr view --json mergeable,mergeStateStatus
。
DIRTY
状态需解决冲突；
BEHIND
状态需更新分支；
UNKNOWN
表示GitHub仍在计算，下次轮询再检查；其他状态则进入下一阶段。
bash
git fetch origin {base} && git rebase origin/{base}
git push --force-with-lease --force-if-includes
  • 干净变基：推送代码并通知用户。
  • 仅锁文件、生成文件或变更日志存在冲突：根据参考文档重新生成文件，继续变基，推送代码。
  • 源代码逻辑、迁移或API契约存在冲突：执行
    git rebase --abort
    ，然后通知用户冲突文件及双方的变更内容。此类冲突需人工决策。
绝不使用裸
--force
参数。若推送被拒绝，说明他人已推送代码：终止操作并通知用户，而非覆盖他人提交。若分支有多个作者，变基会重写他人提交：改为合并
origin/{base}
分支。

Phase 3: CI Check

第三阶段：CI检查

  1. gh pr checks --json name,state,bucket,link,workflow
    . 
    bucket
    is 
    pass
    , 
    fail
    , 
    pending
    , 
    skipping
    , or 
    cancel
    ; 
    link
    is the details URL.
  2. Anything 
    pending
    : wait. Diagnosing a half-finished run fixes the wrong thing.
  3. Every 
    fail
    : fetch logs by platform.
Check 
name
or 
link
PlatformLogs
buildkite/
prefix		Buildkite
bk
CLI when 
bk auth status
passes, else REST with 
BUILDKITE_API_TOKEN
, else hand over the 
link
vercel
in name or 
vercel.com
in link		Vercel
vercel inspect --logs {deployment_url}
(build logs; 
vercel logs
is runtime)
fly-
prefix or 
fly.io
in link		Fly.io
flyctl logs --app {app} --no-tail
Anything elseGitHub Actions
gh run view {run_id} --log-failed
  1. Classify per the reference: flaky (re-run once), stale dependency (reinstall and rebuild before touching source), code error (fix), 
    knip
    (delete dead code or configure), infrastructure (notify; not fixable from code).
  2. Fix, run the verification gate, commit, push. Flag regressions against the previous state (was passing, now failing).
One-shot loop ("fix CI"): after each push, 
gh pr checks --watch --fail-fast
(exit 0 green, 1 a check failed, 8 still pending). Stop and summarize when checks are green, the failure is infrastructure, or the same check fails twice with the same error after a fix. Two identical failures is the signal to stop pushing, not to try a third variant.
  1. 执行
    gh pr checks --json name,state,bucket,link,workflow
    。
    bucket
    的值为
    pass
    、
    fail
    、
    pending
    、
    skipping
    或
    cancel
    ；
    link
    为详情URL。
  2. 若存在
    pending
    状态：等待。诊断未完成的运行可能会修复错误的问题。
  3. 每个
    fail
    状态：按平台获取日志。
检查
name
或
link
平台日志获取方式
前缀为
buildkite/
Buildkite若
bk auth status
通过则使用
bk
CLI，否则使用带
BUILDKITE_API_TOKEN
的REST接口，否则提供
link
名称包含
vercel
或链接包含
vercel.com
Vercel
vercel inspect --logs {deployment_url}
（构建日志；
vercel logs
为运行时日志）
前缀为
fly-
或链接包含
fly.io
Fly.io
flyctl logs --app {app} --no-tail
其他GitHub Actions
gh run view {run_id} --log-failed
  1. 根据参考文档分类：不稳定（重新运行一次）、依赖过期（重新安装并构建后再修改源代码）、代码错误（修复）、
    knip
    问题（删除死代码或配置）、基础设施问题（通知用户；无法通过代码修复）。
  2. 修复问题，执行验证关卡，提交，推送。标记与之前状态相比的回归（之前正常，现在失败）。
一次性循环（“修复CI”）： 每次推送后，执行
gh pr checks --watch --fail-fast
（退出码0表示正常，1表示检查失败，8表示仍在等待）。当检查正常、故障为基础设施问题，或同一检查在修复后连续两次失败且错误相同时，停止并总结。连续两次相同失败是停止推送的信号，而非尝试第三种方案。

Phase 4: Comment Check

第四阶段：评论检查

  1. Count open threads and threads awaiting my reply (newest comment not mine, in any resolution state, minus a reviewer who resolved their own last comment).
  2. Compare both counts and the newest 
    updated_at
    across review and issue comments against the state file. An edited-in-place bot comment and a reply on a resolved thread both have to register.
  3. Any increase: notify "N new review comments on PR #{N}" and run the Comment Triage Workflow.
  1. 统计未关闭线程数和待回复线程数（最新评论不是自己的，无论解决状态如何，减去自行解决最后一条评论的评审者）。
  2. 将这两个计数以及评审和issue评论的最新
    updated_at
    与状态文件对比。机器人编辑的评论和已解决线程中的回复都需被识别。
  3. 若计数增加：通知“PR #{N}收到N条新评审评论”并启动评论分类工作流。

Phase 5: Readiness Check

第五阶段：就绪检查

  1. Ready means all of: 
    mergeable == MERGEABLE
    , every required check 
    pass
    , 
    reviewDecision == APPROVED
    from a review whose 
    commit_id
    is the head SHA, zero open blocking threads, zero threads awaiting my reply, every merge gate satisfied.
  2. A merge-gate comment reading "Human review required" is a blocker to report with the criteria that forced it, not a finding to fix.
  3. Ready: notify "PR #{N} is ready to merge." Merge is a one-way door: 
    gh pr merge --auto
    with the repo's merge method, and only when the user opted in.
  4. Not ready: name the blockers ("Waiting on: 2 checks pending", "Awaiting your answer: 2 questions from @reviewer", "Approval is stale: reviewed abc1234, head def5678").
  5. Write the state file for the next tick.
  1. 就绪状态需满足所有条件：
    mergeable == MERGEABLE
    、所有必填检查
    pass
    、
    reviewDecision == APPROVED
    且评审的
    commit_id
    为当前头部SHA、无未关闭的阻塞线程、无待回复线程、所有合并关卡均已满足。
  2. 包含“需要人工评审”的合并关卡评论是需要报告的阻塞项，而非需要修复的问题。
  3. 就绪状态：通知“PR #{N}已准备好合并”。合并是单向操作：仅当用户选择启用时，使用仓库的合并方式执行
    gh pr merge --auto
    。
  4. 未就绪状态：列出阻塞项（“等待中：2项检查未完成”、“待您回复：评审者@reviewer的2个问题”、“评审已过期：评审基于abc1234，当前头部为def5678”）。
  5. 写入状态文件供下次轮询使用。

Comment Triage Workflow

评论分类工作流

Inline from Phase 4 or one-shot. Autonomous: no approval gate, the plan file is the audit trail.
从第四阶段内联启动或作为一次性任务执行。自动执行：无需审批，计划文件作为审计跟踪。

Fetch

获取评论

Run 
${CLAUDE_SKILL_DIR}/scripts/fetch-comments.sh {N}
. It pages every thread and every thread's comments, recovers anchors, buckets threads, and computes 
owedReply
against your own login. A non-zero exit prints one sentence on stderr saying why; fall back to the manual queries in the API reference only when 
gh
or 
jq
cannot be installed.
Check 
reviewers[]
before classifying: every login that spoke must appear in the output with findings, a verdict, or an explicit "no content". A reviewer with reviews but zero comments is a fetch that lost something. 
anchor.source == "needs-translation"
means finish the anchor ladder against the working tree before judging that finding.
Early exit only when open threads, awaiting-reply threads, actionable reviews, and actionable issue comments are all zero.
运行
${CLAUDE_SKILL_DIR}/scripts/fetch-comments.sh {N}
。该脚本会遍历每个线程及其中的评论，恢复锚点，分类线程，并根据您的登录名计算
owedReply
。若退出码非零，会在stderr输出一句话说明原因；仅当无法安装
gh
或
jq
时，才使用API参考文档中的手动查询作为备选方案。
分类前检查
reviewers[]
：每个发言的登录名必须在输出中包含结果、结论或明确的“无内容”。若评审者有评审记录但无评论，说明获取过程丢失了信息。
anchor.source == "needs-translation"
表示在判断问题前需完成工作树的锚点层级恢复。
仅当未关闭线程、待回复线程、可操作评审和可操作issue评论均为零时才提前退出。

Classify

分类

  • Every inline comment from every author is read. An author absent from the bot table is unknown, not noise; noise needs a positive marker match.
  • Classify per comment, not per thread: a human reply inside a bot's thread carries full human weight.
  • Author type from content first, then login. 
    github-actions[bot]
    is shared by reviewers and noise alike.
  • Severity from the source's own markers; unknown sources default to Major. Severity orders the queue; it never decides whether a comment is read.
  • Human intent: fix request, question, nitpick, or acknowledgement. A question gets an answer, not a code change. Human comments are never auto-ignored: fix unless the reviewer marked it optional.
  • Merge-gate verdicts are Phase 5 inputs: record, never fix, never reply, never resolve.
  • Deduplicate bots only (same path within 3 lines, keep the highest severity). A multi-location finding is one item.
  • Every ignore carries one of the legal reasons from the plan template. "Author unrecognized" and "thread already resolved" are not among them.
  • 读取每个作者的每条内联评论。若作者不在机器人列表中则视为未知，而非无效；无效内容需要明确的标记匹配。
  • 按评论分类，而非按线程：机器人线程中的人工回复具有完整的人工权重。
  • 先根据内容判断作者类型，再根据登录名。
    github-actions[bot]
    既可能是评审者也可能是无效内容。
  • 根据来源自身的标记确定严重程度；未知来源默认设为Major。严重程度决定处理顺序；但绝不决定是否读取评论。
  • 人工意图：修复请求、问题、小问题或确认。问题需回复，而非修改代码。人工评论绝不会被自动忽略：除非评审者标记为可选，否则需修复。
  • 合并关卡结论是第五阶段的输入：记录即可，绝不修复、回复或解决。
  • 仅对机器人内容去重（路径相差3行以内，保留最高严重程度）。多位置问题视为一项。
  • 每个忽略项需包含计划模板中的合法原因之一。“作者未识别”和“线程已解决”不属于合法原因。

Fix

修复

  1. Write the plan (
    references/fix-plan-template.md
    ) to 
    .claude/pr-babysitter/pr-{N}-review-plan.md
    , print the counts, proceed.
  2. Ignored threads: one-line reply, then resolve.
  3. Questions: post the answer, leave the thread open. The reviewer resolves it.
  4. Resolved threads with an unanswered human reply: reply in place, do not unresolve, note it in the report.
  5. Fixes, one commit per logical group. Run the verification gate before each commit and stage only that group's files.
  6. Reply, then resolve, each fixed thread.
  7. Re-run the script and report: open threads, threads still awaiting my reply, questions answered but not yet acknowledged, and current CI status. The re-run is the evidence; "addressed everything" is not.
  1. 将计划（
    references/fix-plan-template.md
    ）写入
    .claude/pr-babysitter/pr-{N}-review-plan.md
    ，打印计数，继续执行。
  2. 忽略的线程：回复一行内容，然后解决线程。
  3. 问题：发布答案，保持线程未关闭。由评审者解决线程。
  4. 已解决线程中存在未回复的人工评论：在原地回复，不重新打开线程，在报告中注明。
  5. 修复：每个逻辑组提交一次。每次提交前执行验证关卡，仅暂存该组的文件。
  6. 回复每个已修复的线程，然后解决线程。
  7. 重新运行脚本并报告：未关闭线程、仍待回复的线程、已回答但未确认的问题、当前CI状态。重新运行的结果是证据；不要说“已处理所有问题”。

Stopping

停止操作

  • "Stop babysitting" / "cancel the monitor": read the mechanism and ID from the state file. Monitor watch: 
    TaskStop
    . Cron: 
    CronDelete
    . Harness subscription: the matching unsubscribe tool.
  • PR merged or closed: the watch script emits 
    TERMINAL
    and exits; cron detects it next tick and self-cancels.
  • Session exit: watches and cron jobs are session-scoped and clean themselves up. Background tasks are not restored on 
    --resume
    ; re-run the skill.
On stop, report: polls or events handled, fixes applied, conflicts resolved, comments triaged, current state.
  • “停止照看PR” / “取消监控”：从状态文件读取监控机制及ID。监控脚本：执行
    TaskStop
    。Cron：执行
    CronDelete
    。Harness订阅：使用对应的取消订阅工具。
  • PR已合并或关闭：监控脚本输出
    TERMINAL
    并退出；Cron会在下次定时检查时检测到并自动取消。
  • 会话退出：监控和Cron任务属于会话范围，会自动清理。后台任务在
    --resume
    时不会恢复；需重新运行此技能。
停止时报告：处理的轮询或事件数、应用的修复、解决的冲突、分类的评论、当前状态。

Gotchas

注意事项

  • gh pr checks --json name,state,conclusion,detailsUrl
    errors: 
    conclusion
    and 
    detailsUrl
    belong to 
    gh pr view --json statusCheckRollup
    . The check fields are 
    bucket
    and 
    link
    .
  • Filtering threads on 
    isResolved == false
    : GitHub collapses resolved threads, so a human reply posted after the resolve is the comment most likely to go unread.
  • comments(first: 20)
    : thread comments arrive oldest first, so a truncated page hides the newest comment, the one that decides whether you owe a reply. The script pages every thread to the end.
  • viewerDidAuthor
    returned 
    false
    on the viewer's own comments. Compare 
    author.login
    to 
    gh api user --jq .login
    .
  • A null 
    line
    means outdated or multi-line, not PR-level. Only a null 
    path
    is PR-level. Recover the anchor before deciding anything.
  • Triaging a bot's review body: the body is a count. Codex, Devin, Copilot, and Bugbot all put findings inline. Four empty-body human reviews are one review pass with its content in threads, not four reviewers with nothing to say.
  • Bots that edit one comment in place (auto-approval assessments, DangerJS) keep the same 
    id
    , so a state diff on ids sees nothing. Compare 
    updated_at
    .
  • Counting a review whose 
    commit_id
    is not the head SHA as an approval: branch protection with "dismiss stale approvals" drops it on the next push, and the PR reads ready until then.
  • vercel logs {url}
    streams runtime logs. A failed build lives in 
    vercel inspect --logs {url}
    .
  • bk
    without 
    bk auth status
    first: keychain tokens expire and a dead token stalls the cycle. Fall through to REST, then the check 
    link
    .
  • A monorepo type-check failure pointing into a sibling package's 
    dist
    is usually stale build output. Reinstall and rebuild before editing source.
  • git add -A
    after a fix commits hook artifacts (a root 
    schema.gql
    ) into the PR. Sweep 
    git status --porcelain
    and stage paths.
  • Resolving a thread without replying first: the reviewer sees a silent resolve and unresolves it.
  • A subscription-only watch never sees conflicts: GitHub emits no webhook when the base branch advances into one.
  • Cron when Monitor is available wakes the agent on every quiet tick and burns tokens for no signal. Polling under 2 minutes does the same to the GitHub rate limit.
  • gh pr checks --json name,state,conclusion,detailsUrl
    报错：
    conclusion
    和
    detailsUrl
    属于
    gh pr view --json statusCheckRollup
    。检查字段应为
    bucket
    和
    link
    。
  • 过滤
    isResolved == false
    的线程：GitHub会折叠已解决线程，因此解决后发布的人工评论最可能被遗漏。
  • comments(first: 20)
    ：线程评论按时间从旧到新返回，因此截断的页面会隐藏最新评论，而最新评论决定是否需要回复。脚本会遍历每个线程到最后。
  • viewerDidAuthor
    对查看者自己的评论返回
    false
    ：将
    author.login
    与
    gh api user --jq .login
    对比。
  • line
    为null表示评论已过时或为多行，而非PR级评论。只有
    path
    为null才是PR级评论。在做决定前需恢复锚点。
  • 分类机器人的评审正文：正文是计数。Codex、Devin、Copilot和Bugbot都会将问题放在内联评论中。四个空正文的人工评审表示一次评审通过，内容在线程中，而非四个评审者无内容可说。
  • 机器人原地编辑一条评论（自动审批评估、DangerJS）会保留相同的
    id
    ，因此基于id的状态差异检测不到变化。需对比
    updated_at
    。
  • 将
    commit_id
    非当前头部SHA的评审视为批准：开启“驳回过期批准”的分支保护会在下次推送时移除该批准，PR会显示就绪直到那时。
  • vercel logs {url}
    会流式传输运行时日志。失败的构建日志在
    vercel inspect --logs {url}
    中。
  • 使用
    bk
    前未执行
    bk auth status
    ：密钥链令牌过期会导致循环停滞。 fallback到REST接口，再到检查
    link
    。
  • monorepo类型检查失败指向兄弟包的
    dist
    目录通常是因为构建输出过期。重新安装并构建后再编辑源代码。
  • 修复后执行
    git add -A
    会将钩子产物（根目录的
    schema.gql
    ）提交到PR中。清理
    git status --porcelain
    并暂存指定路径。
  • 未回复就解决线程：评审者会看到静默解决并重新打开线程。
  • 仅订阅的监控永远看不到冲突：当基准分支更新导致冲突时，GitHub不会发送webhook。
  • 当Monitor可用时使用Cron会在每次无变化的定时检查时唤醒代理，浪费令牌。轮询间隔小于2分钟也会消耗GitHub的速率限制。

Related Skills

相关技能

  • pr-creator
    : opens or edits the PR; babysitting starts after it exists
  • planning
    : writes plans a fresh session executes. The fix plan this skill writes is an audit trail for one PR, not a 
    planning
    deliverable
  • pr-reviewer
    : local diff review for bugs; run it on monitor-authored fixes beyond a trivial patch
  • tidy
    : applies a 
    pr-reviewer
    report to the working tree; this skill applies GitHub review comments
  • autoship
    : npm release pipelines; it watches its own release CI, so never babysit a release PR it drives
  • pr-creator
    ：打开或编辑PR；PR照看从PR创建后开始
  • planning
    ：编写供新会话执行的计划。此技能生成的修复计划仅针对单个PR的审计跟踪，而非
    planning
    的交付物
  • pr-reviewer
    ：本地差异评审以查找bug；对监控工具生成的非 trivial修复运行此技能
  • tidy
    ：将
    pr-reviewer
    报告应用到工作树；此技能应用GitHub评审评论
  • autoship
    ：npm发布流水线；它会自行监控其发布CI，因此请勿照看由它驱动的发布PR