| name | issue-triage |
| description | Triage a GitHub issue for rprof — classify it against project scope and the requirements, decide the next action (bug fix, new requirement, rejected direction, or question), and propose labels. Use when the user asks to triage an issue, label issues, or work through the issue backlog. |
Triage an rprof issue
Classify a GitHub issue and decide what happens to it, using rprof's own
docs as the rubric. Reading is free; confirm with the user before any
write to the public repo — posting a comment, applying labels, or
closing an issue.
Gather
- Read the issue:
gh issue view <number> --comments.
- List the repo's existing labels so you reuse them rather than invent:
gh label list.
- If it is a bug claim with a reproduction, try to reproduce it (build
and run
rprof per the repo's CLAUDE.md) before classifying.
Classify
Work the checks in this order — the cheapest filter first.
-
Out of scope? Compare against the non-goals in
docs/project-scope.md (flamegraphs/stack sampling, distributed
tracing, GPU/network/syscall accounting, Windows, a daemon, or
process-tree aggregation). If it asks for one of these, it is a
decline, not a backlog item. Cite the relevant non-goal. If the same
direction keeps being requested, suggest capturing the rejection as a
rationale entry under docs/rationale/ so the reasoning is reusable.
→ proposed label: the repo's wontfix / out-of-scope equivalent.
-
Bug — a broken contract? Find the governing requirement in
docs/requirements/. If rprof's behaviour violates that
requirement's acceptance criteria, it is a bug. The fix path is
test-first: a failing integration test tagged
// Requirements: <id>, then the code change (see the root
CLAUDE.md decision protocol).
→ proposed label: bug. Note the requirement ID in the triage.
-
New behaviour, in scope? If it is a feature or behaviour change
that no requirement covers yet and no non-goal forbids, it is
requirement-first: a proposed requirement must be written and
agreed before any code (see docs/requirements/CLAUDE.md).
→ proposed label: enhancement. Next step: draft the requirement.
-
Usage or question? Answer it; point at the top-level README.md
or the relevant doc. No code change.
→ proposed label: question.
-
Documentation gap? A wrong or missing doc, not a behaviour change.
→ proposed label: documentation.
Propose, then act
Summarise for the user, per issue:
- Classification and the evidence (the non-goal, requirement ID, or doc
it maps to).
- The next concrete action (decline with rationale / write a failing
test / draft a
proposed requirement / answer / fix a doc).
- The label(s) to apply, drawn from
gh label list.
After the user confirms, apply with gh:
gh issue edit <number> --add-label "<label>", and post the triage
summary as a comment with gh issue comment if they want it recorded.
Do not close an issue as out-of-scope without explicit confirmation.
