From 042f323d6a947a2343c93474e10e593805b49052 Mon Sep 17 00:00:00 2001 From: kaizen-agents-sync Date: Mon, 20 Jul 2026 23:35:24 +0000 Subject: [PATCH] Sync Kaizen shared skills --- skills/kaizen-bug-router/SKILL.md | 10 +++--- .../references/pr-feedback-audit.md | 34 +++---------------- 2 files changed, 9 insertions(+), 35 deletions(-) diff --git a/skills/kaizen-bug-router/SKILL.md b/skills/kaizen-bug-router/SKILL.md index d179b5e..addb6c1 100644 --- a/skills/kaizen-bug-router/SKILL.md +++ b/skills/kaizen-bug-router/SKILL.md @@ -42,11 +42,11 @@ Only pass `--label` values that exist. Prefer `bug` for ordinary bug reports and Issue creation and execution authorization are separate: -- Add `kaizen` by default when the label exists, but do not add `kaizen:ready` or any other execution-selection label by default. -- Add the execution authorization label only when the user asks to queue, approve, run, execute, or put the issue on the Kaizen Loop. -- In opt-in selection mode, add the repository's configured execution authorization label only when it exists. -- If the user asks for immediate execution, file the issue, add the execution authorization label when available, then report the explicit command that should run next, such as `kaizen fix `. -- If the issue needs human clarification before automation, do not add an execution authorization label; state what clarification is needed. +- Add `kaizen` by default when the label exists, but do not add `kaizen:authorized`, `kaizen:ready`, or any other authorization or selection label by default. +- When the user asks to queue, approve, run, execute, or put the issue on the Kaizen Loop, add both the repository's execution authorization label and its configured `issues.selection.includeLabel` when those labels exist. +- In the managed opt-in fleet, this means adding both `kaizen:authorized` and `kaizen:ready`; either label alone leaves the issue ineligible. +- If the user asks for immediate execution, file the issue, add both labels when available, then report the explicit command that should run next, such as `kaizen fix `. +- If the issue needs human clarification before automation, do not add an authorization or selection label; state what clarification is needed. ## Issue Body diff --git a/skills/pr-guardian/references/pr-feedback-audit.md b/skills/pr-guardian/references/pr-feedback-audit.md index 875a028..f5fe25a 100644 --- a/skills/pr-guardian/references/pr-feedback-audit.md +++ b/skills/pr-guardian/references/pr-feedback-audit.md @@ -27,7 +27,6 @@ query($owner:String!, $name:String!, $number:Int!, $cursor:String) { repository(owner:$owner, name:$name) { pullRequest(number:$number) { headRefOid - headRepository { nameWithOwner } reviewDecision mergeStateStatus reviewThreads(first:100, after:$cursor) { @@ -57,19 +56,7 @@ query($owner:String!, $name:String!, $number:Int!, $cursor:String) { if [[ -n "${cursor}" ]]; then args+=(-f "cursor=${cursor}") fi - if ! page="$(gh "${args[@]}")"; then - echo 'failed to fetch review threads' >&2 - exit 1 - fi - if ! jq -e ' - .data.repository.pullRequest.reviewThreads as $threads - | ($threads | type == "object") - and ($threads.nodes | type == "array") - and ($threads.pageInfo.hasNextPage | type == "boolean") - ' >/dev/null <<<"${page}"; then - echo 'reviewThreads returned an invalid or incomplete response' >&2 - exit 1 - fi + page="$(gh "${args[@]}")" jq -c '.data.repository.pullRequest.reviewThreads.nodes[]' <<<"${page}" if [[ "$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' <<<"${page}")" != true ]]; then break @@ -106,19 +93,7 @@ query($threadId:ID!, $cursor:String) { if [[ -n "${cursor}" ]]; then args+=(-f "cursor=${cursor}") fi - if ! page="$(gh "${args[@]}")"; then - echo 'failed to fetch review comments' >&2 - exit 1 - fi - if ! jq -e ' - .data.node.comments as $comments - | ($comments | type == "object") - and ($comments.nodes | type == "array") - and ($comments.pageInfo.hasNextPage | type == "boolean") - ' >/dev/null <<<"${page}"; then - echo 'review comments returned an invalid or incomplete response' >&2 - exit 1 - fi + page="$(gh "${args[@]}")" jq -c '.data.node.comments.nodes[]' <<<"${page}" if [[ "$(jq -r '.data.node.comments.pageInfo.hasNextPage' <<<"${page}")" != true ]]; then break @@ -131,15 +106,14 @@ query($threadId:ID!, $cursor:String) { done ``` -Exhaust each REST endpoint with `--paginate`; summaries and first pages are incomplete evidence. Check runs can be owned by either side of a fork PR: head-repository workflows usually create runs in the head repository, while base-repository Actions and installed apps can create them in the base repository. Read `headRepository.nameWithOwner` from the GraphQL response above, query both base and head repositories when they differ, and retain the repository name alongside every returned check-run ID. Fetch each run's annotations from the same repository that returned it, deduplicating identical run IDs. If either repository query fails or the head repository is unavailable, stop and report the audit as incomplete. +Exhaust each REST endpoint with `--paginate`; summaries and first pages are incomplete evidence: ```sh gh api --paginate 'repos///pulls//reviews?per_page=100' gh api --paginate 'repos///pulls//comments?per_page=100' gh api --paginate 'repos///issues//comments?per_page=100' gh api --paginate 'repos///commits//check-runs?per_page=100' -gh api --paginate 'repos///commits//check-runs?per_page=100' # when different -gh api --paginate 'repos///check-runs//annotations?per_page=100' +gh api --paginate 'repos///check-runs//annotations?per_page=100' ``` ## Reply, then resolve