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.
1---2name: issue-triage3description: 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.4---56# Triage an rprof issue78Classify a GitHub issue and decide what happens to it, using rprof's own9docs as the rubric. **Reading is free; confirm with the user before any10write to the public repo** — posting a comment, applying labels, or11closing an issue.1213## Gather14151. Read the issue: `gh issue view <number> --comments`.162. List the repo's existing labels so you reuse them rather than invent:17 `gh label list`.183. If it is a bug claim with a reproduction, try to reproduce it (build19 and run `rprof` per the repo's CLAUDE.md) before classifying.2021## Classify2223Work the checks in this order — the cheapest filter first.24251. **Out of scope?** Compare against the non-goals in26 `docs/project-scope.md` (flamegraphs/stack sampling, distributed27 tracing, GPU/network/syscall accounting, Windows, a daemon, or28 process-tree aggregation). If it asks for one of these, it is a29 decline, not a backlog item. Cite the relevant non-goal. If the same30 direction keeps being requested, suggest capturing the rejection as a31 rationale entry under `docs/rationale/` so the reasoning is reusable.32 → proposed label: the repo's `wontfix` / out-of-scope equivalent.33342. **Bug — a broken contract?** Find the governing requirement in35 `docs/requirements/`. If `rprof`'s behaviour violates that36 requirement's acceptance criteria, it is a bug. The fix path is37 test-first: a failing integration test tagged38 `// Requirements: <id>`, then the code change (see the root39 `CLAUDE.md` decision protocol).40 → proposed label: `bug`. Note the requirement ID in the triage.41423. **New behaviour, in scope?** If it is a feature or behaviour change43 that no requirement covers yet and no non-goal forbids, it is44 requirement-first: a `proposed` requirement must be written and45 agreed before any code (see `docs/requirements/CLAUDE.md`).46 → proposed label: `enhancement`. Next step: draft the requirement.47484. **Usage or question?** Answer it; point at the top-level `README.md`49 or the relevant doc. No code change.50 → proposed label: `question`.51525. **Documentation gap?** A wrong or missing doc, not a behaviour change.53 → proposed label: `documentation`.5455## Propose, then act5657Summarise for the user, per issue:5859- Classification and the evidence (the non-goal, requirement ID, or doc60 it maps to).61- The next concrete action (decline with rationale / write a failing62 test / draft a `proposed` requirement / answer / fix a doc).63- The label(s) to apply, drawn from `gh label list`.6465After the user confirms, apply with `gh`:66`gh issue edit <number> --add-label "<label>"`, and post the triage67summary as a comment with `gh issue comment` if they want it recorded.68Do not close an issue as out-of-scope without explicit confirmation.
rizsotto