From d8b91f5fa126fbf5fbfb4ae28825c3d9f70c26fc Mon Sep 17 00:00:00 2001 From: Eric Traut Date: Fri, 17 Apr 2026 12:27:48 -0700 Subject: [PATCH] Attribute automated PR Babysitter review replies (#18379) ## Summary PR Babysitter can reply directly to GitHub code review comments when feedback is non-actionable, already addressed, or not valid. Those replies should be visibly attributed so reviewers do not mistake an automated Codex response for a message from the human operator. This updates the skill instructions to require GitHub code review replies from the babysitter to start with `[codex]`. ## Changes - Adds the `[codex]` prefix requirement to the core PR Babysitter workflow. - Repeats the requirement in the review comment handling guidance where agents decide whether to reply to a review thread. --- .codex/skills/babysit-pr/SKILL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.codex/skills/babysit-pr/SKILL.md b/.codex/skills/babysit-pr/SKILL.md index 4718f55b5..d472fad66 100644 --- a/.codex/skills/babysit-pr/SKILL.md +++ b/.codex/skills/babysit-pr/SKILL.md @@ -30,7 +30,7 @@ Accept any of the following: 5. If the failure is likely caused by the current branch, patch code locally, commit, and push. 6. If `process_review_comment` is present, inspect surfaced review items and decide whether to address them. 7. If a review item is actionable and correct, patch code locally, commit, push, and then mark the associated review thread/comment as resolved once the fix is on GitHub. -8. If a review item from another author is non-actionable, already addressed, or not valid, post one reply on the comment/thread explaining that decision (for example answering the question or explaining why no change is needed). If the watcher later surfaces your own reply, treat that self-authored item as already handled and do not reply again. +8. If a review item from another author is non-actionable, already addressed, or not valid, post one reply on the comment/thread explaining that decision (for example answering the question or explaining why no change is needed). Prefix the GitHub reply body with `[codex]` so it is clear the response is automated. If the watcher later surfaces your own reply, treat that self-authored item as already handled and do not reply again. 9. If the failure is likely flaky/unrelated and `retry_failed_checks` is present, rerun failed jobs with `--retry-failed-now`. 10. If both actionable review feedback and `retry_failed_checks` are present, prioritize review feedback first; a new commit will retrigger CI, so avoid rerunning flaky checks on the old SHA unless you intentionally defer the review change. 11. On every loop, look for newly surfaced review feedback before acting on CI failures or mergeability state, then verify mergeability / merge-conflict status (for example via `gh pr view`) alongside CI. @@ -99,7 +99,7 @@ When you agree with a comment and it is actionable: 5. Resume watching on the new SHA immediately (do not stop after reporting the push). 6. If monitoring was running in `--watch` mode, restart `--watch` immediately after the push in the same turn; do not wait for the user to ask again. -If you disagree or the comment is non-actionable/already addressed, reply once directly on the GitHub comment/thread so the reviewer gets an explicit answer, then continue the watcher loop. If the watcher later surfaces your own reply because the authenticated operator is treated as a trusted review author, treat that self-authored item as already handled and do not reply again. +If you disagree or the comment is non-actionable/already addressed, reply once directly on the GitHub comment/thread so the reviewer gets an explicit answer, then continue the watcher loop. Prefix any GitHub reply to a code review comment/thread with `[codex]` so it is clear the response is automated and not from the human user. If the watcher later surfaces your own reply because the authenticated operator is treated as a trusted review author, treat that self-authored item as already handled and do not reply again. If a code review comment/thread is already marked as resolved in GitHub, treat it as non-actionable and safely ignore it unless new unresolved follow-up feedback appears. ## Git Safety Rules