github-triage
Triages a repository's open GitHub issues and pull requests via the gh CLI. Optionally reviews and merges ready PRs — incrementally merging passing automated/bot PRs and maintainer-approved ones, and spawning review subagents for never-reviewed ones — then closes already-resolved issues with comments citing the resolving PR or commit, cross-links issues with their pending fix PRs, and assigns local-only priority and change-size estimates for everything outstanding. Use when triaging, grooming, or reviewing a repository's open issues and PRs.
npx skills add trailofbits/skills --skill github-triage --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Triage a repository's open GitHub issues and pull requests. It can merge ready PRs (bot or maintainer-approved) incrementally, spawn review subagents for never-reviewed PRs, close resolved issues with a citation to the resolving PR or commit, cross-link issues with their pending fix PRs, and assign local-only priority and change-size estimates for outstanding items. The triage is invoked explicitly by the user to groom or review open issues and PRs.
How it works
- Phase 0: Determine the target repository using gh auth status, git rev-parse, and git remote -v, then set REPO="OWNER/REPO" and pass -R "$REPO" to gh calls. Validate REPO against a pattern before use.
- Phase 1: Gather issues and context with gh issue list and gh pr list to collect open issues, open PRs, and recently merged PRs. Use closingIssuesReferences to identify linked items. Determine default branch and search commits for closing keywords to corroborate resolution.
- Phase 2: Triage open PRs (optional). Classify each PR as Ready to merge, Bot PR, Maintainer-approved, Never reviewed, or Needs work based on fields like mergeable, mergeStateStatus, statusCheckRollup, author, latestReviews, and review decisions. Present categorized PRs and actions via AskUserQuestion. For incremental merges, verify ready state immediately before each merge and perform merges one at a time in oldest-first order, using gh pr merge <N> with a chosen method and ensuring MERGED state after each.
- Phase 2 continued: For Never-reviewed PRs, spawn a per-PR Agent subagent that reviews the diff and writes a file github-pr-<number>-review.md in the working directory with the review content (read-only, not posted).
- After merges, re-fetch merged PR list to refresh Phase 1 data.
- Phase 3: Classify open issues into buckets A (Already resolved with concrete evidence), B (Pending PR would resolve it with cross-references), or C (Outstanding with local-only priority/size). For Bucket B, add non-destructive pointers or rely on existing references; avoid editing PR bodies unless user requests auto-close. Use gh issue close or gh issue comment as appropriate if the user opts in.
- Phase 4: Score outstanding issues locally by assigning Priority (Critical/High/Medium/Low) and Change size (size/XS through size/XXL) based on impact, reach, signal, urgency, and estimated changed lines. Open implicated files with Grep/Read to base estimates when possible; otherwise use unsized — needs investigation if insufficient information.
- GATE 1: Present the full triage for review, ensuring all local-only information is clearly separated.
# 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
- When to Use
- When NOT to Use
- Core Principles
- Workflow
- Phase 0: Select the target repository
- Phase 1: Gather issues and context
- Phase 2: Triage open pull requests (optional)
- Phase 3: Classify each open issue
- Phase 4: Score outstanding issues (LOCAL ONLY)
- GATE 1: Present the full triage for review
- Phase 5: Execute approved issue writes
- Phase 6: Deliver the outstanding triage
- Safety Rules
- Rationalizations to Reject
gh auth status # confirm gh is authenticated git rev-parse --is-inside-work-tree # is PWD a git repository? git remote -v # enumerate remotes Open issues (gh issue list excludes PRs by default) gh issue list -R "$REPO" --state open --limit 1000 \ Open PRs — candidates for "pending fix" (issue phase) and PR triage (Phase 2) gh pr list -R "$REPO" --state open --limit 1000 \ Recently merged PRs — candidates for "already resolved" gh pr list -R "$REPO" --state merged --limit 300 \ Anchor the issue number so #12 does not match #120, #123, …
What does the github-triage skill do?
Triages a repository's open GitHub issues and pull requests via the gh CLI. Optionally reviews and merges ready PRs — incrementally merging passing automated/bot PRs and maintainer-approved ones, and spawning review subagents for never-reviewed ones — then closes already-resolved issues with comments citing the resolving PR or commit, cross-links issues with their pending fix PRs, and assigns local-only priority and change-size estimates for everything outstanding. Use when triaging, grooming, or reviewing a repository's open issues and PRs.
How do I install it?
Run `npx skills add trailofbits/skills --skill github-triage --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From trailofbits/skills, a repository with 6,426 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.