issue-triage

Name: issue-triage
Author: testdouble

122stars12forks

How to install issue-triage?

testdouble/han/issue-triage

$npx -y skills add testdouble/han --skill issue-triage

Installs into the current project.

Summary

Triage a raw, vague issue or bug report into a structured document that names what is known, what is missing, and what to do next. Use when an incoming issue, bug report, or problem description is too vague or incomplete for investigation or planning, and recommend the right next

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5
6	## Triage Approach
7
8	- Work only from what the reporter wrote. Do not infer facts that are not stated. This is the single most important constraint in this skill.
9	- Classify the issue type before doing anything else. The type drives what counts as missing information.
10	- Severity and reproducibility are estimates based on what is known. For a Bug, Regression, Performance, or Security issue, mark them Unknown when not inferable. For a Feature Request, Question, or Other issue, omit them entirely when they are not inferable (see Step 4) rather than rendering Unknown.
11	- The recommended next step is the single most appropriate han skill (or "clarify with reporter") to run after triage completes.
12	- Project context (CLAUDE.md, project-discovery.md) is read only to identify Suspected Areas. Never use it to supply information the reporter omitted.
13	- Load and apply the readability rule (`../../references/readability-rule.md`) as you write the triage document. Hold its default audience frame: a capable reader who did not do this work and lacks the author's context.
14
15	# Issue Triage
16
17	## Step 0: Resolve the Issue Text
18
19	Determine the issue text from the argument:
20
21	- If the argument is a path to an existing file, read that file; its contents are the issue text.
22	- Otherwise the argument text itself is the issue text.
23	- If no argument was given and no issue text is present in the conversation, ask the reporter to paste the issue or bug report, then stop until they provide it.
24
25	## Step 1: Classify the Issue
26
27	Determine the issue type from the report text. Choose exactly one:
28
29	- Bug — something is broken or behaving unexpectedly
30	- Feature Request — something new is being asked for
31	- Performance — the system is too slow, uses too much memory, or degrades under load
32	- Security — a vulnerability, exposure, or access control concern
33	- Regression — the reporter explicitly says it used to work and no longer does; quote or paraphrase that statement
34	- Question — the reporter is asking how something works, not reporting a problem
35	- Other — none of the above apply
36
37	## Step 2: Extract What Is Known
38
39	From the report, identify:
40
41	- Summary — one sentence describing the problem in plain terms
42	- Reported Behavior — what the reporter said happened, in their words or a close paraphrase
43	- Expected Behavior — what the reporter said should happen; if not stated, mark Unknown
44
45	## Step 3: Identify Missing Information
46
47	List what a developer would need to reproduce or investigate this issue that is absent from the report. Common gaps by issue type:
48
49	- Bug / Regression — reproduction steps, environment (OS, browser, version), error messages or stack traces, affected data or user accounts, frequency of occurrence
50	- Performance — scale or load at which the problem occurs, baseline measurements, environment
51	- Security — affected endpoints or data, attack surface description, access level required to trigger
52	- Feature Request — use case or job to be done, success criteria, constraints
53	- Feature Request / Question (problem space not yet decided) — which options or approaches are in play, prior art, a build-vs-buy choice, or which direction to take, when the reporter is asking to define or scope the problem rather than supplying a missing fact about a direction already chosen
54
55	List only what is genuinely absent. Do not list information already present in the report. If nothing is missing, write exactly: `None - report has enough to proceed.`
56
57	## Step 4: Assess Severity and Reproducibility
58
59	Severity (estimate from what is known):
60
61	- Critical — data loss, system down, security breach, or blocks all users
62	- High — major feature broken, significant user impact, no workaround known
63	- Medium — feature degraded, workaround exists, or affects a subset of users
64	- Low — cosmetic, edge case, or minor inconvenience
65	- Unknown — not enough information to assess
66
67	Reproducibility (estimate from what is known):
68
69	- Always — happens consistently under described conditions
70	- Intermittent — happens sometimes; conditions unclear

People who liked this also viewed

6 picks

Type

issue-triage

122stars12forks

View on GitHub

How to install issue-triage?

testdouble/han/issue-triage

$npx -y skills add testdouble/han --skill issue-triage

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5
6	## Triage Approach
7
8	- Work only from what the reporter wrote. Do not infer facts that are not stated. This is the single most important constraint in this skill.
9	- Classify the issue type before doing anything else. The type drives what counts as missing information.
10	- Severity and reproducibility are estimates based on what is known. For a Bug, Regression, Performance, or Security issue, mark them Unknown when not inferable. For a Feature Request, Question, or Other issue, omit them entirely when they are not inferable (see Step 4) rather than rendering Unknown.
11	- The recommended next step is the single most appropriate han skill (or "clarify with reporter") to run after triage completes.
12	- Project context (CLAUDE.md, project-discovery.md) is read only to identify Suspected Areas. Never use it to supply information the reporter omitted.
13	- Load and apply the readability rule (`../../references/readability-rule.md`) as you write the triage document. Hold its default audience frame: a capable reader who did not do this work and lacks the author's context.
14
15	# Issue Triage
16
17	## Step 0: Resolve the Issue Text
18
19	Determine the issue text from the argument:
20
21	- If the argument is a path to an existing file, read that file; its contents are the issue text.
22	- Otherwise the argument text itself is the issue text.
23	- If no argument was given and no issue text is present in the conversation, ask the reporter to paste the issue or bug report, then stop until they provide it.
24
25	## Step 1: Classify the Issue
26
27	Determine the issue type from the report text. Choose exactly one:
28
29	- Bug — something is broken or behaving unexpectedly
30	- Feature Request — something new is being asked for
31	- Performance — the system is too slow, uses too much memory, or degrades under load
32	- Security — a vulnerability, exposure, or access control concern
33	- Regression — the reporter explicitly says it used to work and no longer does; quote or paraphrase that statement
34	- Question — the reporter is asking how something works, not reporting a problem
35	- Other — none of the above apply
36
37	## Step 2: Extract What Is Known
38
39	From the report, identify:
40
41	- Summary — one sentence describing the problem in plain terms
42	- Reported Behavior — what the reporter said happened, in their words or a close paraphrase
43	- Expected Behavior — what the reporter said should happen; if not stated, mark Unknown
44
45	## Step 3: Identify Missing Information
46
47	List what a developer would need to reproduce or investigate this issue that is absent from the report. Common gaps by issue type:
48
49	- Bug / Regression — reproduction steps, environment (OS, browser, version), error messages or stack traces, affected data or user accounts, frequency of occurrence
50	- Performance — scale or load at which the problem occurs, baseline measurements, environment
51	- Security — affected endpoints or data, attack surface description, access level required to trigger
52	- Feature Request — use case or job to be done, success criteria, constraints
53	- Feature Request / Question (problem space not yet decided) — which options or approaches are in play, prior art, a build-vs-buy choice, or which direction to take, when the reporter is asking to define or scope the problem rather than supplying a missing fact about a direction already chosen
54
55	List only what is genuinely absent. Do not list information already present in the report. If nothing is missing, write exactly: `None - report has enough to proceed.`
56
57	## Step 4: Assess Severity and Reproducibility
58
59	Severity (estimate from what is known):
60
61	- Critical — data loss, system down, security breach, or blocks all users
62	- High — major feature broken, significant user impact, no workaround known
63	- Medium — feature degraded, workaround exists, or affects a subset of users
64	- Low — cosmetic, edge case, or minor inconvenience
65	- Unknown — not enough information to assess
66
67	Reproducibility (estimate from what is known):
68
69	- Always — happens consistently under described conditions
70	- Intermittent — happens sometimes; conditions unclear

People who liked this also viewed

6 picks

Type