Issue Triage

Project Context

• CLAUDE.md: !find . -maxdepth 1 -name "CLAUDE.md" -type f
• project-discovery.md: !find . -maxdepth 3 -name "project-discovery.md" -type f
• personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
• project .han/config.md: !cat .han/config.md 2>/dev/null || echo ""

As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md probe supplies content, apply it per config-rule.md, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Triage Approach

• 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.
• Classify the issue type before doing anything else. The type drives what counts as missing information.
• 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.
• The recommended next step is the single most appropriate han skill (or "clarify with reporter") to run after triage completes.
• Project context (CLAUDE.md, project-discovery.md) is read only to identify Suspected Areas. Never use it to supply information the reporter omitted.
• Source the standard by invoking han-communication:readability-guidance and apply it 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.

Issue Triage

Step 0: Resolve the Issue Text

Determine the issue text from the argument:

• If the argument is a path to an existing file, read that file; its contents are the issue text.
• Otherwise the argument text itself is the issue text.
• 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.

Step 1: Classify the Issue

Determine the issue type from the report text. Choose exactly one:

• Bug — something is broken or behaving unexpectedly
• Feature Request — something new is being asked for
• Performance — the system is too slow, uses too much memory, or degrades under load
• Security — a vulnerability, exposure, or access control concern
• Regression — the reporter explicitly says it used to work and no longer does; quote or paraphrase that statement
• Question — the reporter is asking how something works, not reporting a problem
• Other — none of the above apply

Step 2: Extract What Is Known

From the report, identify:

• Summary — one sentence describing the problem in plain terms
• Reported Behavior — what the reporter said happened, in their words or a close paraphrase
• Expected Behavior — what the reporter said should happen; if not stated, mark Unknown

Step 3: Identify Missing Information

List what a developer would need to reproduce or investigate this issue that is absent from the report. Common gaps by issue type:

• Bug / Regression — reproduction steps, environment (OS, browser, version), error messages or stack traces, affected data or user accounts, frequency of occurrence
• Performance — scale or load at which the problem occurs, baseline measurements, environment
• Security — affected endpoints or data, attack surface description, access level required to trigger
• Feature Request — use case or job to be done, success criteria, constraints
• 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

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.

Step 4: Assess Severity and Reproducibility

Severity (estimate from what is known):

• Critical — data loss, system down, security breach, or blocks all users
• High — major feature broken, significant user impact, no workaround known
• Medium — feature degraded, workaround exists, or affects a subset of users
• Low — cosmetic, edge case, or minor inconvenience
• Unknown — not enough information to assess

Reproducibility (estimate from what is known):

• Always — happens consistently under described conditions
• Intermittent — happens sometimes; conditions unclear
• Rare — reported once or infrequently; hard to reproduce
• Unknown — not stated in the report

Omit when inapplicable. Severity and Reproducibility describe a problem that is occurring. When the issue type is Feature Request, Question, or Other and neither is inferable from the report, omit both sections entirely rather than rendering Unknown — the same omit-when-not-inferable pattern Step 5 applies to Suspected Areas. For a Bug, Regression, Performance, or Security issue, always render both (as Unknown if needed); they are core to triaging a problem.