Back to Details

melech-babysit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Babysit PR

PR全程跟进

What The User Is Trying To Achieve

用户目标

The user opened a PR and wants it merged without hand-holding every 30 seconds. Between iterations the world moves: teammates comment, the base branch advances, CI reruns, review bots (Bugbot, CodeRabbit, and friends) post new findings. A one-shot check goes stale within minutes.
Your job is to keep the PR in "merge-ready" state on a recurring cadence until it merges, the user stops you, or something genuinely needs them.
用户提交了PR，希望无需频繁手动干预即可完成合并。在迭代过程中，情况不断变化：队友提出评论、基准分支更新、CI重新运行、评审机器人（Bugbot、CodeRabbit等）发布新的检查结果。一次性的检查几分钟内就会过时。
你的任务是按固定周期持续维护PR，使其保持“可合并”状态，直到PR合并、用户停止任务或出现确实需要用户处理的问题。

Loop Or You're Useless

必须循环执行，否则毫无作用

Default cadence: every 5 minutes. Accept overrides like 
melech-babysit every 10m
or 
melech-babysit 2m
.
Arm the loop before doing anything else:
  • If the user has a 
    /loop
    primitive in their setup, invoke it: 
    /loop 5m melech-babysit <PR ref>
    .
  • Otherwise arm a background heartbeat with a unique sentinel and monitored output, then run one immediate iteration.
One iteration doesn't count as babysitting. If you can't loop, say so and stop — don't pretend a single pass is enough.
默认周期：每5分钟一次。支持自定义周期，例如
melech-babysit every 10m
或
melech-babysit 2m
。
在执行任何操作前先启动循环：
  • 如果用户环境中有
    /loop
    指令，请调用它：
    /loop 5m melech-babysit <PR 引用>
    。
  • 否则，启动一个带有唯一标记和监控输出的后台心跳任务，然后立即执行一次迭代。
单次迭代不算作跟进。如果无法启动循环，请告知用户并停止任务——不要假装单次检查就足够。

Per Iteration

每次迭代步骤

Do these in order. Skip a step only if the previous one produced a hard blocker.
  1. Refresh state. 
    git fetch
    , pull the PR branch, check whether base has advanced. Never trust cached PR data older than the last tick.
  2. Merge conflicts. Resolve them intelligently, preserving intent on both sides. If intents genuinely conflict, abort the merge and surface the specific hunks to the user — do not guess.
  3. Comments. Fetch only unresolved review threads. For each, read only the comment body and the minimum location needed to act. Validate before changing code — review bots are often wrong on intent. If you disagree, reply with the reasoning instead of silently ignoring. Never mass-resolve threads.
  4. CI. Only fix failures caused by this PR's diff. Never edit workflow YAML or unrelated code just to make a check green. If a merge-blocking check looks unrelated, first try merging latest base — another PR may have fixed it. If it's still red and out of scope, stop and report.
  5. Push scoped fixes and let the next tick verify.
按以下顺序执行步骤。仅当前一步骤出现无法解决的阻塞时才可跳过后续步骤。
  1. 刷新状态。执行
    git fetch
    ，拉取PR分支，检查基准分支是否已更新。绝不要信任超过上次检查时间的缓存PR数据。
  2. 合并冲突。智能解决冲突，保留双方的代码意图。如果双方意图确实存在冲突，请中止合并并将具体冲突块告知用户——不要自行猜测处理。
  3. 评论处理。仅获取未解决的评审线程。对于每个线程，仅阅读评论内容和执行操作所需的最少位置信息。在修改代码前先验证——评审机器人经常会误解代码意图。如果你不同意机器人的建议，请回复说明理由，不要默默忽略。绝不要批量标记线程为已解决。
  4. CI处理。仅修复由PR差异导致的失败。绝不要编辑工作流YAML文件或无关代码来让检查通过。如果阻塞合并的检查看起来与PR无关，请先尝试合并最新的基准分支——可能已有其他PR修复了该问题。如果检查仍然失败且超出你的处理范围，请停止任务并报告。
  5. 推送针对性修复，等待下一次检查验证结果。

When To Stop On Your Own

自动停止任务的场景

  • PR is mergeable, CI is green, no unresolved threads → announce ready, then stop the loop.
  • A step needs a product / design / security decision only the user can make → stop the loop and hand back with a clear question.
  • Same failure repeats across 3 consecutive ticks with no progress → stop and report; you're spinning.
Always kill the loop process when stopping. A silently-alive heartbeat is worse than no babysit.
  • PR可合并、CI全部通过、无未解决线程 → 告知用户PR已就绪，然后停止循环。
  • 某一步骤需要用户做出产品/设计/安全决策 → 停止循环并向用户提出明确问题，交回处理权。
  • 连续3次检查出现相同失败且无进展 → 停止任务并报告；此时继续循环只是浪费资源。
停止任务时务必终止循环进程。静默运行的心跳任务比不进行跟进更糟糕。

Between Ticks

检查间隔期间的报告

Keep tick reports short. On each wake, say what changed (new comments, CI delta, new commits on base) and what you did. Don't reprint the whole PR state.
检查报告需简洁。每次启动时，说明发生了哪些变化（新评论、CI状态变化、基准分支新增提交）以及你执行了哪些操作。不要重复打印整个PR状态。

Do / Don't

注意事项

Do: "Tick 3 — CI now green, one Bugbot thread left. It's asking for a null check; the code already handles that case at line 42. Replied on the thread, didn't change code."
Don't: Silently mark a review bot's request "resolved" because it's inconvenient.
Do: "Base advanced by 4 commits, one of them fixed the flaky 
api-integration
job. Merged base into the branch, checks re-running."
Don't: Edit 
.github/workflows/*.yml
to skip a failing check.
Do: "Two ticks in a row the 
db-migration
job fails with the same timeout. This isn't a code fix I can make from here. Stopping the loop — can you check the migration or bump the timeout?"
Don't: Keep looping on a failure you clearly cannot fix.
正确做法：“第3次检查 — CI现已通过，仅剩一个Bugbot线程。它要求添加空值检查，但代码已在第42行处理了该情况。已在线程中回复，未修改代码。”
错误做法：因评审机器人的请求不便处理而默默标记为“已解决”。
正确做法：“基准分支新增了4个提交，其中一个修复了不稳定的
api-integration
任务。已将基准分支合并到当前分支，检查正在重新运行。”
错误做法：编辑
.github/workflows/*.yml
文件跳过失败的检查。
正确做法：“连续两次检查中
db-migration
任务均因相同超时失败。我无法在此处修复该问题。已停止循环 — 能否请你检查迁移任务或延长超时时间？”
错误做法：在明显无法修复的失败上继续循环。