chore: update shared AI tooling

.agents/skills/finish-pr/SKILL.md

@@ -46,9 +46,15 @@ Never request an automated review (`@coderabbitai review`, `@codex review`, or a
 timed re-request after a rate limit); reviews arrive on their own. Budget the loop:
 at most two review rounds after the first green head. When actionable findings keep
 arriving past that, keep the green head and triage the remaining findings yourself
-with a concrete accept or push-back. Open one stacked follow-up PR for the accepted
-fixes, then reply to each deferred finding with that PR's URL and resolve it: the
-named follow-up is the disposition, not a promise.
+with a concrete accept, push-back, or defer. Open one stacked follow-up PR for the
+accepted fixes, then reply to each deferred finding with that PR's URL, and resolve
+the thread where the finding has one: the named follow-up is the disposition, not a
+promise. A deferred top-level comment stays open; the reply is its terminal state.
+
+The budget never defers a release-blocking defect. A finding that names a
+security, authorization, data-loss, or data-corruption defect, and survives
+verification, is fixed on this head however late it arrives: shipping a known
+defect to keep a round count is the outcome the budget exists to avoid.
 
 ## 4. Stop at a Real Terminal State
 
@@ -58,7 +64,8 @@ The latest pushed head has converged only when:
 - automated reviewers are terminal, not pending
 - no actionable automated finding remains in a review thread or a top-level
   comment: each is implemented, already addressed, pushed back with evidence,
-  or deferred to a named follow-up PR
+  or deferred to a named follow-up PR, and no verified release-blocking defect
+  was deferred
 - no unresolved human request for changes remains
 - no blocking review or merge conflict remains
 

.agents/skills/open-pr/SKILL.md

@@ -19,12 +19,17 @@ defaults to the fork and would miss an upstream PR:
 git branch --show-current
 git status --short
 gh pr list --repo "$BASE_REPO" --head "$(git branch --show-current)" \
-  --state all --json number,state,isDraft,headRefName,baseRefName,url
+  --state all \
+  --json number,state,isDraft,headRefName,headRepositoryOwner,baseRefName,url
 ```
 
-An empty PR list means no PR exists. Authentication, network, or repository
-errors must remain visible and stop the workflow before history changes or
-publication.
+An empty PR list means no PR exists. `--head` filters by branch name alone, so
+in a fork workflow the list can hold another contributor's PR from a branch of
+the same name: treat a result as this checkout's PR only when its
+`headRepositoryOwner` is the owner your head remote pushes to.
+
+Authentication, network, or repository errors must remain visible and stop the
+workflow before history changes or publication.
 
 Never prepare a PR in a dirty shared checkout. If the checkout is on the
 default branch, detached, has unrelated changes, or spans repositories or

.agents/skills/rabbit-round/SKILL.md

@@ -18,9 +18,13 @@ identified.
 Fetch paginated review threads through GitHub GraphQL so unresolved state and
 thread replies are preserved. Fetch top-level issue comments separately. Record
 every participant and reply author in a thread, which comments apply to the
-current head, and which are stale. Treat a thread as bot-authored only when every
-participant is a confirmed allowed bot; a mixed or uncertain thread follows the
-human-thread rules.
+current head, and which are stale. Classify participants from a fresh fetch.
+Record a receipt for every workflow reply with its returned reply-node ID and
+exact content, and retain those receipts across resume or handoff. On later
+fetches, exclude only replies matched to an exact receipt; never infer an
+exclusion from the requester account or an attribution footer. All remaining
+participants must be confirmed allowed bots; a human, mixed, or uncertain thread
+follows the human-thread rules.
 
 Do not rely only on the REST review-comments list: it does not represent thread
 resolution or the complete conversation reliably.
@@ -37,7 +41,10 @@ comment:
 - **Push back**: incorrect, stale, speculative, or contrary to documented
   constraints.
 - **Defer**: accepted, but landing in a named follow-up PR because the enclosing
-  workflow's review budget is spent. Only with the follow-up PR's URL.
+  workflow's review budget is spent. Only with the follow-up PR's URL, and every
+  defer in one run names the same PR. Never for a verified release-blocking
+  defect (security, authorization, data loss, corruption): those are fixed on the
+  current head.
 
 Read the cited code and applicable instructions before deciding. Treat security,
 authorization, data loss, and compatibility claims as hypotheses to verify, not
@@ -69,19 +76,25 @@ finding. Keep responses short and factual:
 Follow repository attribution rules for GitHub comments. Do not claim a check
 passed unless it ran successfully on the reported head.
 
-After replying, resolve only review threads whose every participant is a
-confirmed allowed bot and that are implemented, already addressed, answered
-with a supported pushback, or deferred to a named follow-up PR. Leave human, mixed-participant, and uncertain threads
-open. Top-level comments have no thread-resolution state; do not minimize bot
-summaries by default.
+After replying, refetch each candidate thread before resolving it. Exclude only
+exact workflow reply receipts, then require every remaining participant to be a
+confirmed allowed bot. Triage any new bot finding before resolving; any human,
+unknown, mixed-participant, or uncertain arrival leaves the thread open. Resolve
+only when the finding is implemented, already addressed, answered with supported
+pushback, or deferred to a named follow-up PR. Top-level comments have no
+thread-resolution state: a reply naming the follow-up PR is the whole disposition
+there. Do not minimize bot summaries by default.
 
 ## 5. Recheck the Current Head
 
 Refresh the PR after the push and report one status:
 
 - `clean`: all current-head automated reviewers are terminal, required checks
   are green, and no actionable automated finding remains in a review thread or
-  top-level comment
+  top-level comment. A top-level finding answered with a defer reply carrying the
+  follow-up PR's URL is no longer actionable on later rounds, unless it names a
+  verified release-blocking defect: no defer makes one of those non-actionable,
+  and the status stays `needs_changes` until it is fixed on the current head
 - `pending_bots`: this round pushed the current head, or a current-head
   automated review or required check is still running
 - `needs_changes`: actionable automated feedback remains

.claude/skills/finish-pr/SKILL.md

@@ -46,9 +46,15 @@ Never request an automated review (`@coderabbitai review`, `@codex review`, or a
 timed re-request after a rate limit); reviews arrive on their own. Budget the loop:
 at most two review rounds after the first green head. When actionable findings keep
 arriving past that, keep the green head and triage the remaining findings yourself
-with a concrete accept or push-back. Open one stacked follow-up PR for the accepted
-fixes, then reply to each deferred finding with that PR's URL and resolve it: the
-named follow-up is the disposition, not a promise.
+with a concrete accept, push-back, or defer. Open one stacked follow-up PR for the
+accepted fixes, then reply to each deferred finding with that PR's URL, and resolve
+the thread where the finding has one: the named follow-up is the disposition, not a
+promise. A deferred top-level comment stays open; the reply is its terminal state.
+
+The budget never defers a release-blocking defect. A finding that names a
+security, authorization, data-loss, or data-corruption defect, and survives
+verification, is fixed on this head however late it arrives: shipping a known
+defect to keep a round count is the outcome the budget exists to avoid.
 
 ## 4. Stop at a Real Terminal State
 
@@ -58,7 +64,8 @@ The latest pushed head has converged only when:
 - automated reviewers are terminal, not pending
 - no actionable automated finding remains in a review thread or a top-level
   comment: each is implemented, already addressed, pushed back with evidence,
-  or deferred to a named follow-up PR
+  or deferred to a named follow-up PR, and no verified release-blocking defect
+  was deferred
 - no unresolved human request for changes remains
 - no blocking review or merge conflict remains
 

.claude/skills/open-pr/SKILL.md

@@ -19,12 +19,17 @@ defaults to the fork and would miss an upstream PR:
 git branch --show-current
 git status --short
 gh pr list --repo "$BASE_REPO" --head "$(git branch --show-current)" \
-  --state all --json number,state,isDraft,headRefName,baseRefName,url
+  --state all \
+  --json number,state,isDraft,headRefName,headRepositoryOwner,baseRefName,url
 ```
 
-An empty PR list means no PR exists. Authentication, network, or repository
-errors must remain visible and stop the workflow before history changes or
-publication.
+An empty PR list means no PR exists. `--head` filters by branch name alone, so
+in a fork workflow the list can hold another contributor's PR from a branch of
+the same name: treat a result as this checkout's PR only when its
+`headRepositoryOwner` is the owner your head remote pushes to.
+
+Authentication, network, or repository errors must remain visible and stop the
+workflow before history changes or publication.
 
 Never prepare a PR in a dirty shared checkout. If the checkout is on the
 default branch, detached, has unrelated changes, or spans repositories or

.claude/skills/rabbit-round/SKILL.md

@@ -18,9 +18,13 @@ identified.
 Fetch paginated review threads through GitHub GraphQL so unresolved state and
 thread replies are preserved. Fetch top-level issue comments separately. Record
 every participant and reply author in a thread, which comments apply to the
-current head, and which are stale. Treat a thread as bot-authored only when every
-participant is a confirmed allowed bot; a mixed or uncertain thread follows the
-human-thread rules.
+current head, and which are stale. Classify participants from a fresh fetch.
+Record a receipt for every workflow reply with its returned reply-node ID and
+exact content, and retain those receipts across resume or handoff. On later
+fetches, exclude only replies matched to an exact receipt; never infer an
+exclusion from the requester account or an attribution footer. All remaining
+participants must be confirmed allowed bots; a human, mixed, or uncertain thread
+follows the human-thread rules.
 
 Do not rely only on the REST review-comments list: it does not represent thread
 resolution or the complete conversation reliably.
@@ -37,7 +41,10 @@ comment:
 - **Push back**: incorrect, stale, speculative, or contrary to documented
   constraints.
 - **Defer**: accepted, but landing in a named follow-up PR because the enclosing
-  workflow's review budget is spent. Only with the follow-up PR's URL.
+  workflow's review budget is spent. Only with the follow-up PR's URL, and every
+  defer in one run names the same PR. Never for a verified release-blocking
+  defect (security, authorization, data loss, corruption): those are fixed on the
+  current head.
 
 Read the cited code and applicable instructions before deciding. Treat security,
 authorization, data loss, and compatibility claims as hypotheses to verify, not
@@ -69,19 +76,25 @@ finding. Keep responses short and factual:
 Follow repository attribution rules for GitHub comments. Do not claim a check
 passed unless it ran successfully on the reported head.
 
-After replying, resolve only review threads whose every participant is a
-confirmed allowed bot and that are implemented, already addressed, answered
-with a supported pushback, or deferred to a named follow-up PR. Leave human, mixed-participant, and uncertain threads
-open. Top-level comments have no thread-resolution state; do not minimize bot
-summaries by default.
+After replying, refetch each candidate thread before resolving it. Exclude only
+exact workflow reply receipts, then require every remaining participant to be a
+confirmed allowed bot. Triage any new bot finding before resolving; any human,
+unknown, mixed-participant, or uncertain arrival leaves the thread open. Resolve
+only when the finding is implemented, already addressed, answered with supported
+pushback, or deferred to a named follow-up PR. Top-level comments have no
+thread-resolution state: a reply naming the follow-up PR is the whole disposition
+there. Do not minimize bot summaries by default.
 
 ## 5. Recheck the Current Head
 
 Refresh the PR after the push and report one status:
 
 - `clean`: all current-head automated reviewers are terminal, required checks
   are green, and no actionable automated finding remains in a review thread or
-  top-level comment
+  top-level comment. A top-level finding answered with a defer reply carrying the
+  follow-up PR's URL is no longer actionable on later rounds, unless it names a
+  verified release-blocking defect: no defer makes one of those non-actionable,
+  and the status stays `needs_changes` until it is fixed on the current head
 - `pending_bots`: this round pushed the current head, or a current-head
   automated review or required check is still running
 - `needs_changes`: actionable automated feedback remains