PR Triage

PR Triage

Maintainer triage. Three real outcomes: approve, supersede (salvage + credit + close the old one), or close (wrong premise). Verdict first; wait for an explicit go before forge writes (approve / supersede / close / merge / push). Use gh or glab.

Explicit review scope

Treat the user's stated outcome set as overriding the default taxonomy below. If they request approve or request changes only, review each MR on that basis: report concrete blockers as request changes, and do not consolidate, supersede, close, or implement a replacement. Keep the verdict-first / explicit-go boundary for forge writes.

Kickoff

Batch ("we will be reviewing…") or a pasted Discord/>>>…<<< thread with a PR:

1. Figure out repo + forge. Skim AGENTS.md / CONTRIBUTING.md if present.
2. Match this repo's worktree/branch naming by inspecting existing worktrees.
3. Don't touch the primary checkout — use worktrees.
4. Cluster the batch first (below), then verdict + salvage plan; wait for go before forge writes.

Cluster the batch first (before per-PR verdicts)

More than one PR/issue in front of you? Group them by the fix they need before you judge any single one. Multiple PRs on the same bug (or fragile subsystem) are one consolidation, not N salvages.

1. Map each PR/issue to the underlying fix and the files/subsystem it touches.
2. Any two that fix the same bug class or the same subsystem → treat the group as one super-PR: build the proper fix once, credit every author (Co-authored-by + @handle), and supersede the whole cluster.
3. Default to consolidation. Only keep PRs separate when the fixes are genuinely independent (different bug class, different area, no shared code).
4. State the grouping up front, e.g. #68665 + #63590 + #67603 → one super-PR, then run the per-PR loop within each group to confirm premises.

Do not enumerate one verdict per PR when they share a fix — that's the lazy shape. One cluster → one consolidated supersede.

Discord threads

A pasted thread is the intake. Don't make them restate a bare URL.

A support handoff with an owner/maintainer column is a shared board, not her queue. Take only rows whose owner names her (alone or shared); list the rest as "not yours" with no forge writes, even when the ask is a broad "help these out". Approving, merging, salvaging or closing another maintainer's cluster is overreach she has to walk back.

1. Pull out symptom, platform, linked PR/issue, what staff already said.
2. Open those PRs; look for siblings on the same fix.
3. Run the per-PR loop. Check the PR actually matches the reported bug.
4. Draft a user reply only if useful — still wait for go before GH actions.
5. No PR? Search open ones; if they want a new fix, follow that repository's worktree workflow.

Issue-only closure audits

• Follow the user's issue verdict taxonomy rather than applying PR supersede outcomes. A reachable fix commit is a lead, not proof that the entire issue is solved; read later comments and test the present implementation.
• Honor explicitly assigned issue numbers even when their PR references appear only in comments; timeline-based batches do not implicitly own them. Only exclude merged-reference issues when the assignment expressly says to. Inspect references in the body and comments as well as timeline cross-references, resolve object and merge state live, and record actual exclusions as skipped rather than solved. A historical, partial, or unrelated merged reference is not resolution evidence.
• Preserve the reviewed base SHA in machine-readable results. Separate closure candidates, substantively unresolved issues, and skipped ownership cases in totals; inherit labels on skips only with an explicit unassessed qualifier.
• Distinguish external-repository merges from upstream implementation. Check the referenced repository and git merge-base --is-ancestor <merge> <reviewed-base>; exit 128 for an unavailable commit is missing ancestry evidence, never proof of inclusion or exclusion. For oversized PR diffs, recover the issue-relevant patches with paginated gh api repos/<owner>/<repo>/pulls/<number>/files --paginate --slurp rather than trusting a truncated file list.
• Re-enumerate a range-limited catalog independently before writing verdicts, using the exact source/subject merge predicate requested. Assert selected IDs equal reviewed IDs, not just equal counts, and retain later human reports and unresolved acceptance requirements even when a sibling fix merged.
• For merged-reference issue batches, derive and count the exact selection from both timeline source and subject objects. Preserve external-repository references: a merged fork/plugin PR is not upstream coverage, and merge-base exit 128 means an unavailable object, not a proven non-ancestor.
• Read reopen events and post-fix reports before proposing closure. GitHub can auto-close from a negated phrase such as “does not fix #N”; a test-only or sibling PR linked that way is not a production fix.
• For merged-reference issue audits, check the PR's base branch and git merge-base --is-ancestor <merge-sha> <reviewed-main-sha> before treating it as landed. Stacked fixes can be marked MERGED into an unlanded feature branch; absent feature code on main is not proof that a pre-merge bug report is resolved. Conversely, inspect current code and its history for later fixes outside the issue timeline so an unrelated reference does not hide an actual resolution.
• When the desktop Vitest workspace cannot load a missing build plugin, do not install dependencies during a read-only audit. A scratch standalone config can run source-level suites with the app's aliases, React/ReactDOM package resolution and existing setup file, without extending its Vite build config. Label this as alternate-config testing, not packaged Electron verification. Scratch hook probes must execute actual imports, never regex-match source.

Issue audits with merged cross-references

For recommendation-only audits, preserve that boundary: no forge writes, even when a related PR is merged.

• Enumerate the full requested issue set programmatically from structured source/subject references; save the input IDs and assert the final reviewed IDs match exactly.
• Read issue bodies, all comments, and timeline events before treating a merged PR as resolution. Flag reopens and distinguish post-merge reproductions from comments predating the fix.
• Verify each merge commit is an ancestor of the exact reviewed main SHA, then inspect the current code. A related PR, stale closure trailer, or mitigation is not full acceptance evidence.
• Separate every reported requirement and later variant. Recommend closure only when all are addressed with high confidence; otherwise name the concrete residual or unverified acceptance case without claiming it still reproduces.
• Record test commands and actual results, including startup blockers and alternate test configuration. Unit recovery tests do not prove native-app geometry, update-time permissions, or cross-profile end-to-end isolation.
• Draft closures with complete PR/source URLs and say fixed on main, not released, unless the release artifact was separately verified.

Forge cheatsheet

git fetch origin pull/<N>/head:refs/remotes/origin/pr-<N>   # GitHub
# GitLab: glab mr checkout <N>

Per-PR loop

Run this within each cluster (see "Cluster the batch first"). If the group consolidates, the salvage plan is shared and you supersede all of them into one super-PR — don't emit a standalone salvage per member.

1. Metadata + diff + existing reviews (gh / glab).
2. Unaddressed #1 / lead maintainer comments → do not approve.
3. Check the premise on current default branch (usually main).
4. Cherry-pick/apply in a review worktree; run targeted tests this repo uses.
5. Return a verdict:

**PR/MR:** [#N](https://…/pull/N)

**Verdict: approve | supersede | close-as-wrong-premise**

**Worktree:** `…` · `<branch>`

### Why
- …

### Checks
| Check | Result |
|---|---|
| Merges onto default branch | … |
| CI | … |
| Targeted tests | … |

### Next (after go)
- approve: …
- supersede: salvage plan (reuse X, drop Y, tests Z, credit @handle)
- close: wrong-premise comment outline

Pick the verdict (no soft exits)

Anti-patterns — do not do these:

• keep open — ask the author to rewrite / reuse helper X / add coverage when the shape is already wrong → that is supersede. You salvage it.
• Inventing a fourth outcome (request-changes, needs-info, wait-and-see) for external PRs that need reshaping.
• Emitting one verdict per PR when several fix the same bug/subsystem → that's one consolidated super-PR that supersedes the cluster, credit all authors.
• Parking on someone else's confirmation when the PR's shape is already a supersede (wrong helper, wrong layer, no bug-class tests). Note the open question under Why if useful; still verdict supersede with the salvage plan. Only block the verdict when you literally cannot tell whether the reported bug is this codepath vs something else — and even then say what evidence would flip it, don't default to "ask the author."

request-changes is not a triage verdict. It is only for trusted / internal authors with a single tiny nit under Approve — never for "please rebuild this correctly."

Trusted / internal authors

Infer from organization membership, team roles, prior maintainer behavior, or the user explicitly identifying someone as a lead/internal contributor. If a pr-triage-<repo> overlay skill exists for this repo, load it for the roster and worktree layout.

When to supersede

• Contaminated / wrong close keywords
• Stale conflicts, author not fixing
• Duplicates a helper / wrong layer / wrong issue
• Missing tests for the bug class while the idea is right
• Same bug across 2+ PRs → one shared fix
• Lead feedback ignored and the idea is still right

Not enough alone: taste nits, optional follow-ups, "could be prettier."