--- name: pr-finalize description: > Drives a single GitHub PR from "open with loose ends" to genuinely ready-to-merge: rebases off the base branch and resolves conflicts, sweeps every review bot (Qodo, CodeRabbit, Greptile) plus human comments to zero unaddressed findings, verifies that unit AND browser/E2E coverage was actually added for the change, runs the repo's real lint/format/test gates before pushing, and reports what still needs a human. Use when the user gives a PR URL or number and says "finalize this PR", "fix all outstanding comments", "address the review feedback and push", "get this PR merge-ready", or asks to clear what Qodo/CodeRabbit/Greptile could still comment on. compatibility: Requires git and gh (GitHub CLI) authenticated. Review-bot sweeps only cover bots actually installed on the repo. metadata: version: "1.0" allowed-tools: Bash(gh:*) Bash(git:*) --- # PR Finalize One PR, taken all the way to merge-ready. The job is not "make the bots stop talking": it is **land the change in a state a careful reviewer would sign off on**, with evidence for every claim. ## Inputs - **PR number or URL** (optional): detect from the current branch if not given. - `--no-push` (optional): do everything except the final push. Use when the repo auto-merges and the user wants to eyeball first. ## Non-negotiables These are the failure modes this skill exists to prevent. Violating one makes the whole run worthless: - **Never report a gate as passing without having run it.** Paste the real output. "Tests should pass" is not a result. - **Never resolve or claim-fix a finding you didn't actually fix.** Blocked is an honest outcome; a false "done" is not. - **Never `git add -A`.** Stage only the files your fixes touched. Start from a clean tree so that's safe. - **Never invent test coverage.** If the change has no browser-reachable surface, say so explicitly and name the suite that *is* the real gate. Do not add a hollow E2E test to look thorough. - **A green CI badge is not proof.** Many repos split their required check from the full suite (browser-free half only, etc.). Find out what the required check actually runs. ## Instructions ### 1. Establish the ground truth ```bash gh pr view --json number,title,body,state,isDraft,headRefName,baseRefName,mergeable,mergeStateStatus,labels,reviewDecision,statusCheckRollup,url ``` Record four things before touching code: - **`mergeable`**: `CONFLICTING` means step 2 is mandatory. - **Which checks are failing**, and for each, whether it is *required*. Check branch protection (`gh api repos/{owner}/{repo}/branches//protection`) rather than assuming: a red optional job (a flaky bot-review runner, a nightly) is not a blocker, and burning the run waiting on one is a classic waste. - **Whether the repo auto-merges.** Look for a shepherd/automerge workflow in `.github/workflows/` and read its *gating conditions* (required labels, required checks). If pushing could trigger an immediate merge, decide deliberately: either satisfy the review sweep first, or tell the user before you push. Never let an auto-merge race a review you were asked to complete. - **Whether a bot review actually ran.** A `SUCCESS` status from a review bot can still mean "rate-limited, never reviewed": read its comment body, not just the check state. ### 2. Rebase onto the base branch Require a clean tree first (`git status --porcelain` empty), then: ```bash git fetch origin git rebase origin/ ``` Resolve conflicts by **understanding both sides**, not by picking one. Read the base-side commit that introduced the conflicting hunk (`git log -1 --format=%s -- `, then the diff): a conflict usually means main changed an invariant your branch is unaware of, and blindly keeping "your" side silently reverts it. State in the PR comment which invariant you preserved and why. After resolving, re-run the tests before continuing: a rebase that compiles is not a rebase that works. ### 3. Sweep every review source Collect findings from all of these; do not stop at the first: ```bash # inline review threads (all bots + humans), with resolution state gh api repos/{owner}/{repo}/pulls//comments --paginate # rollup issue comments (where CodeRabbit/Qodo post summaries and rate-limit notices) gh api repos/{owner}/{repo}/issues//comments --paginate # formal reviews gh pr view --json reviews ``` **Delegate to the dedicated loop skill when one exists** rather than reimplementing its bot's protocol: `qodoloop` for Qodo, `coderabbitloop` for CodeRabbit, `greploop` for Greptile. Each already encodes that bot's posting shape, its ready-made per-finding fix prompt, and its real terminal states. Use this skill's own sweep for human comments and for bots without a dedicated loop. Triage every finding into exactly one bucket: | Bucket | Action | |---|---| | **Real defect** | Fix it. This is the point of the exercise. | | **Legitimate improvement** | Fix it if it's in scope for this PR. | | **False positive** | Reply explaining *specifically* why the bot is wrong. Do not resolve silently. | | **Needs a human call** | Reply, leave open, surface in the final report. | Bot findings are suggestions from something that has not run the code. A "🐞 Bug" label is a hypothesis: verify it against the actual source before fixing, and against the actual behavior before dismissing. ### 4. Close the coverage gap Ask, for the change as a whole, what would catch a regression here: then check whether the PR actually has it. - **Unit / integration tests:** does every new branch have a test that fails if you invert it? Bots frequently and correctly flag helper functions exercised only *indirectly* through a caller. A direct test per branch is cheap and is usually the right response. - **Browser / E2E tests:** determine whether the repo supports them (`playwright.config.*`, `cypress.config.*`, a `test:e2e` script) **and** whether this change has any surface they can reach. Then do one of exactly two things: - it has a reachable surface → add or extend the E2E spec; - it does not → **say so explicitly in the PR comment**, name why (e.g. "this is entirely inside a Durable Object alarm loop; the E2E harness only serves static assets"), and name the suite that is the real gate. Silence here reads as an oversight. An explicit "not applicable, because X" reads as diligence, and is checkable. ### 5. Run the real gates Discover them from the repo (`Makefile`, `package.json` scripts, CI workflow): do not guess target names. Run, at minimum, the equivalents of: ```bash # e.g. make lint / npm run lint # check mode first; only write if it reports drift # the suite covering the changed package ``` Capture exit codes, not just output. Repo-specific traps worth checking for before you burn a cycle: linters whose cache replays findings from deleted sibling worktrees, formatters whose local toolchain version outruns CI's (churning unrelated files), and test runners that hang when two runs overlap. If a gate fails, fix it. Do not push red. ### 6. Push and explain Stage only the files you touched, commit, and push (`--force-with-lease` after a rebase, never bare `--force`). Then post **one** PR comment that a reviewer can audit without re-reading the diff: - what the rebase conflict was and which side won, with the reason; - each finding, and what you did about it (including the ones you rejected, with the argument); - the coverage decision from step 4, including the explicit not-applicable if that's the answer; - **verbatim** gate output: real numbers (`# pass 480 / # fail 0`, `0 issues.`), not adjectives. Re-trigger any bot that never actually reviewed (e.g. `@coderabbitai review`) so the PR gets the pass it was owed. ### 7. Verify and report Re-read the PR state after the push: confirm `mergeable` flipped, checks went green, and clear now-stale labels (`needs-rebase`, etc.). Poll re-triggered bots for their new pass and handle anything it raises. ```text PR #965 finalized. Rebase: 1 conflict resolved (kept main's #834 D1-first ordering) Findings: 2 addressed, 0 rejected, 0 blocked Coverage: +5 unit tests; E2E not applicable (no browser surface), stated on the PR Gates: tests 480/480, lint 0 issues, format clean State: MERGEABLE, checks green Needs human: none ``` If anything is left, say precisely what and why: an honest "blocked on X" is the deliverable when X is genuinely a human call. ## Related skills - `qodoloop`: full Qodo thread protocol (per-finding Agent Prompts, resolve mutations). - `coderabbitloop`: full CodeRabbit protocol. - `greploop`: drives a PR to a 5/5 Greptile confidence score. - `ci-fix-loop`: when the blocker is a failing pipeline rather than review feedback.