Triage PRs

Turn an unbounded PR queue into a short list of maintainer decisions. The pipeline has three phases; no GitHub write happens in any phase without the maintainer approving that specific batch — present verdicts and drafted messages first, act on their word.

Companion: each substantive review inside phase 3 applies the pr-review skill; this skill owns only the batch mechanics around it.

The timeline outranks the snapshot. Before any verdict or comment on a PR, read its full timeline — issue comments AND reviews (gh pr view --json comments,reviews or gh api repos/{owner}/{repo}/pulls/N/reviews; a maintainer's Changes requested is a review and never appears in the comments list) AND commits since the last human event: a prior maintainer verdict (a push-back list, a recorded product decision like a placement or scope call) is BINDING — a new sweep verifies whether it was addressed at the current HEAD and says so explicitly ("all three prior items resolved" / "item 2 still open"), never re-decides it or asks the maintainer the same product question again. And never post the generic rebase-request on a PR that already carries a substantive review comment — the author already has their instructions; a bare "please rebase" on top reads as the left hand not knowing the right.

Pickup mode. A PR with human activity beyond the bot — a maintainer comment, an author reply, a trusted-reviewer thread — is a conversation in progress, not a fresh review target. Such PRs go into their own report bucket ("Розмова триває"), and each entry opens with the thread state: what the maintainer asked, what the author answered, which points are resolved at the current HEAD and which remain. The ready action continues the thread (a reply, a verdict on the author's answer, a merge if everything asked for was delivered) — it never restarts review from scratch. The maintainer may not remember their own comment from days ago; the sweep remembers for them.

Phase 1 — Mechanical sweep (no judgment, no LLM verdicts)

Fetch all open PRs with gh (the repo is openchamber/openchamber). Two measurement rules learned the hard way:

• Staleness is the last commit date on the branch, never updatedAt — bots bump updatedAt with every comment and label. Fetch last-commit dates with batched GraphQL (commits(last: 1)), ~50 PRs per query.
• gh pr list silently defaults to 30 rows — always pass --limit above the real queue size and print the resulting count.

Bucket every non-draft PR:

Then detect duplicate clusters across the survivors: pairs with high title-token overlap or high changed-file overlap. For each cluster recommend one keeper (prefer: mergeable over conflicted, references an issue, smaller diff, earlier author — a later near-identical body is likely a regenerated copy of the earlier PR, and the earlier author keeps the credit); the rest close with duplicate-close.

Deliver the sweep as one report (counts per bucket, per-bucket tables with number/title/author/size/last-commit-age/areas, clusters with keeper recommendations) and stop for approval.

Phase 2 — Approved batch actions

Execute the approved closes/comments with retries and ~1–2s spacing between calls. Log every result; report exact ok/fail counts and re-verify the open-PR total afterwards. Branch protection may reject merges — --admin is available and accepted for maintainer-approved merges; a merge that becomes conflicted mid-batch (usually CHANGELOG collisions from the batch's own merges) can be resolved in a temporary worktree and pushed to the contributor's branch when maintainerCanModify is true.

Phase 3 — Verdict reviews

Trusted community reviewers. yulia-ivashko is a core maintainer with merge rights — her review decisions carry maintainer weight (a PR she approved or merged needs no re-verdict; her open questions are the maintainer's questions). Comments and reviews from patrick-motard and mattv8 are strong human signals: during any sweep, collect the PRs/issues they weighed in on, read their assessment, and carry it into the verdict — an approval from them upgrades confidence like a passing verifier; a concern from them is a finding to verify, never to ignore. They write free-form; map their conclusion onto the verdict ladder rather than expecting the format.

The intake workflow (.github/workflows/pr-intake.yml) adds size:* (changed lines, tests/lockfiles/translations excluded) to every PR and parks size:XL/XXL PRs from non-collaborators with no Ideas discussion linked under needs-discussion. Parked PRs are waiting on author for the sweep: the report lists them in one line each and no verdict review is spent on them until a discussion link appears or the maintainer removes the label by hand (the workflow never re-adds it). Cutover: 2026-09-22. PRs opened before that date got the label from the first relabel run, with no comment and no rule in place when the author started: for them needs-discussion is size information, not a parking decision. Treat those as ordinary review pool entries (size and product fit judged by the pr-review skill as usual), and never send the author to Ideas for a PR that predates the rule. The parking applies as written only to PRs opened on or after 2026-09-22.

The review bot's review:* labels are a pre-sort, not a verdict: review:ready PRs go first (the bot found no code defects — likely MERGE/MERGE-THEN-FIX), review:blocked ones carry a bot comment whose findings the verdict review verifies rather than rediscovers. Bot labels never replace the pr-review pass — the bot cannot judge product fit or maintainability scope. The reverse holds too: when the bot's BLOCKED findings are the whole story and the author has not answered, the maintainer never re-posts them in their own voice — the PR is waiting on author and the report says so in one line.

Split the clean pool smallest-first (tiny diffs are fast wins and most likely mergeable). Fan out the review subagent (.opencode/agent/review.md, which loads the pr-review skill and carries the hard rules). It takes one PR or several per call — group related PRs together when one context can serve them, give a large or contentious PR its own call; fall back to a general subagent that receives the full pr-review skill text when review is unavailable. The subagent inherits the chat's model; never hand verdicts to a smaller model to save quota — a verdict from a small model is a pre-sort, not a decision. Each returns per-PR verdict blocks in the skill's output format.

Report format. The consolidated report is what the maintainer decides from — calibrate each entry so no follow-up question is needed, without ballooning:

• Every PR/issue reference is a clickable link: [#3177](https://github.com/openchamber/openchamber/pull/3177) (issues: /issues/N) — never a bare number.
• One entry per PR, 2–4 sentences: what it does for the user, whether the problem is real, why this verdict, the main risk or the thing the decision turns on. "Closes #N" links included.
• A "needs your hands" line appears only when the check gates the merge (per the pr-review skill), and lives INSIDE the PR's own entry as its final line — never as a separate section repeating the numbers. A plain MERGE entry carries no checklist.
• Thread-state line first for pickup-mode entries.
• A one-line entry ("точковий фікс") is fine only for genuinely trivial diffs; a verdict the maintainer must weigh (product calls, larger features) gets the full 4 sentences.

Consolidate into a single report grouped by verdict — MERGE, MERGE-THEN-FIX, PUSH-BACK (with the drafted lists), DECLINE (with the drafted close comments), plus every "needs your hands" line — and stop for approval. Each entry carries the subagent's Ready action verbatim — the comment or follow-up list exactly as it will be posted or executed, in a quote block under the entry. The consolidation summarizes the reasoning, never the artifact: a paraphrased push-back item loses the file, the cause, and the "done means" the subagent already found, and the maintainer approves what they can read, not a description of it. After approval: post/merge per verdict, and queue MERGE-THEN-FIX follow-ups as in-house work.

If a batch subagent skips a PR, notice (count outputs against inputs) and re-dispatch the gap.

A PR whose verdict needs more than a review — deep investigation of a core path, a rework against code main has rewritten, or a live check — can go to its own session with the PR linked to it. Keep it the exception: most PRs, including fix-then-merge ones, are finished inside the triage session.