| name | triaging-pull-requests |
| description | Triage open pull requests into actionable categories. |
Workflow
Step 1: List open pull requests
List open pull requests by running gh pr list.
Step 2: Categorize pull requests
Read the contents of pull requests using gh pr view.
For any pull request that needs deeper status, review, comment, or CI context, use the investigating-pull-request skill.
Categorize each pull request into one of the following buckets:
- Ready to merge
- Needs review
- PR validation failing
- Needs follow-up
- Draft
Step 3: Investigate failures
For failing pull requests, use the investigating-pull-request skill to gather their full context and check their CI status.
For pull requests with CI failures, use the investigating-pipeline skill with the failing build ID to read task logs and identify root causes.
Step 4: Correlate failures with recent pull requests and issues
To check recent issues, run gh issue list --state all.
To check recently merged pull requests, run gh pr list --state merged.
Look for:
- A recent change that obviously caused the failure
- An existing known issue tracking this failure
- An open pull request that already addresses the failure
Step 5: Categorize and present results
Using everything you've learned, place each pull request into one of these
categories in this priority order:
- Ready to Merge — Approved, CI passing, no merge conflicts
- Needs Review — The current user is a requested reviewer
- Needs Author Action — Changes requested, CI failing, or merge conflicts
- Stale — No updates in 7+ days and not ready to merge
Use your judgment when things are ambiguous. For example:
- A pull request with only flaky-test failures might still be ready to merge
- A draft pull request from the user that hasn't been touched in weeks is stale even if CI is green
For "Needs Author Action" pull requests with CI failures, include the root cause diagnosis.
End with a recommended next action.