Skip to content

Sync Kaizen shared skills #42

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
s-hiraoku merged 1 commit into from
Jul 21, 2026
Merged

Sync Kaizen shared skills #42

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions skills/kaizen-bug-router/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <issue>`.
- 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 <issue>`.
- If the issue needs human clarification before automation, do not add an authorization or selection label; state what clarification is needed.

## Issue Body

Expand Down
34 changes: 4 additions & 30 deletions skills/pr-guardian/references/pr-feedback-audit.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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) {
Expand Down Expand Up @@ -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[@]}")"

@chatgpt-codex-connector chatgpt-codex-connector Bot Jul 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Fail closed when feedback GraphQL fetches fail

With this unguarded command substitution (and the same pattern in the nested comment loop), an auth, rate-limit, or GraphQL failure leaves page empty or shaped like an error response; the following jq -r ...hasNextPage then yields an empty string/null, so the loop breaks and the guardian can report zero unresolved feedback instead of blocking as an incomplete audit. The repo requires the vendored PR guardian to keep running until a PR is truly mergeable, so this should fail closed and validate the response before continuing.

Useful? React with 👍 / 👎.

jq -c '.data.repository.pullRequest.reviewThreads.nodes[]' <<<"${page}"
if [[ "$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' <<<"${page}")" != true ]]; then
break
Expand Down Expand Up @@ -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
Expand All @@ -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/<owner>/<repo>/pulls/<pr>/reviews?per_page=100'
gh api --paginate 'repos/<owner>/<repo>/pulls/<pr>/comments?per_page=100'
gh api --paginate 'repos/<owner>/<repo>/issues/<pr>/comments?per_page=100'
gh api --paginate 'repos/<owner>/<repo>/commits/<head-sha>/check-runs?per_page=100'
gh api --paginate 'repos/<head-owner>/<head-repo>/commits/<head-sha>/check-runs?per_page=100' # when different
gh api --paginate 'repos/<check-run-owner>/<check-run-repo>/check-runs/<check-run-id>/annotations?per_page=100'
gh api --paginate 'repos/<owner>/<repo>/check-runs/<check-run-id>/annotations?per_page=100'

@chatgpt-codex-connector chatgpt-codex-connector Bot Jul 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Audit check runs in the head repository

For fork PRs where checks are created in the head repository, hard-coding annotation fetches to <owner>/<repo> misses those runs or fetches annotations from the wrong repository; GitHub documents Checks API lookups as repository-scoped and notes they only look in the repository where the check suite or run was created (docs). The guardian can therefore report no actionable check annotations even though head-repo CI produced findings, so retain the head repository from the PR query and fetch annotations from the repository that returned each run.

Useful? React with 👍 / 👎.

```

## Reply, then resolve
Expand Down
Loading