# Linear Bug Triage > Use this skill after a bug or regression candidate has measured evidence to document them within linear. - Skill: `jasonkneen/linear-bug-triage` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jasonkneen/linear-bug-triage` - Raw SKILL.md: https://api.skillmd.com/api/skills/jasonkneen/linear-bug-triage/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jasonkneen (https://skillmd.com/u/jasonkneen) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jasonkneen/linear-bug-triage --- # Linear Bug Triage Use this skill after a bug or regression candidate has measured evidence. This skill owns Linear search, deduplication, evidence comments, and filing new issues once a human says yes; the calling skill owns deciding whether the signal is issue-worthy. ## What This Skill May Write Every write carries a label and is marked as agent-written in the text, and only three write shapes are permitted at all. [`linear-agent-writes`](../linear-agent-writes/SKILL.md) is the authority for that policy; read it before your first write and prefer it over this summary wherever they differ. For this skill it resolves to: - **An evidence comment on an issue that already exists: propose, then post.** Show the comment body in the findings table, get a yes (one go-ahead can cover the whole set), then post it and label that issue `AI commented`. Mark the comment body as agent-written. - **A new top-level issue: ask once, then file it.** A bug cluster surfaced by a review has no parent, and a parentless ticket needs a go-ahead. Take one go-ahead for the whole set, or for named rows — never one question per candidate. So present the findings table either way: it is what the go-ahead is given against, and it is the report afterwards. One row per candidate: - Candidate / cluster name. - Environments. - Service and route/resource. - Recent window measurement. - Baseline measurement. - Delta / regression summary. - Key evidence links — the ones *Required Evidence* below asks for. - Action: `awaiting your go-ahead` with the exact comment or ticket body, `commented ` once approved and posted, or `filed ` once a row is approved and created. Never present an `awaiting your go-ahead` row without the exact title and body you intend to land underneath it — that text is what is being approved. Deduplicate first, so comments land on the right issue. If Linear is unreachable in this environment, say so plainly and return every row as text ready to paste. Do not skip the handoff silently. ## Required Evidence For each candidate, gather: - Recent window and baseline window as absolute time ranges with timezone. - Measured signal: counts, rates, p50/p95/p99 latency, trace samples, flamegraphs, monitor thresholds, or benchmark deltas. - Affected environments, services, routes/resources, status codes, and top error messages. - Datadog links for logs, spans, traces, metrics, dashboards, or flamegraphs used as evidence. - The exact text `No measurements found` for requested measurements that are unavailable. Do not create or comment based on guesses, unsupported impact claims, or missing measurements alone. ## Deduplication Always, before writing anything: 1. Search Linear for related open issues using exact error text, route/resource, service, environment, monitor name, and observability link keywords. 2. Search recently closed or canceled issues if the error is recurring or the wording is distinctive. 3. If a related issue exists, put a concise evidence comment in the findings table as `awaiting your go-ahead`. Post it and label `AI commented` only after the go-ahead (one yes can cover the whole set). 4. If no related issue exists, prepare the issue in the format below and put it in the findings table as `awaiting your go-ahead`. File it once the go-ahead comes, and update the row to `filed `. ## Existing Issue Comments For related existing issues, after a yes, add only: - Recent window and baseline window. - Measured delta or `No measurements found` for unavailable signals. - Affected environments, services, routes/resources, and top error messages. - The evidence links from *Required Evidence*. Do not add fix suggestions, root-cause guesses, implementation notes, owner assignments, or next steps. ## New Issue Format The shape to prepare, show for the go-ahead, and then file: - State/status `Triage`; pass the Linear state explicitly on creation and do not rely on workspace defaults. - Label `bug`. - Additional existing labels that match the evidence, such as affected service, environment, API, ingestion, latency, ClickHouse, Postgres, integrations, or observability labels. Query labels first and use the repository/team's exact label names. - Concise title: `bug: in `. - Concise body, evidence-only: ```markdown Recent window: Baseline: Signal: - - <"No measurements found" for missing requested measurements> Evidence: - Datadog logs: - Datadog spans/traces: - Datadog metrics, dashboard, or latency graph: Related Linear search: - ``` Do not include fix suggestions, root-cause guesses, implementation notes, owner assignments, or next steps unless the user explicitly asks outside the Linear issue or comment.