Back to Details

shepherd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Shepherd PR

跟进PR（Shepherd PR）

Your job is to shepherd this PR all the way to merge-ready - reviewed, addressed, verified, and CI green. Not merged. Merging is a human decision.
Create the PR (or pick up the one just created), mark as ready for review if not yet the case, then relentlessly poll its status in a loop. Do not stop polling until all automatic reviewers (e.g., Bugbot, Cubic, etc) have fully completed their review.
  1. Wait for reviewers: Keep polling 
    gh pr view
    / 
    gh pr checks
    / review comments until ALL reviewers have finished. Do not act on partial feedback. If one is still running, keep waiting.
  2. Triage their feedback: Once both are done, implement their required changes. Fix everything medium severity and beyond. Only fix low severity issue if they're a DRY violation or if there are other issues to fix already. Strictly skip suggestions/low severity issue if they're the only ones remaining, and they qualify under super minor (nit) or rare edge case. In these cases reply explaining why and continue working autonomously.
  3. Commit and push: After implementing changes, commit and push. Then go back to step 1 - the reviewers will automatically re-review your new push.
  4. Loop: Repeat until a full cycle passes with nothing meaningful left to address from either reviewer.
  5. Double-verify merge-ready: Before declaring the PR merge-ready, verify twice that (a) all reviewers have re-run on the latest commit, (b) no outstanding required changes remain, and (c) CI is green and the PR is mergeable.
  6. Stop. Hand off to human. Report that the PR is merge-ready and wait. Do not merge.
你的任务是全程跟进这个PR，直至其达到可合并状态——已审核、问题已处理、已验证且CI状态正常。不进行合并操作，合并是人工决策。
创建PR（或接手刚创建的PR），如果尚未标记为“准备好审核”则进行标记，然后持续循环轮询其状态。在所有自动审核者（如Bugbot、Cubic等）完全完成审核前，不要停止轮询。
  1. 等待审核者完成：持续轮询
    gh pr view
    / 
    gh pr checks
    / 审核评论，直到所有审核者完成审核。不要针对部分反馈采取行动。如果仍有审核在进行，请继续等待。
  2. 处理审核反馈：当所有审核完成后，实施要求的更改。修复所有中等及以上严重程度的问题。仅当低严重程度问题违反DRY原则，或同时还有其他需要修复的问题时，才修复低严重程度问题。如果仅剩建议/低严重程度问题，且属于超级细微的挑剔（nit）或罕见边缘情况，则严格跳过这些问题，并回复解释原因，然后继续自主工作。
  3. 提交并推送：完成更改后，提交并推送。然后回到步骤1——审核者会自动重新审核你的新推送内容。
  4. 循环：重复上述步骤，直到一轮完整的审核周期后，两位审核者均无有意义的待处理问题。
  5. 双重验证可合并状态：在宣布PR达到可合并状态前，需双重验证：(a) 所有审核者已针对最新提交重新运行审核，(b) 无未解决的必填更改，(c) CI状态正常且PR可合并。
  6. 停止操作，移交人工处理：报告PR已达到可合并状态并等待。不要合并。

Hard rule: never merge without explicit approval

硬性规则：未经明确批准绝不合并

  • NEVER run 
    gh pr merge
    , the GitHub merge API, or any equivalent action on your own.
  • "All checks green" is NOT permission to merge. It is permission to stop and report.
  • Even if the user originally said "get this PR merged", treat that as "get this PR merge-ready" and ask for explicit confirmation before merging.
  • Only merge if the user replies with an explicit, unambiguous YES to merge after you've reported merge-ready (e.g. "yes merge it", "go ahead and merge"). A thumbs-up or "ok" is not enough - ask again if unclear.
  • If in doubt, do not merge. Ask.
"Pushed a fix" is not done. "All green" is not done either - it's the handoff point.
Do not stop early. Do not merge on your own.
Done is when you've looped through a clean review cycle, double-checked it, reported merge-ready, and the human has explicitly approved the merge.
  • 绝不自行运行
    gh pr merge
    、GitHub合并API或任何等效操作。
  • “所有检查通过”不代表可以合并，这只是停止操作并报告的节点。
  • 即使用户最初说“合并这个PR”，也将其视为“让这个PR达到可合并状态”，并在报告可合并状态后请求明确确认再进行合并。
  • 仅当用户在你报告可合并状态后回复明确、无歧义的YES（例如“是的，合并它”“去合并吧”）时，才进行合并。点赞或“好的”不足以作为批准——若有疑问，请再次询问。
  • 如有任何疑问，不要合并，先询问。
“已推送修复”不代表完成。“所有状态正常”也不代表完成——这只是移交的节点。
不要提前停止操作，不要自行合并。
完成的标志是：你已完成一轮无问题的审核周期，双重验证通过，报告了可合并状态，且人工明确批准了合并。