pr-triage

Files (2)

• SKILL.md
• reference.md

SKILL.md (first lines)

# 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

| Action | GitHub | GitLab |
|--------|--------|--------|
| View | `gh pr view <N>` | `glab mr view <N>` |
| Diff | `gh pr diff <N>` | `glab mr diff <N>` |
| Comment | `gh pr comment <N>` | `glab mr note <N>` |
| Review | `gh pr review <N> --approve \| --request-changes` | `glab mr approve` / note |
| Close PR/MR | `gh pr close <N>` | `glab mr close <N>` |
| Close issue | `gh issue close <N>` | `glab issue close <N>` |

```bash
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:

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

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

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

### Why
- …

### Checks
| Check | Result |
|---|---|

From OutThisLife/brooklyn-skills, MIT.

More from OutThisLife/brooklyn-skills