Cherry-pick the value from every PR (never merge dirty)

PR reviewFreshClaudeverified 2026-06-21sha 76711bdb6947

Born in: the post where it earned its place →

Vendor “review my PRs” prompts optimise for a verdict per PR; this one optimises for VALUE EXTRACTED and a cleaner repo, and it forces the ruling to be DONE before the table row exists. The unlock is three honest, executed rulings – integrate the best parts on a green branch, capture the lesson before any close, or close with a real reason – behind a pre-flight safety gate, so nothing useful is lost, nothing dirty is merged, and the queue does not just get a tidy-looking summary.

You are reviewing open pull requests against the current codebase. The goal is NOT to merge them as-is and NOT to close them to clear the queue. It is to EXTRACT the value from each PR and leave the project cleaner and higher-quality than you found it. A lazy "merge or close" pass is a failure of this task.

PRs / branches to review:
{{prs_or_branches}}

What main currently does + the quality bar:
{{repo_context}}

Before you touch anything: confirm main is current (fetched and up to date), the working tree is clean, and you have a restore point (a branch or a known-good commit). Capture the starting branch and HEAD SHA with a live command (e.g. git rev-parse HEAD) and record it, so a red validate after a cherry-pick can be reverted to THAT recorded SHA without disturbing earlier-landed keepers. If any of those is false, STOP and report what must be fixed first - do not change files or close PRs from a dirty or stale base. Process at most 5 PRs this pass (fewer if any integration is large); defer the rest with a one-line reason each - no skim-rulings. Finish one PR completely - integrated-and-green, captured, or closed - before you start the next.

For EACH pull request, in order:

1. ASSESS against main. Read BOTH the current code on main AND the PR's diff - you cannot rule on a PR you only skimmed. Check whether its change already landed on main (in whole or part) and what its CI / review state is. State concretely what it brings: useful logic, an implementation pattern, a bug fix, a reusable asset, or only a lesson / failed experiment. Be specific: "adds retry-with-backoff to the upload path" not "improves uploads".

2. RULE - exactly one:
   - INTEGRATE: it has valuable parts. Do NOT merge, squash, or fast-forward the PR. On a fresh branch off current main, port the SMALLEST coherent set of its ideas, ADAPTED to main's conventions, not pasted. Name exactly which hunks/ideas you took, which you dropped, and why. Run the project's build and tests. If they fail, either fix it cleanly now or REVERT this PR's changes and re-rule it CAPTURE or CLOSE - never carry broken work forward and never merge red. Only after green: land it and record the commit/PR reference in your table row.
   - CAPTURE: no shippable code, but a real lesson, pattern, or "this approach failed because X" worth keeping. Write it somewhere durable and grep-findable - an ADR (docs/adr/NNN-title.md), a named test whose name states the failure, or an issue/comment - tagged with the PR number and the concrete lesson. NEVER close the PR until that capture exists on disk or as a URL. Put the exact path/URL in your table row.
   - CLOSE: only after the assessment and the self-critical loss check below, and only if nothing reusable remains (superseded, wrong direction, broken beyond worth). If ANY idea is reusable, CAPTURE it first. Close it yourself with a clear, specific comment: WHY, the evidence on main that made it obsolete or wrong, and whether anything was captured (link it). No vague "closing stale PR" - the author deserves the real reason, even if the author is you last week.

3. Be self-critical at the decision, in one written line before you act. Tempted to CLOSE? Answer "what exactly would I lose, and did I capture it?" Tempted to INTEGRATE? Answer "is this actually better than main, or just different?"

Hard rules:
- Never merge a PR whole to dodge the work of extracting its good parts; never merge or push red.
- Every CLOSE has a written reason + evidence. Every CAPTURE exists on disk or as a URL before its PR is closed. Every INTEGRATE names what was taken and dropped and lands only green.
- One PR's mutations are finished and verified before the next begins - no two half-applied cherry-picks interleaved.
- Leave main coherent: no half-applied features, no dead code, no failing build, nothing re-implemented that already landed elsewhere.

End with:
- Proof per PR: ruling + evidence (commit hash / file path / close-comment URL) + your one-line self-critical answer.
- A table: PR | ruling (INTEGRATE / CAPTURE / CLOSE) | what was taken, captured, or why closed | evidence.
- Deferred PRs (if any): list + why.
- One honest line: is the codebase cleaner and higher-quality than before you started? You may say yes only with evidence - green build/tests on main, captures on disk, closes logged with reasons. If not, you are not done.

Fill in: prs_or_branches repo_context

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.