PR Finish
Use this skill to finish a PR without turning review and CI into an unbounded
loop. Keep
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 , , , or .
- 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 once 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 after 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:
bash
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:
bash
gh pr view <pr> --json url,title,headRefOid,reviewDecision,latestReviews,reviews,comments,statusCheckRollup
Fetch inline review comments:
bash
gh api repos/<owner>/<repo>/pulls/<pr>/comments --paginate
Use
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:
- : Still applies to current and should be fixed.
- : The code/docs/tests already address it.
- : The comment points at an old commit or moved code and no longer
applies.
- : 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:
bash
go test ./internal/cli
go test ./internal/controller
Then run the repo's standard verification targets:
Run broader targets such as
only when the touched code
or review findings justify it.
6. Commit And Push
Check the diff and status:
bash
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
once against the committed branch diff.
If
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:
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