kube-agents: Skill for Claude Code

Task

Work a review round until every thread has a reply and the bot's part is over: a green AI Review check — clean on a first review, nothing holding on a later one — or the third reviewed commit, whichever comes first; after either, no re-read of your own (the stop rule). AGENTS.md and the rules it links win if this file disagrees, and unattended agents follow agents/contributor/AGENTS.md where it differs; docs/pull-request-workflow.md holds the commands.

Workflow

1. Collect every unresolved thread, review-body finding and red check. Read each against the current head and current main, not your checkout: a finding that reads wrong is often a stale checkout, and an outdated thread is not an addressed one.
2. Cross-check the Self-Review. A finding it recorded without a disposition, or claimed fixed when it is not, gets settled this round; one it rejected with a reason gets that reason as the reply.
3. Triage each: fix; push back with a reason about this change and its evidence; or defer with a filed issue (pre_pr_review.md), or with an expected-fail eval case for an agent-behaviour gap you will not fix (eval_driven_development.md). A finding that correctly applies a rule with no exemption is a fix, never a push-back, on a first review and, when it is a 🔴 High, on any round; a High you can show wrong is a refutation like any other. On a later round, decline by default: fix a 🟠 Medium only when its Kind is behaviour, it is on code this pull request added, and the fix is one mechanical edit per site that adds no file, helper, branch, flag, dependency or regex alternative; otherwise reply declined: <reason about this change> or deferred to #N and record it in Self-Review. A fix that would add a mechanism — a module or file, an exported type, command, flag, env var, config key or dependency, a test that parses or simulates another system, more than about forty net lines, or a non-test, non-doc file the pull request did not touch — is a design question for the human reviewer whatever the finding's severity: say so in the thread, defer it to an issue, and do not build it on a review round. Read a red check's log before acting: a red your change caused is a fix; one it did not gets one retest if transient, otherwise a report to the check's owners.
4. Drive toward merge. A standing instruction from the user to address findings and move the pull request to merge is their decision: act on it, deciding each finding from that direction and the pull request's stated intent, and summarise each finding and its disposition to the user. Ask only without such an instruction or when neither settles a finding, and then with concrete options and a recommendation, never an open-ended question.
5. Bracket each fix with evidence, red before and green after: the eval loop for agent behaviour, live validation for runtime behaviour, or the exemption record those rules allow. Take the live-test lease before touching a shared install.
6. Fix the class: every site of the same shape, scoped by the rule behind the finding: a correctness shape across the functions this pull request touches, a convention shape only in the lines it writes. A class is fixed whole or deferred whole. Add a test that fails on the shape where one can exist.
7. Re-review non-trivial fixes with review-preflight before pushing.
8. Push once, body included: a push restarts CI, and Testing, Live validation and Self-Review go current in the same push, before any re-read, each round folded in place — a skipped live run written Not live-tested: <what a run would show, why no install reaches it>; a description ask the bot repeats after your reply is a dispute for the human reviewer, not another edit. A merge of main or a rebase that changes nothing of yours is not a round and earns no re-read.
9. Convince with proof. Reply in every thread with the fixing commit, the refutation, or the filed issue or case; answer review-body findings in one pull request comment. Ground every statement in something the reviewer can verify (a test, command output, a file:line, a design doc, or a design choice the user made for this pull request) and reason from it; make no unsourced claim.
10. Request a re-read only while one is owed. Before green you have at most two of your own: request one of the new commits under step 4's standing instruction, and without one ask the user whether, and at which width; skip it when the push already triggered one, never twice for one commit unless the first never arrived, and none for a draft until it is marked ready. A round whose only change is a body edit requests a re-read of the body on the same commit (/review fresh, one of the two), under the same split. A round that pushed nothing — every finding declined, deferred or refuted — requests no re-read: comment /request-review if no human is on it yet (who counts), so the human who rules on it is asked now. At the third reviewed commit, or once both re-reads are spent, comment /request-review if no human is on it yet — the command on the first line, then a line for the reviewer: where the fix for any 🔴 High is, that the bot re-runs on their /review, and that you will not ask for one — and stop: a requested reviewer is the end of self-service, and so is the auto-request workflow's hand-off comment (opening <!-- auto-request-review:handoff -->), which says one was requested. A green AI Review entry — No findings, No findings above low severity, or Found N issues, none holding — is settled: no /review in any form after it, no draft-to-ready or close-and-reopen to buy one; answer each open 🟠 Medium by reply, push a fix only for one you would have fixed unasked and say so in the thread, and the human reviewer rules on the rest. Re-request any human who asked for changes: their request, a /review that is not the author's, or a diff grown past twice the green head's size owes one more re-read, and nothing else does. On a finding that holds the check within that budget, return to step 1.
11. Resolve what the push settled: each thread fixed by a commit or shown factually wrong; the description thread waits for the body edit or for a ruling on a disputed ask. A kube-agents-bot finding you declined stays open with its reply until a human rules on it — an approval, or a reply in the thread that accepts the decline; a reply that asks for the fix owes it, thread open — then resolve it, citing the ruling — with a user in the loop you may resolve it earlier once your reply and Self-Review give the reason, but a resolved thread collapses and the summoned reviewer may never see it. A disagreement with a human reviewer stays open for them, including one your reply settles by a design choice. The round went into Self-Review and Live validation with the push (step 8).