triaging-pull-requests

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:

1. Ready to Merge — Approved, CI passing, no merge conflicts
2. Needs Review — The current user is a requested reviewer
3. Needs Author Action — Changes requested, CI failing, or merge conflicts
4. 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.