Triage PRs

Overview

Produce a maintainer's action queue for the open pull requests, not a review of each one. Classify from GitHub signals and PR bodies, then delegate deep code review of individual PRs to the review-pr skill when the user selects them.

Workflow

1. Resolve scope and write permissions.

   • Default to a read-only report. Labels, comments, review requests, closing, readiness changes, and project fields are writes and need an explicit user request. "Tag bug fixes with bug" or "label feature PRs" is such a request.
   • Confirm the repository with gh repo view --json nameWithOwner. Do not switch branches or fetch PR heads; triage never needs a checkout.
   • Restrict to a subset (author, label, path, PR list) when the user names one.

2. Collect signals.

   • Run scripts/pr_inventory.sh from this skill directory. It prints one JSON object per open PR with CI, mergeability, review, stack, template, and closing-issue signals. Field meanings are in references/triage-signals.md.
   • Re-query PRs whose mergeable is UNKNOWN after a short wait. GitHub computes mergeability lazily.
   • For PRs whose bucket depends on review content, read the latest maintainer comment or review with gh pr view N --comments. Findings in this repository are often plain comments with [P0] to [P3] prefixes.
   • Read the Problem section of each PR body. Do not read diffs except to resolve a classification question, such as whether a change is a bug fix or a refactor.

3. Classify.

   • Assign exactly one bucket per PR using the precedence in references/triage-signals.md: blocked, needs-author, draft, stale, ready-to-merge, needs-review.
   • Record the concrete blocker: failing check names, conflict, unanswered findings, missing template section, open predecessor PR.
   • Decide who acts next. Trust waiting_on unless the latest comment shows otherwise.

4. Run the cross-PR checks: overlapping files between open PRs, shared commits, stacks that are claimed in the body but based on trunk, split series and their order, superseded work, and large PRs with no review.

5. Estimate review effort per PR from the logical change, not the diff size. Use size, large_files, and bulk_lines from the inventory and the rules in the reference. A mechanical rename, a regenerated schema, a recorded fixture, or a vendored source tree inflates the diff without adding review work; say so in the report.

6. Apply requested writes.

   • Labeling: follow the label rules in the reference. Ground bug in the PR's Problem section or a closing issue labeled bug; ground enhancement in a Solution that adds capability or a surface, and refactor in a stated absence of behavior change. Skip borderline cases and list them for the user.
   • Before any comment, close, or review request, restate exactly which PRs are affected. Never close or mark ready without a per-PR instruction.
   • Re-read each edited PR with gh pr view N --json labels and report the result.

7. Report using the template in the reference. Lead with the maintainer's ordered actions, then the queue table, cross-PR notes, and writes made. End with the recommended review sequence: small targeted PRs first, then old PRs that need a close or follow-up decision, then stacks bottom-up, then larger work ordered by what it unblocks, with drafts and blocked PRs as a watch list. State anything not verified after the sequence.

Boundaries

• Triage judges readiness and ownership, not code quality. Say "needs review" rather than guessing whether the code is correct.
• Do not count passing checks as evidence of correctness; the queue tells the maintainer where to spend review time.
• Report unverified state (transient UNKNOWN mergeability, missing token scopes for the project board, CI that has not run) instead of filling it in.
• Do not expose credentials, private logs, or sensitive paths.