| name | issue-triage |
| description | List the open GitHub issues on a repository and put them in the order they should be worked on, with a one-line reason each. Use when the user says "issueの優先度をつけて", "どれから着手すべき", "open な issue を一覧して", "what should I work on next", "triage the issues", or asks which of several issues to start with. |
issue-triage
Turn a list of open issues into an order of work, with a reason attached to each
position. The deliverable is a decision aid, not an inventory: anyone can run
gh issue list.
The failure mode is a table where everything is important. If three issues are
"high", the ranking has told the reader nothing they did not already know.
Ordering means committing — something has to be last.
Steps
-
Fetch what is open.
gh issue list --state open --limit 50 \
--json number,title,labels,createdAt,updatedAt,body
Or the GitHub MCP tools where gh is not available. If nothing is open, say
so and stop; do not pad the list with ideas of your own.
-
Read each one only as far as ranking requires. For every issue, answer:
- Does it carry a reproduction, or would work start with "make it happen
first"?
- Is it one PR, or is it a discussion wearing an issue's clothes?
- Is anything else waiting on it?
- Is it stuck on a decision only the user can make? Those are not
implementable work and must not be ranked among it.
On a repository with dozens of issues, read the plausible top ten properly
and say which ones you skimmed. A ranking of ten you understood beats a
ranking of fifty you did not.
-
Check the top candidates still reproduce. Issues go stale — the bug gets
fixed in passing, the file moves, the dependency changes. If the issue names
a command, run it. Anything that no longer reproduces goes in the
close-candidates list, and you do not close it — that is the user's call
and they may know why it is still open.
-
Rank. In descending weight:
| Axis | What to look at |
|---|
| Kind of wrong | silently produces a wrong result > noisy but visible > cosmetic |
| Frequency | shell startup, hooks, CI — paths that run constantly — versus a rarely-taken branch |
| Blocking | is other work or another issue waiting on it |
| Cost | a few lines, or a design decision |
| Freshness | does it still reproduce at all |
A cheap fix on a hot path outranks an expensive fix on a cold one, even when
the expensive one is more interesting.
-
Report in four parts, and keep it to one screen:
- Work order — numbered, with issue number, title, and one line saying
why here. Not a summary of the issue: the reason for the position.
- Quick wins — the ones that close in a few lines. Say which could
sensibly share a single PR.
- Needs a decision — one sentence each on what to decide, phrased as a
question. These block on the user, not on effort.
- Close candidates — no longer reproduce, with what you ran to find out.
What makes a good reason line
Say what moves it up or down, not what the issue is about.
- Good: "every shell start on Linux; two lines to fix"
- Good: "blocks 312 — the test it needs does not exist yet"
- Bad: "important bug in the shell config" (that is a summary, and a grade)
- Bad: "high priority" (a label is not a reason)
If two issues genuinely tie, say so and pick one anyway, on cost.
Do not
- Pad the ranking. Not everything is urgent; something is last.
- Close, label, comment on, or edit issues. Read-only unless asked.
- File new issues — that is
repo-survey's job. Something you notice while
triaging gets mentioned in chat, not filed mid-task.
- Start the work. Ranking is the deliverable; the user picks what to begin.
- Rank an issue you did not read.
- Treat an issue's claims as fact when checking is cheap. A body written months
ago describes the repository as it was.
Constraints
- Every repository ranks differently. A dotfiles repo weighs "runs on every
shell start" heavily; a library weighs "breaks a public API" heavily. Take the
weighting from what the project is, and say which weighting you used when it
is not obvious.
- Say when the list is thin or the issues are all small. "Three small ones, any
order, here is the cheapest first" is a legitimate result.
