GitHub Triage

Triage a repository's open GitHub issues and pull requests. Optionally clear ready PRs first (merge passing bot PRs and maintainer-approved PRs, review never-reviewed ones), then close issues that are already resolved (with a comment citing the PR or commit that resolved them), make sure issues and the pending PRs that fix them reference each other, and assign a local-only priority and change-size estimate to every issue that is still outstanding.

When to Use

• When the user runs /github-triage to groom or review a repository's open issues and pull requests.
• When an issue backlog has drifted: resolved work left open, fixes landed without closing their issues, or PRs in flight that never linked their issue.
• When ready PRs have piled up (passing dependency bumps, approved-and-green PRs) or PRs are sitting unreviewed.

When NOT to Use

• Do not invoke automatically. This skill performs irreversible GitHub writes (merging PRs, closing issues, posting comments) and runs only on explicit invocation.
• Do not use to apply priority/effort labels on GitHub. Priority and size are presented locally only and are never posted (see Safety Rules).
• Do not use as a substitute for a human's final merge decision, every merge is proposed for explicit approval, never performed autonomously.

Core Principles

1. Writes are gated. Compute the full triage first, present every proposed write, merges included, for review, and execute nothing until the user approves.
2. Evidence before closing. Never close an issue without a concrete, cited reason (a merged PR or a commit on the default branch). When evidence is weak or ambiguous, leave the issue outstanding and flag it for review.
3. Priority and size stay local. They are an internal planning aid for the user, never written to GitHub.

Workflow

Phase 0: Select the target repository