triage-work-itemlisted

# Triage a tracker work item against the codebase and observability data Throughout this skill "work item" is the generic term for whatever the tracker holds — a bug, task, or story (Jira and GitHub both call the object an "issue," and the steps below keep that word when naming the concrete object or an API/CLI call). This is an investigation workflow, not a lookup. The value it adds over just reading the work item is a verified conclusion — a specific code path, config value, or data condition for a bug; a validated approach and effort estimate for a change request — that a future engineer can act on immediately, backed by evidence you actually checked rather than plausible-sounding guesses. Every step below exists to either gather that evidence or to guard against reporting something that sounds right but isn't. The workflow is tool-agnostic; the tracker-specific and observability-specific mechanics live in adapter files under `references/` and load only when you reach the step that needs them. This keeps the always-loaded body focused on judgment — the part that's the same whether the work item lives in Jira or GitHub and whether the telemetry is in Grafana or CloudWatch. By default, once you've verified your findings, post the comment — don't pause for a separate approval step. The verification step (Step 9) is the safety gate, not a human checkpoint. The one exception is `--dry-run`: if the user passes it (or clearly wants to see the analysis before anything goes out