Linear Bug Triage Agent Skill
| Use this skill after a bug or regression candidate has measured evidence to document them within linear.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/langfuse/langfuse --skill linear-bug-triageWhat comes with it
235 bytes besides the instructionThe instruction itself
6 sections, as written by the authorLinear Bug Triage
Use this skill after a bug or regression candidate has measured evidence. This
skill owns Linear search, deduplication, evidence comments, and ticket creation;
the calling skill owns deciding whether the signal is issue-worthy.
Human Approval Gate
Before doing anything in Linear, first show the findings to the human in a
compact markdown table and ask for explicit permission to share them in Linear.
The table should include one row per candidate with:
- Candidate / cluster name.
- Environments.
- Service and route/resource.
- Recent window measurement.
- Baseline measurement.
- Delta / regression summary.
- Key Datadog evidence links.
- Proposed Linear action (
comment existing,create new, ornone).
If the human does not explicitly approve, stop after presenting the table. Do
not search Linear, do not comment on issues, and do not create issues.
If a calling workflow already showed the findings table and obtained explicit
human approval for a Linear handoff, skip this gate and proceed directly to
deduplication.
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 foundfor requested measurements that are
unavailable.
Do not create or comment based on guesses, unsupported impact claims, or missing
measurements alone.
Deduplication
After the human explicitly approves, before creating a new issue:
- Search Linear for related open issues using exact error text, route/resource,
service, environment, monitor name, and Datadog link keywords.
- Search recently closed or canceled issues if the error is recurring or the
wording is distinctive.
- If a related issue exists, add a concise evidence comment instead of creating
a duplicate.
- If no related issue exists, create one Linear issue in the
Triagestate for
each distinct bug cluster.
Existing Issue Comments
For related existing issues, add only:
- Recent window and baseline window.
- Measured delta or
No measurements foundfor unavailable signals. - Affected environments, services, routes/resources, and top error messages.
- Datadog links.
Do not add fix suggestions, root-cause guesses, implementation notes, owner
assignments, or next steps.
New Issue Format
Create new issues with:
- 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: <service or route> <measured symptom> in <envs>. - Concise body, evidence-only:
Recent window: <absolute time range and timezone>
Baseline: <absolute time range and timezone>
Signal:
- <count/rate/latency delta with env/service/route>
- <"No measurements found" for missing requested measurements>
Evidence:
- Datadog logs: <url>
- Datadog spans/traces: <url>
- Datadog metrics, dashboard, or latency graph: <url>
Related Linear search:
- <brief search terms used and result>
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.
Other skills for the same job
different authors, same section of the catalogue
Plan, execute, and document validation, verification, and transfer of analytical procedures under the governing framework - ICH Q2(R2) and Q14, USP <1220>/<1225>/<1226>, ICH M10 bioanalytical, CLSI EP, or ISO/IEC 17025. Use for HPLC, LC-MS/MS, GC, CE, ICP-MS, dissolution, qNMR, qPCR, NIR, and ligand binding or cell-based assays whenever the question is whether a procedure is fit for its intended purpose. Triggers include "method validation", "analytical method validation", "AMV", "validation protocol", "acceptance criteria", "linearity", "reportable range", "accuracy and precision", "repeatability", "intermediate precision", "recovery", "LOD", "LOQ", "detection limit", "quantitation limit", "specificity", "robustness", "method transfer", "method comparison", "Deming", "Passing-Bablok", "Bland-Altman", "equivalence testing", "OOS investigation", "ICH Q2", "Q2(R2)", "Q14", "USP 1225", "ICH M10", "incurred sample reanalysis", "ISR", "CLSI EP", and any request to show that an assay works.
This skill provides a structured workflow for guiding users through collaborative document creation. Act as an active guide, walking users through three stages: Context Gathering, Refinement & Structure, and Reader Testing.
Creates comprehensive Technical Design Documents (TDD) with mandatory and optional sections through interactive discovery. Use when user asks to "write a design doc", "create a TDD", "technical spec", "architecture document", "RFC", "design proposal", or needs to document a technical decision before implementation. Do NOT use for README files, API docs, or general documentation (use docs-writer instead).
Adversarial Quarto-vs-Beamer parity QA. A critic agent compares the Quarto HTML render to the Beamer PDF benchmark for content/visual parity; a fixer agent applies fixes; loops until APPROVED (max 5 rounds). Use when user says "qa the quarto", "check parity", "does the html match the pdf?", "quarto matches beamer?", or after a translate-to-quarto run. Requires both the `.qmd` rendered and a `.pdf` benchmark.
>- Adversarially stress-tests a legal text — a contract, statute, regulation, or people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix. Use it whenever someone wants to pressure-test, red-team, audit, or find weak spots, loopholes, gaps, ambiguities, or drafting problems in a legal document; whenever a drafter wants to tighten a contract, statute, regulation, or opinion before it issues; whenever a litigator wants to mine an opinion or contract for arguments; or whenever someone hands over a legal text and asks where it will be fought over or for issue-spotting. Trigger it for contract review, statutory-ambiguity analysis, judicial-opinion scope analysis, and drafting QA — even if the user never says "stress-test" or "ambiguity."
Acceptance test creation methodology for the DISTILL wave. Domain knowledge for the acceptance designer agent: port-to-port principle, prior wave reading, wave-decision reconciliation, graceful degradation, and document back-propagation.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.
Convert structured project-note JSON manuscripts into validated EPUB and optional Kindle-clickable PDF files. Use when the user asks to turn project notes, book-system JSON, FIRE-indexed notes, Luhmann/Zettelkasten numbered chunks, table-of-contents cards, index cards, cross-linked project notes, or manuscript JSON into an EPUB/PDF with chapter directories, keyword index cards, weighted links, bidirectional backlinks, versioned filenames, chapter-splitting plans, and full link testing.
How to use it
Take langfuse/linear-bug-triage from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.