with one click
with one click
| name | review |
| description | Review code changes and return prioritized, actionable findings |
| register_cmd | true |
| cmd_info | review code changes |
Review the requested code changes as if you are reviewing another engineer's PR.
User-provided target or constraints (honor these): $ARGUMENTS
PR#68 feat/headless-mode "feat: add non-interactive prompt mode", assume the GitHub CLI is available. Use gh pr view to inspect PR metadata, resolve the base/head branches, fetch as needed, compute the merge base, and review the PR diff. Do not checkout a different branch unless the user explicitly asks or confirms.origin; it may live on a contributor fork. Prefer gh pr checkout --detach <number> only if checkout is acceptable, or fetch the head repository/ref reported by gh pr view --json headRepository,headRefName into a temporary remote/ref before diffing./review PR#68 feat/headless-mode "feat: add non-interactive prompt mode", use the PR number/title/branch as hints, verify them with gh pr view 68, then review the code changes relative to the PR base branch.Only report issues the original author would likely fix if they knew about them.
Flag a finding only when:
Do not stop at the first issue. Return all qualifying findings. If there are no findings worth fixing, say so clearly.
Use repository tools to inspect the actual diff and surrounding code. Prefer precise commands such as:
git status --shortgit diff --stagedgit diffgit diff <merge-base>...HEADgit show <sha>gh pr view <number> --json number,title,body,baseRefName,headRefName,url,authorRead nearby implementation and tests when needed to prove whether a suspected issue is real. Avoid speculative findings.
Use these severity levels for finding titles:
[P0] — Drop everything to fix. Blocking release, operations, or major usage. Only use for universal issues that do not depend on assumptions about inputs.[P1] — Urgent. Should be addressed in the next cycle.[P2] — Normal. Should be fixed eventually.[P3] — Low. Nice to have.For each finding, include:
[P0], [P1], [P2], or [P3];Keep line ranges as short as possible and make sure they overlap the reviewed diff when possible.
End with an overall verdict:
patch is correct if existing code/tests should not break and no blocking issues were found;patch is incorrect if the patch has blocking correctness, security, reliability, or maintainability issues that should prevent merging.Do not mark a patch incorrect for non-blocking issues such as style, formatting, typos, documentation nits, or ordinary [P2]/[P3] follow-ups unless they still indicate the patch should not merge.
Do not fix the code unless the user asks after the review.
Tag, publish to PyPI, and create GitHub release for Kon with validation and rollback-safe steps
Create or update AGENTS.md for this repository
E2E testing of kon using tmux sessions; IMPORTANT: only trigger this skill when user asks for e2e testing of kon