You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4c96f0a
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: .codex/skills/babysit-pr/SKILL.md
+29-4Lines changed: 29 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ Accept any of the following:
29
29
4. If `diagnose_ci_failure` is present, inspect failed run logs and classify the failure.
30
30
5. If the failure is likely caused by the current branch, patch code locally, commit, and push. Do not patch random flaky tests, CI infrastructure, dependency outages, runner issues, or other failures that are unrelated to the branch.
31
31
6. If `process_review_comment` is present, inspect surfaced review items and decide whether to address them.
32
-
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.
32
+
7. If a review item is actionable and correct, patch code locally, commit, push, and then resolve the associated review thread only when allowed by the GitHub state mutation policy below.
33
33
8. Do not post replies to human-authored review comments/threads unless the user explicitly confirms the exact response. If a human review item is non-actionable, already addressed, or not valid, surface the item and recommended response to the user instead of replying on GitHub.
34
34
9. If the failure is likely flaky/unrelated and `retry_failed_checks` is present, rerun failed jobs with `--retry-failed-now`.
35
35
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.
@@ -101,14 +101,39 @@ When you agree with a comment and it is actionable:
101
101
1. Patch code locally.
102
102
2. Commit with `codex: address PR review feedback (#<n>)`.
103
103
3. Push to the PR head branch.
104
-
4. After the push succeeds, mark the associated GitHub review thread/comment as resolved.
104
+
4. After the push succeeds, resolve the associated GitHub review thread only when allowed by the GitHub state mutation policy below.
105
105
5. Resume watching on the new SHA immediately (do not stop after reporting the push).
106
106
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.
107
107
108
108
Do not post replies to human-authored GitHub review comments/threads automatically. If you disagree with a human comment, believe it is non-actionable/already addressed, or need to answer a question, report the item to the user with a suggested response and wait for explicit confirmation before posting anything on GitHub. If the user approves a response, prefix it with `[codex]` so it is clear the response is automated and not from the human user.
109
109
If the watcher later surfaces your own approved 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.
110
110
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.
111
111
112
+
## GitHub State Mutation Policy
113
+
114
+
You can read any PR state you need for monitoring. Writes must comply with this policy.
115
+
116
+
You can push PRs to update the code under review or to force CI re-runs as described above.
117
+
118
+
You can resolve review comment threads from the human who requested babysitting or from the Codex
119
+
review bot. When resolving, leave a comment prefixed with `[from Codex]: ` and explain what changes
120
+
you made and which commit includes them. Don't touch review threads if other humans other than the
121
+
user who requested babysitting have participated.
122
+
123
+
Before making any changes, fetch the PR state yourself instead of relying on the PR watcher script's
124
+
output.
125
+
126
+
Unless explicitly asked, do not:
127
+
128
+
* comment on other humans' review threads, communicate with the user in chat instead
129
+
* resolve review threads from humans other than the user
130
+
* interact with humans other than the user
131
+
* mark PRs as drafts or ready for review
132
+
* close or reopen PRs
133
+
134
+
In general, never act on GitHub in ways that would make it hard to tell whether you or the user did
135
+
something visible to other humans. When in doubt, ask the user for clarification in chat.
136
+
112
137
## Git Safety Rules
113
138
114
139
- Work only on the PR head branch.
@@ -133,10 +158,10 @@ Use this loop in a live Codex session:
133
158
3. First check whether the PR is now merged or otherwise closed; if so, report that terminal state and stop polling immediately.
134
159
4. Check CI summary, new review items, and mergeability/conflict status.
135
160
5. Diagnose CI failures and classify branch-related vs flaky/unrelated. If the overall run is still pending but `failed_jobs` already includes a failed job, fetch that job's logs and diagnose immediately instead of waiting for the whole workflow run to finish. Patch only when the failure is branch-related.
136
-
6. For each surfaced review item from another author, patch/commit/push and then resolve it if it is actionable. If it is non-actionable, already addressed, or requires a written answer, surface it to the user with a suggested response instead of posting automatically. If a later snapshot surfaces your own approved reply, treat it as informational and continue without responding again.
161
+
6. For each surfaced review item from another author, patch/commit/push if it is actionable, then resolve it only when allowed by the GitHub state mutation policy above. If it is non-actionable, already addressed, or requires a written answer, surface it to the user with a suggested response instead of posting automatically. If a later snapshot surfaces your own approved reply, treat it as informational and continue without responding again.
137
162
7. Process actionable review comments before flaky reruns when both are present; if a review fix requires a commit, push it and skip rerunning failed checks on the old SHA.
138
163
8. Retry failed checks only when `retry_failed_checks` is present and you are not about to replace the current SHA with a review/CI fix commit. Do not make code changes for unrelated flakes or infrastructure failures just to get CI green.
139
-
9. If you pushed a commit, resolved a review thread, or triggered a rerun, report the action briefly and continue polling (do not stop). If a human review comment needs a written GitHub response, stop and ask for confirmation before posting.
164
+
9. If you pushed a commit, resolved an eligible review thread, or triggered a rerun, report the action briefly and continue polling (do not stop). If a human review comment needs a written GitHub response, stop and ask for confirmation before posting.
140
165
10. After a review-fix push, proactively restart continuous monitoring (`--watch`) in the same turn unless a strict stop condition has already been reached.
141
166
11. If everything is passing, mergeable, not blocked on required review approval, and there are no unaddressed review items, report that the PR is currently ready to merge but keep the watcher running so new review comments are surfaced quickly while the PR remains open.
142
167
12. If blocked on a user-help-required issue (infra outage, exhausted flaky retries, unclear reviewer request, permissions), report the blocker and stop.
0 commit comments