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](../../references/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.

## Step 5: Identify Suspected Areas

If the report points to a specific system area, list it. Then, only to sharpen those areas, consult project context: if
the `CLAUDE.md` label is non-empty, read it; if the `project-discovery.md` label is non-empty, read it (it is the richer
system map when present). Use them to name relevant areas such as upload pipeline, authentication middleware, database
migrations, or frontend state management.

Do not inf