Back to Details

babysit-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Babysit PR

照看PR

Drive an open pull request to a merge-ready state. This may run for hours — work autonomously in a loop until done or blocked.
将开放的拉取请求（PR）推进至可合并状态。此过程可能持续数小时——会自主循环执行直至完成或遇到阻塞。

Invocation

调用方式

Examples:
  • /babysit-pr on #1034
  • Babysit PR #1034 until merge-ready
  • Babysit this PR
    (resolve from current branch)
  • /babysit-pr --merge #124 #125 #126
    (shepherd and merge, in queue order)
One babysitter for many PRs beats one babysitter per PR — they share a single CodeRabbit rate limit, so a single session drains the queue without multiplying review-limit stalls.
示例：
  • /babysit-pr on #1034
  • Babysit PR #1034 until merge-ready
  • Babysit this PR
    （从当前分支解析）
  • /babysit-pr --merge #124 #125 #126
    （按队列顺序引导并合并）
一个照看者处理多个PR优于每个PR单独分配一个照看者——它们共享同一个CodeRabbit速率限制，因此单次会话即可处理队列中的PR，不会因评审限制而多次停滞。

Hard rules

硬性规则

  1. Never approve the PR. Never merge unless invoked with 
    --merge
     — the flag is the explicit authorization to merge; without it, only the human owner merges.
  2. Lint before every commit — read and follow the 
    lint
    skill (
    uv run lintro fmt
    then 
    uv run lintro chk
    , zero issues). Do not use 
    --tools
    filtering.
  3. Never push while CI is pending or running on the PR head.
  4. Minimal diffs — fix only what the PR scope and valid review/CI feedback require.
  5. Never weaken CI/workflows just to make checks pass; report instead if that seems necessary.
  6. Never force-push, amend pushed commits, or rewrite history unless the user explicitly requested it.
  1. 绝不批准PR。除非使用
    --merge
    标志调用，否则绝不合并    ——该标志是合并的明确授权；未使用该标志时，仅由人类所有者执行合并。
  2. 每次提交前必须执行lint检查——阅读并遵循
    lint
    技能（先执行
    uv run lintro fmt
    ，再执行
    uv run lintro chk
    ，确保零问题）。请勿使用
    --tools
    过滤。
  3. 当PR头部的CI处于待处理或运行状态时，绝不推送。
  4. 最小化差异——仅修复PR范围和有效评审/CI反馈要求的内容。
  5. 绝不弱化CI/工作流来让检查通过；如果看起来有必要这么做，应先上报。
  6. 除非用户明确要求，否则绝不强制推送、修改已推送的提交或重写历史。

Composed skills

组合技能

  • lint
     — pre-commit formatting and checks (required gate).
  • commit
     — conventional commits, signed commits, semantic prefixes.
  • gh-fix-ci
     (if available) — inspect failing GitHub Actions checks and logs.
Do not duplicate their full workflows here — read and follow them at commit time.
  • lint
    ——提交前的格式化与检查（必填关卡）。
  • commit
    ——符合规范的提交、签名提交、语义化前缀。
  • gh-fix-ci
    （若可用）——检查失败的GitHub Actions任务及日志。
请勿在此处重复它们的完整工作流程——提交时请阅读并遵循这些技能的要求。

Phase 0 — Resolve target PR

阶段0——确定目标PR

  1. PR number: Extract from the user message (
    #123
    , URL) or resolve from the current branch:
    bash
    gh pr view --json number,url,title,headRefName,baseRefName,state,mergeable,mergeStateStatus
  2. Repository: Use 
    gh repo view --json nameWithOwner
    from the worktree, or parse from a PR URL.
  3. Worktree: Prefer a path from conversation context. Otherwise scan worktrees:
    bash
    git worktree list
    Match 
    headRefName
    to a worktree path. If none exists, use the current git root only when it matches the resolved PR branch. Otherwise stop and ask for the correct worktree before continuing.
  4. Load repo context (after the target worktree is known): From that worktree root only, read 
    AGENTS.md
    and/or 
    CLAUDE.md
    if present. Do not read context from the parent checkout or any other repo. Precedence: 
    AGENTS.md
    is authoritative when both exist — do not also apply conflicting 
    CLAUDE.md
    instructions; if only one exists, use that file; if both conflict in a blocking way, stop and ask. Treat house standards, operating agreement (including merge policy / merge-queue notes), and standing constraints as binding for this babysit run. See the 
    stand-general
    skill's Per-repo agent context section for the expected file shape. Missing the file is fine — fall back to chat instructions and this skill's defaults.
  5. Snapshot before looping: PR URL, branch, worktree path, latest commit SHA, check summary, open review threads.
  1. PR编号：从用户消息（
    #123
    、URL）中提取，或从当前分支解析：
    bash
    gh pr view --json number,url,title,headRefName,baseRefName,state,mergeable,mergeStateStatus
  2. 仓库：从工作树中使用
    gh repo view --json nameWithOwner
    ，或从PR URL中解析。
  3. 工作树：优先使用对话上下文提供的路径。否则扫描工作树：
    bash
    git worktree list
    将
    headRefName
    与工作树路径匹配。如果没有匹配项，仅当当前Git根目录与解析出的PR分支匹配时才使用它。否则请停止并询问正确的工作树路径后再继续。
  4. 加载仓库上下文（确定目标工作树后）：仅从该工作树的根目录读取
    AGENTS.md
    和/或
    CLAUDE.md
    （如果存在）。请勿从父检出目录或任何其他仓库读取上下文。优先级：当两个文件都存在时，
    AGENTS.md
    具有权威性——请勿应用
    CLAUDE.md
    中与之冲突的指令；如果仅存在一个文件，则使用该文件；如果两者存在阻塞性冲突，请停止并询问。将内部标准、操作协议（包括合并策略/合并队列说明）和常规约束视为本次PR照看任务的绑定规则。有关预期文件格式，请参见
    stand-general
    技能的每个仓库的Agent上下文部分。如果缺少这些文件也没关系——回退到聊天指令和本技能的默认设置。
  5. 循环前快照：PR URL、分支、工作树路径、最新提交SHA、检查摘要、开放的评审线程。

Phase 1 — Launch background sub-agent (if supported)

阶段1——启动后台子Agent（若支持）

Babysitting is long-running. After Phase 0, if the agent supports background sub-agents (e.g. Claude Code's general-purpose agent run in the background), launch one and pass it the resolved PR metadata, worktree path, hard rules, and this skill's main loop (Phase 2 onward). In that mode, the parent agent returns immediately with the sub-agent link and handoff snapshot. The sub-agent runs until exit conditions are met or a human blocker is found.
Portability note: on agents without background sub-agents, skip the handoff, tell the user the babysitting loop will occupy the current session, and run the main loop (Phase 2 onward) inline instead.
PR照看是长时间运行的任务。完成阶段0后，如果Agent支持后台子Agent（例如Claude Code的通用型后台Agent），请启动一个子Agent并向其传递已解析的PR元数据、工作树路径、硬性规则以及本技能的主循环（从阶段2开始）。在此模式下，父Agent会立即返回子Agent链接和交接快照。子Agent会运行直至满足退出条件或遇到人类阻塞。
可移植性说明：对于不支持后台子Agent的Agent，请跳过交接环节，告知用户照看循环会占用当前会话，然后直接在线运行主循环（从阶段2开始）。

Phase 2 — Main loop

阶段2——主循环

Repeat until exit conditions (Phase 5) or a blocker. Track loop iterations and elapsed time; stop and report if more than 20 iterations or 6 hours pass without reaching exit conditions (avoids unbounded token/API cost on flaky CI or re-triggering bots).
重复执行直至满足退出条件（阶段5）或遇到阻塞。跟踪循环次数和耗时；如果超过20次循环或6小时仍未达到退出条件，请停止并上报（避免在不稳定的CI或重复触发机器人时产生无限制的令牌/API成本）。

Step A — Wait for CI

步骤A——等待CI完成

bash
gh pr checks <number> --repo <owner/repo>
If any check is 
pending
or 
in_progress
, wait and re-poll. Re-poll every 60 seconds; after five consecutive pending polls, double the interval up to 5 minutes. Do not push during this window.
bash
gh pr checks <number> --repo <owner/repo>
如果任何检查处于
pending
或
in_progress
状态，请等待并重新轮询。每60秒重新轮询一次；连续五次轮询均为待处理状态后，将间隔时间加倍，最长至5分钟。在此期间请勿推送。

Step B — Merge conflicts

步骤B——合并冲突

If 
mergeable
is 
CONFLICTING
, resolve intelligently in the worktree preserving branch intent. If intents conflict, stop and report — do not guess.
If the branch is behind base and failures look unrelated, merge onto latest base per repo convention. Only rebase/cherry-pick if the user explicitly approves rewriting history.
如果
mergeable
状态为
CONFLICTING
，请在工作树中智能解决冲突，同时保留分支意图。如果意图冲突，请停止并上报——请勿猜测。
如果分支落后于基准分支且失败原因看起来无关，请按照仓库约定合并至最新基准分支。仅当用户明确批准重写历史时，才进行变基/樱桃拣选操作。

Step C — Fix CI failures

步骤C——修复CI失败

For each failing GitHub Actions check:
  1. Get check status via 
    gh pr checks --json
    ; fetch logs separately with 
    gh run view <run_id> --log
    .
  2. Fix failures within PR scope in the worktree.
  3. Run project tests if applicable (follow the 
    test
    skill or repo convention).
  4. Lint gate → commit (follow 
    commit
    skill) → push.
  5. Return to Step A.
For external CI providers (non-GitHub Actions), report the details URL only.
针对每个失败的GitHub Actions检查：
  1. 通过
    gh pr checks --json
    获取检查状态；使用
    gh run view <run_id> --log
    单独获取日志。
  2. 在工作树中修复PR范围内的失败问题。
  3. 若适用，运行项目测试（遵循
    test
    技能或仓库约定）。
  4. 通过lint关卡 → 提交（遵循
    commit
    技能） → 推送。
  5. 返回步骤A。
对于外部CI提供商（非GitHub Actions），仅上报详情URL。

Step D — Triage review comments

步骤D——处理评审意见

Fetch unresolved review threads and recent bot comments:
bash
gh api graphql -f query='...'  # or gh pr view --comments, issue comment APIs
Sources: Greptile, CodeRabbit (
coderabbitai[bot]
), Bugbot, human reviewers.
For each actionable thread:
  1. Read the comment and the cited code location.
  2. Verify against current code — skip or reply N/A if outdated or already fixed.
  3. Fix valid issues with minimal diffs; lint → commit → push (after Step A allows).
  4. Reply briefly on invalid/outdated findings (one short paragraph, no argument).
  5. Resolve the thread when the platform supports it and the issue is addressed.
Greptile: Often posts a summary comment plus inline findings — treat inline items like review threads.
Bugbot: Validate carefully; only fix real bugs. Explain when disagreeing.
CodeRabbit: See Step E for rate limits; otherwise triage like other bots.
When reading GitHub API output, fetch only comment bodies and locations needed — do not load entire JSON payloads into context.
获取未解决的评审线程和最近的机器人评论：
bash
gh api graphql -f query='...'  # 或 gh pr view --comments、issue评论API
来源：Greptile、CodeRabbit（
coderabbitai[bot]
）、Bugbot、人类评审者。
针对每个可操作线程：
  1. 阅读评论及其引用的代码位置。
  2. 对照当前代码验证——如果评论已过时或问题已修复，请跳过或回复N/A。
  3. 修复有效问题，尽量减少差异；通过lint检查 → 提交 → 推送（需符合步骤A的要求）。
  4. 简要回复无效/过时的发现（一段简短内容，无需争论）。
  5. 如果平台支持且问题已解决，请标记线程为已解决。
Greptile：通常会发布一条总结评论加上内联发现——将内联项视为评审线程处理。
Bugbot：仔细验证；仅修复真实的bug。如果不同意，请给出解释。
CodeRabbit：请参见步骤E中的速率限制；否则按其他机器人的方式处理。
读取GitHub API输出时，仅获取所需的评论内容和位置——请勿将整个JSON负载加载到上下文中。

Step E — CodeRabbit review cycle (mandatory)

步骤E——CodeRabbit评审周期（必填）

CodeRabbit is not done when its GitHub check says "Review completed" on an older commit. The babysit loop must cover the current PR head.
  1. Record the latest commit SHA (
    gh pr view --json headRefOid
    ).
  2. Find the latest CodeRabbit issue comment:
    bash
    gh api repos/<owner>/<repo>/issues/<number>/comments \
  --jq '.[] | select(.user.login | test("coderabbit"; "i")) | {id, created_at, body}'
  3. Rate-limited (
    Review limit reached
    / 
    Next review available in
    ):
    • Do not sleep or poll for the reset — the rate limit does not block exit.
    • If unpushed commits exist: push per Step A discipline (CI quiescent first), then return to the loop.
    • Record that CodeRabbit review of the current head is pending due to the rate limit, and continue toward the Phase 5 exit conditions.
  4. Not rate-limited but head unreviewed (latest CodeRabbit summary/walkthrough comment is older than the current head commit, or only a rate-limit comment exists): post 
    @coderabbitai please review
    , then wait and triage.
  5. Do not burn CodeRabbit CLI runs during babysit — PR bot comments are the source of truth.
  6. Repeat Step E after every push until CodeRabbit has reviewed the current head and all resulting threads are triaged.
当CodeRabbit的GitHub检查显示“评审完成”但对应的是旧提交时，并不代表评审已完成。照看循环必须覆盖当前PR头部的提交。
  1. 记录最新提交SHA（
    gh pr view --json headRefOid
    ）。
  2. 查找最新的CodeRabbit issue评论：
    bash
    gh api repos/<owner>/<repo>/issues/<number>/comments \
  --jq '.[] | select(.user.login | test("coderabbit"; "i")) | {id, created_at, body}'
  3. 速率受限（显示
    Review limit reached
    / 
    Next review available in
    ）：
    • 请勿休眠或轮询等待限制重置——速率限制不会阻止退出。
    • 如果存在未推送的提交：按照步骤A的规则推送（先等待CI静止），然后返回循环。
    • 记录当前头部的CodeRabbit评审因速率限制而处于待处理状态，然后继续向阶段5的退出条件推进。
  4. 未速率受限但头部未评审（最新的CodeRabbit总结/遍历评论早于当前头部提交，或仅存在速率限制评论）：发送
    @coderabbitai please review
    ，然后等待并处理评审意见。
  5. 在PR照看期间，请勿消耗CodeRabbit的CLI运行次数——PR机器人评论是唯一可信来源。
  6. 每次推送后重复步骤E，直到CodeRabbit已评审当前头部提交且所有产生的线程都已处理完毕。

Step F — Re-check and repeat

步骤F——重新检查并重复

After push, return to Step A. Continue until Phase 5 exit conditions.
推送后，返回步骤A。继续执行直至满足阶段5的退出条件。

Phase 3 — Push discipline

阶段3——推送规则

Before every push:
  1. CI quiescent (Step A).
  2. Lint gate passed.
  3. Commit signed and conventional.
  4. CodeRabbit rate limit respected (Step E).
bash
git push origin HEAD
每次推送前：
  1. CI处于静止状态（步骤A）。
  2. 通过lint关卡。
  3. 提交已签名且符合规范。
  4. 遵守CodeRabbit速率限制（步骤E）。
bash
git push origin HEAD

Phase 4 — Human blockers (stop and report)

阶段4——人类阻塞（停止并上报）

Stop the loop and report if:
  • Merge conflicts you cannot resolve safely.
  • CI failures outside PR scope or requiring workflow changes.
  • Missing credentials / permissions.
  • Ambiguous product or design decisions.
Do not approve the PR to unblock it.
Do not stop solely because 
REVIEW_REQUIRED
or branch protection needs human approval — that is expected. When all other Phase 5 exit conditions are met, exit successfully and note pending approval in the final report.
如果遇到以下情况，请停止循环并上报：
  • 无法安全解决的合并冲突。
  • PR范围外的CI失败或需要修改工作流的失败。
  • 缺少凭据/权限。
  • 模糊的产品或设计决策。
请勿通过批准PR来解除阻塞。
请勿仅因
REVIEW_REQUIRED
或分支保护需要人类批准而停止——这是预期情况。当满足阶段5的所有其他退出条件时，成功退出并在最终报告中注明待批准状态。

Phase 5 — Exit conditions

阶段5——退出条件

Done when all are true:
  • All required CI checks green (or only allowed skips like 
    REVIEW_REQUIRED
    ).
  • No unresolved actionable Greptile/CodeRabbit/Bugbot threads (fixed or replied).
  • CodeRabbit has reviewed the current head — summary/walkthrough or inline review on the latest commit, with all threads triaged — or CodeRabbit is rate-limited and the pending review of the current head is noted in the final report.
  • No unpushed local commits.
  • Branch mergeable (no conflicts).
REVIEW_REQUIRED
alone is not a loop blocker — note it in the final report.
当所有以下条件均满足时，任务完成：
  • 所有必填CI检查通过（或仅存在允许的跳过项，如
    REVIEW_REQUIRED
    ）。
  • 无未解决的可操作Greptile/CodeRabbit/Bugbot线程（已修复或已回复）。
  • CodeRabbit已评审当前头部提交——对最新提交有总结/遍历或内联评审，且所有线程已处理完毕——或者CodeRabbit处于速率受限状态，且最终报告中注明当前头部的评审待处理。
  • 无未推送的本地提交。
  • 分支可合并（无冲突）。
仅
REVIEW_REQUIRED
状态不会阻止循环退出——请在最终报告中注明。

Merging (only with 
--merge
)

合并操作（仅当使用
--merge
标志时）

Skip this entire section unless invoked with 
--merge
. Without the flag, exit at Phase 5 and let the human owner merge.
除非使用
--merge
标志调用，否则跳过本节内容。未使用该标志时，在阶段5退出并由人类所有者执行合并。

Capability check (first)

能力检查（首次执行）

Before the first merge, detect what the repository provides:
  • Merge queue / auto-merge enabled? — 
    gh repo view --json autoMergeAllowed
    , ruleset inspection (
    gh api repos/<owner>/<repo>/rulesets
    ), or a note in the repo's 
    CLAUDE.md
    .
  • Conversation resolution required? — branch protection / ruleset settings.
If the repo has a merge queue or auto-merge, use queue-aware mode. Otherwise fall back to manual serial mode. The per-PR gate, release handling, failure signatures, and signing-park behavior below apply to both modes.
首次合并前，检测仓库支持的功能：
  • 是否启用合并队列/自动合并？——使用
    gh repo view --json autoMergeAllowed
    、规则集检查（
    gh api repos/<owner>/<repo>/rulesets
    ），或查看仓库
    CLAUDE.md
    中的说明。
  • 是否需要解决对话线程？——分支保护/规则集设置。
如果仓库有合并队列或自动合并功能，请使用队列感知模式。否则回退到手动串行模式。以下针对每个PR的关卡、发布处理、失败特征和签名锁定行为适用于两种模式。

Per-PR gate (both modes)

每个PR的关卡（两种模式）

Before merging (or enqueuing) any single PR:
  • Phase 5 exit conditions met for that PR.
  • Bot reviewed the CURRENT head — if the head moved since the last CodeRabbit review, re-request (
    @coderabbitai please review
    ) and wait before merging — or CodeRabbit is rate-limited and the pending review of the current head is noted in the final report.
  • Re-check PR state immediately before merge — an already-merged PR is a normal outcome, not an error; re-baseline the queue and move on.
合并（或加入队列）任何单个PR前：
  • 该PR满足阶段5的退出条件。
  • 机器人已评审当前头部提交——如果自上次CodeRabbit评审后头部提交已更新，请重新请求评审（
    @coderabbitai please review
    ）并等待后再合并——或者CodeRabbit处于速率受限状态，且最终报告中注明当前头部的评审待处理。
  • 合并前立即重新检查PR状态——PR已合并是正常结果，而非错误；重新确定队列基线并继续处理下一个PR。

Queue-aware mode (primary, when available)

队列感知模式（首选，当可用时）

Per PR: resolve all review threads (fix or refute — Step D unchanged), get checks green, then enqueue and observe:
bash
gh pr merge <n> --auto --squash --delete-branch
Never pass 
--subject
or 
--body
to 
gh pr merge
 (either mode). Repo squash defaults produce the correct commit on their own: PR title + auto-appended 
(#N)
+ blank body. An explicit 
--subject
suppresses the 
(#N)
append (seen: py-lintro 
#1916
/
#1922
landed numberless); a custom 
--body
trips commitlint 
body-max-line-length
on main's dogfood. "Squash with PR title and blank body" means rely on the defaults, not pass them as flags.
The platform serializes merges, rebases each PR, merges when its turn comes, and blocks on unresolved threads. Do not re-implement that machinery: no manual main-green waiting between merges, no single-merger lock, no hand-rolled ordering. Thread resolution is the irreducible judgment step and stays with the babysitter; the mechanical serialization belongs to the platform. Keep observing until each enqueued PR actually merges (or is ejected from the queue — then triage why).
Never use 
--admin
in this mode — it uses administrator privileges against the whole merge requirement set (reviews, required checks, queue enrollment, blocked/behind state), so it bypasses queue enrollment entirely or masks a genuine failure. If the merge fails solely because of the self-approval restriction, that is a human blocker: stop and report it (see Phase 4) so the human owner reviews and merges — do not reach for 
--admin
to push past branch protection.
针对每个PR：解决所有评审线程（修复或反驳——步骤D规则不变），确保检查通过，然后加入队列并观察：
bash
gh pr merge <n> --auto --squash --delete-branch
请勿向
gh pr merge
传递
--subject
或
--body
参数（任何模式下）。仓库的默认 squash 设置会自动生成正确的提交信息：PR标题 + 自动追加的
(#N)
+ 空正文。显式传递
--subject
会抑制
(#N)
的追加（示例：py-lintro的
#1916
/
#1922
合并后缺少编号）；自定义
--body
会触发main分支上commitlint的
body-max-line-length
检查。“使用PR标题和空正文进行squash”意味着依赖默认设置，而非传递这些参数。
平台会自动序列化合并操作，对每个PR进行变基，轮到时执行合并，并在存在未解决线程时阻塞。请勿重新实现该机制：无需在合并之间手动等待main分支检查通过，无需单合并锁，无需手动排序。线程处理是不可简化的判断步骤，由照看者负责；机械序列化由平台处理。持续观察直至每个已加入队列的PR实际合并（或被移出队列——此时需处理失败原因）。
在此模式下绝不使用
--admin
参数——它会使用管理员权限绕过所有合并要求（评审、必填检查、队列加入、阻塞/落后状态），因此会完全跳过队列加入步骤或掩盖真实的失败。如果合并失败仅因为自我批准限制，这属于人类阻塞：停止并上报（参见阶段4），以便人类所有者进行评审和合并——请勿使用
--admin
绕过分支保护。

Manual serial mode (fallback — no merge queue / auto-merge)

手动串行模式（回退——无合并队列/自动合并）

Merge command:
bash
gh pr merge <n> --squash --admin --delete-branch
Guardrails for 
--admin
here: use it only when the owner has explicitly granted merge authority for the listed PRs (the 
--merge
invocation naming them); the admin bypass clears the review requirement only — all required checks must be genuinely green (never skipped or forced). 
--admin
stays forbidden in queue-aware mode, where it would bypass queue enrollment.
Queue discipline (this mode only):
  • Single merger — before starting, verify no other session is draining the same queue. One merger at a time.
  • Strictly sequential — after each merge, wait for all post-merge runs on 
    main
    to finish before merging the next PR.
  • A 
    main
    run fails post-merge → STOP and report.     No fix-forward; the queue halts until a human decides.
  • Order by conflict — merge docs/config-only PRs first, wide-touch refactors last, to minimize rebases.
  • Under strict up-to-date-branch policies, use 
    gh pr update-branch <n>
    to bring each PR current before its turn.
合并命令：
bash
gh pr merge <n> --squash --admin --delete-branch
--admin
参数的使用规则：仅当所有者明确授予列出PR的合并权限（即调用时使用
--merge
并指定这些PR）时才使用；管理员绕过仅清除评审要求**——所有必填检查必须真正通过（绝不跳过或强制通过）**。在队列感知模式下，
--admin
始终被禁止，因为它会绕过队列加入步骤。
队列规则（仅适用于此模式）：
  • 单一合并者——开始前，验证没有其他会话在处理同一个队列。同一时间只能有一个合并者。
  • 严格串行——每次合并后，等待
    main
    分支上所有合并后的任务完成后，再合并下一个PR。
  • main
    分支合并后任务失败→停止并上报    。请勿向前修复；队列暂停直至人类做出决策。
  • 按冲突程度排序——先合并仅涉及文档/配置的PR，最后合并大范围重构的PR，以最小化变基操作。
  • 在严格的分支最新政策下，合并前使用
    gh pr update-branch <n>
    将每个PR更新至最新状态。

Releases (both modes)

发布处理（两种模式）

  • Expect auto version PRs to appear after merges.
  • If the repo convention is 1 PR = 1 release, merge the release PR and wait for its runs before moving to the next change PR.
  • Never touch publish gates (PyPI environment approval, etc.) — those are human gates. Stop and report.
  • 合并后可能会出现自动版本PR。
  • 如果仓库约定为1个PR对应1次发布，请合并发布PR并等待其任务完成后，再处理下一个变更PR。
  • 绝不触碰发布关卡（PyPI环境审批等）——这些是人类关卡。停止并上报。

Failure signatures (both modes)

失败特征（两种模式）

  • CANCELLED
     = a duplicate/superseded run; only 
    FAILURE
    / 
    TIMED_OUT
    are genuine failures.
  • Stale merge ref (setup fails on infra added to 
    main
    after the PR was created) → 
    gh pr update-branch
    ; reruns of the old ref fail deterministically.
  • Pages "Multiple artifacts named github-pages" → delete the run's 
    github-pages
    artifacts via the API, then rerun; partial reruns re-hit this forever.
  • Registry "manifest unknown" on partial reruns (a cleanup job deleted the run-scoped tags) → rerun the entire run, not just the failed job.
  • Signing locked ("failed to write commit object") → park with ~20-minute probes, resume on unlock, and report the blocker once (not on every probe).
  • CANCELLED
     = 重复/被取代的任务；只有
    FAILURE
    / 
    TIMED_OUT
    是真正的失败。
  • 陈旧的合并引用（PR创建后main分支新增基础设施导致设置失败）→ 使用
    gh pr update-branch
    ；旧引用的重新运行会确定性失败。
  • Pages出现“Multiple artifacts named github-pages” → 通过API删除该任务的
    github-pages
    工件，然后重新运行；部分重新运行会持续遇到此问题。
  • Registry在部分重新运行时出现“manifest unknown”（清理任务删除了任务范围的标签）→ 重新运行整个任务，而非仅失败的作业。
  • 签名锁定（“failed to write commit object”） → 每隔约20分钟探测一次，解锁后恢复，并仅上报一次阻塞（而非每次探测都上报）。

Phase 6 — Final report

阶段6——最终报告

Return a concise summary:
FieldValue
PRURL, title, number
Branchname @ final SHA
CIpass/fail per check
Commits pushedlist (short)
Threads handledfixed / replied N/A
CodeRabbitreviewed current head / review pending (rate-limited)
Merge-ready?yes/no + why
PRs mergedlist (or n/a without 
--merge
)
Human blockersapproval, decisions, etc.
返回简洁的总结：
字段值
PRURL、标题、编号
分支名称 @ 最终SHA
CI各检查的通过/失败状态
已推送提交列表（简短）
已处理线程已修复 / 已回复N/A
CodeRabbit已评审当前头部提交 / 评审待处理（速率受限）
是否可合并？是/否 + 原因
已合并PR列表（未使用
--merge
则为n/a）
人类阻塞项审批、决策等

Notes

说明

  • Differs from the built-in Cursor 
    babysit
    skill: this workflow is PR-parameterized, Greptile/CodeRabbit-aware, and enforces the lint gate and CodeRabbit rate-limit loop.
  • Stacked branches on py-lintro sometimes need cherry-pick onto 
    main
    , not a blind rebase — prefer conversation context or ask before rewriting history.
  • See also 
    backlog
    : the interactive routing entry point that composes this skill with 
    implement-issues
    . It does not auto-invoke either.
  • See also 
    sweep-prs
    : the periodic, fleet-wide complement — where this skill watches the PR it's actively merging, 
    sweep-prs
    retrospectively audits everything else across repos.
  • 与Cursor内置的
    babysit
    技能不同：此工作流支持PR参数化，可识别Greptile/CodeRabbit，并强制执行lint关卡和CodeRabbit速率限制循环。
  • py-lintro上的堆叠分支有时需要樱桃拣选至
    main
    分支，而非盲目变基——优先参考对话上下文或在重写历史前询问。
  • 另请参见
    backlog
    ：交互式路由入口，将本技能与
    implement-issues
    组合使用。它不会自动调用任何一个技能。
  • 另请参见
    sweep-prs
    ：定期的全仓库补充工具——本技能专注于正在合并的PR，而
    sweep-prs
    会回顾性审核所有仓库中的其他PR。