pr-finish
Finish an open PR by batching review feedback, applying valid fixes, running verification, pushing once per batch, and monitoring CI with bounded waits. Use when the user asks to update code until PR review comments are handled, review-all has no valid blocking findings, and required checks pass.
- Installs
- 1.1K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/gjkim42/kanon-repo --skill pr-finish- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads pr-finish automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
PR Finish
Use this skill to finish a PR without turning review and CI into an unbounded
loop. Keep review-all review-only; this skill owns the triage, fix, verify,
push, and bounded CI workflow.
Rules
- Do not fix review comments one at a time.
- Fetch all current review state before editing: PR review bodies, inline review comments, issue comments, current head SHA, and check status.
- Triage every finding as
valid,already fixed,obsolete, ornot actionable. - Apply all valid P0-P2 fixes in one batch.
- Treat P3 as optional unless it violates an explicit repo convention, is very cheap and clearly useful, or the user asks to fix all nits.
- Run focused tests for touched code first, then one final repo verification pass before pushing.
- Push once per batch.
- Run
review-allonce after the batch. If valid P0-P2 findings remain, do at most one more fix batch unless the user explicitly asks to continue. - Do not rerun
review-allafter each individual fix. - If only long e2e jobs remain pending after 10 minutes, report status and stop unless the user explicitly asked to wait for them.
Procedure
1. Resolve PR Context
Find the PR for the current branch:
gh pr view --json number,url,title,headRefOid,reviewDecision,statusCheckRollup
If the branch has no PR, ask for the PR number.
2. Fetch Review State
Fetch summary reviews, issue comments, and checks:
gh pr view <pr> --json url,title,headRefOid,reviewDecision,latestReviews,reviews,comments,statusCheckRollup
Fetch inline review comments:
gh api repos/<owner>/<repo>/pulls/<pr>/comments --paginate
Use gh for GitHub operations. If an API call fails because of sandboxed
network access, rerun the same command with the required approval.
3. Triage Before Editing
Create a concise triage table before making changes:
| Source | File:Line | Priority | Finding | Status | Action |
|---|
Classification:
valid: Still applies to currentHEADand should be fixed.already fixed: The code/docs/tests already address it.obsolete: The comment points at an old commit or moved code and no longer applies.not actionable: The finding is wrong, speculative, or asks for behavior outside the requested scope.
Only edit after the table is complete.
4. Fix In One Batch
Apply all valid P0-P2 fixes together. Keep edits narrow and aligned with the repo's conventions. For P3, fix only when it is convention-backed or clearly worth the small cost.
5. Verify
Run focused checks for touched code first. Examples:
go test ./internal/cli
go test ./internal/controller
Then run the repo's standard verification targets:
make test
make verify
Run broader targets such as make test-integration only when the touched code
or review findings justify it.
6. Commit And Push
Check the diff and status:
git status --short
git diff --stat
git diff --check
Commit with a scoped message and push once for the batch.
7. Run Review-All Once
After the push, run review-all once against the committed branch diff.
If review-all reports valid P0-P2 findings, do one more batched fix cycle:
triage all findings, fix them together, verify, commit, push. Do not continue
past that second cycle without explicit user confirmation.
If only P3 findings remain, report them as optional unless they violate a stated repo rule.
8. Monitor CI With Bounds
Check status:
gh pr checks <pr>
If a check fails, inspect that job and fix the failure. If checks are passing or only long e2e jobs remain pending, use this policy:
- Wait up to 10 minutes total for pending long jobs.
- If they still run after 10 minutes, report which jobs are pending and stop.
- Continue waiting only if the user explicitly asked to wait for all checks.
Final Report
Keep the final response short:
- review findings fixed or triaged
- commits pushed
- local checks run
- PR check status
- any remaining pending long jobs or optional P3 items
FAQ
What does the pr-finish skill do?
Finish an open PR by batching review feedback, applying valid fixes, running verification, pushing once per batch, and monitoring CI with bounded waits. Use when the user asks to update code until PR review comments are handled, review-all has no valid blocking findings, and required checks pass.
How do I install pr-finish?
Run npx skills add https://github.com/gjkim42/kanon-repo --skill pr-finish in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/pr-finish/ (personal) or .claude/skills/pr-finish/ (project).
Which AI agents can use pr-finish?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is pr-finish safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains pr-finish?
It is published by gjkim42 in gjkim42/kanon-repo. It has 1,148 recorded installs.
More from gjkim42/kanon-repo
review-all
gjkim42/kanon-repo
Run a two-agent code review: spawn two fresh, clean-context agents that examine the SAME committed branch diff in parallel. One agent runs Codex's native codex review --base command, while the other independently reviews the code against Google's "What to look for in a code review" guidance. Merge both outputs into one agreement-ranked report. Use this whenever the user asks for "review-all", a second-opinion review, a dual review, a cross-check before a PR, or a maximum-confidence review of committed branch changes. Do not use it to APPLY fixes; it is review-only.
api-review
gjkim42/kanon-repo
Review the current Kelos branch, or an explicitly specified PR, issue, or diff, for Kubernetes API and CRD design quality. Use when asked for a Kelos API review, CRD/API compatibility review, Kubernetes API convention review, or review of changes under api/, generated CRDs, examples/, or self-development/ manifests. Default to the current branch when no target is specified. This skill is review-only.
gjkim-instruction
gjkim42/kanon-repo
Create and maintain gjkiminstruction.md, the root document for a loop-engineering effort. The document holds only the minimum requirements and confirmed decisions, and deliberately leaves everything else open so that later iterations are not locked into early guesses. Use whenever the user mentions gjkiminstruction.md, a root document or root doc for a loop, loop engineering, starting a long-running agent loop on a goal, or asks to record a requirement or a confirmed decision for such an effort. Also use at the start of a loop iteration to check what is already decided versus still open.
design-cleanup
gjkim42/kanon-repo
Sweep the current branch for leftovers of an abandoned design after a significant mid-work decision change, and rewrite the affected code, comments, tests, and docs so the result reads as if it had been designed this way from the beginning. Use when the user says "design cleanup", "clean up the old approach", "erase the journey", says a design decision changed and asks to clean up after it, or after a pivot in approach mid-branch. This is a rewrite pass over the code touched by the decision only — not a general refactoring or bug-hunting pass.
pre-session-end
gjkim42/kanon-repo
Use this skill PROACTIVELY when the user indicates they are done working, ending the session, wrapping up, or saying goodbye. Also use when significant work has been completed and the user hasn't explicitly asked to continue. Analyzes the session to evolve skills/commands/agents and propagates useful project permissions to global settings.
address-pr-review
gjkim42/kanon-repo
Review the comments on a PR and address the findings that are valid and required. Use when the user says "address-pr-review", asks to address the PR review, handle or apply the review comments or review feedback on a PR, or fix what the reviewers asked for. Defaults to the PR for the current branch when none is named. This skill changes code; it is not a review pass.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.