---
name: ops-linear-triage-from-chat-bug-report
description: Use when a bug report or feature request collected from in-product chat needs to be classified, assigned, prioritized, and scheduled in Linear. Covers severity heuristics (P0–P3), component routing (frontend/backend/skill-router/auth/billing), team assignment rules, SLA-based due dates, and Slack notification — the downstream step after the bug-report-collector or feature-request-collector runs.
license: MIT
metadata:
  id: ops.linear-triage-from-chat-bug-report
  category: ops
  priority: P1
  intent: [ops, linear, triage, bug, severity]
  related: [ops-bug-report-collector, ops-feature-request-collector, ops-crash-report-formatter, ops-error-classifier]
  source: Louis — HAQQ Legal AI (github.com/sboghossian/mini-claude-for-legal)
  version: "1.0"
---

# Ops — Linear Triage from Chat Bug Report

## Purpose

A bug report collected in-chat is raw material. Triage converts it into an actionable Linear issue with the right owner, priority, and due date. Poorly triaged bugs fall through the cracks; over-triaged bugs waste engineering time on edge cases while real problems wait. This skill defines the rules for getting triage right every time.

## Inputs

This skill receives the output of [[ops-bug-report-collector]] or [[ops-feature-request-collector]]:
- User description (in their words)
- Auto-collected session metadata
- Preliminary severity from the collector
- Component hint (if the collector detected one)
- Persona (lawyer / consumer / enterprise)
- Surface (web / mobile / word-plugin)

## Triage steps

### Step 1 — Receive and verify

Pull the newly created Linear issue from the `LOUIS-BUGS` or `LOUIS-FEATURES` project. Confirm:
- Title is descriptive (not "bug" or "error")
- Description includes user context and session metadata
- PII redaction has been applied (no raw names, emails, document content)

If any of these are missing, add them before proceeding.

### Step 2 — Classify by component

Determine which engineering domain owns the issue:

| Component | Indicators | Owner |
|-----------|------------|-------|
| Frontend | UI rendering issue, browser console error, React component failure, layout bug | Frontend lead |
| Backend / API | HTTP 5xx, database error, API response format issue, server-side logic bug | Backend lead |
| Skill router | Wrong skill invoked, router fallback triggered unexpectedly, skill composition error | AI team |
| Auth | Login failure, session expiry, permission denied error | Backend lead / Security |
| Billing | Subscription state incorrect, payment failure not handled, credit not applied | Ops lead |
| Infrastructure | Database timeout, memory exhaustion, cold-start latency spike | Infra/DevOps |

When in doubt, assign to the most likely owner and leave a comment with the uncertainty noted.

### Step 3 — Classify severity

| Level | Definition | Examples |
|-------|------------|---------|
| **P0** | Full or partial outage; data loss; security vulnerability; loss of a client's saved work | App down for all users; a saved draft was deleted; SQL injection found |
| **P1** | Feature broken for a significant portion of users; payment processing failure; frequent crashes that block work | PDF upload fails for all users; payment webhook not firing; skill router always falls back |
| **P2** | Edge-case failure; affects a small number of users; workaround available | Arabic RTL rendering glitch in a specific browser; date format wrong in one jurisdiction |
| **P3** | Cosmetic; non-blocking; nice-to-have fix | Spinner animation jank; button text slightly misaligned |

When the user is a **paid tier** user and the bug blocks their paid feature, automatically elevate one severity level (P3 → P2, P2 → P1). Paying customers have a higher SLA expectation.

### Step 4 — Set due date based on severity

| Severity | Target resolution |
|----------|------------------|
| P0 | 24 hours from report |
| P1 | 1 week from report |
| P2 | 1 month from report (or next sprint) |
| P3 | Backlog; no fixed date |

Due dates are targets, not hard deadlines — but they should be set in Linear so that missed SLAs surface visibly in the weekly ops review.

### Step 5 — Assign

Set the assignee to the component owner (from Step 2). If the component owner is unclear, assign to the engineering lead who triages the morning standup queue.

### Step 6 — Notify

- For P0: immediately post to `#incidents` Slack channel and page the on-call engineer.
- For P1: post to `#bugs-p1` Slack channel with a link to the Linear issue.
- For P2/P3: no Slack notification; visible in the Linear project view.
- If the user opted in to updates, add them as a subscriber on the Linear issue.

## Anti-patterns to avoid

| Anti-pattern | Why it's harmful |
|---|---|
| Over-triaging: full P0/P1 treatment for every report | Desensitizes the team to alerts; burns engineering cycles on low-impact issues |
| Under-triaging: marking a real P1 as P2 because it only affects one user | If that user is a key enterprise account, the impact is disproportionate |
| No owner set | Unowned bugs languish; nobody feels accountable |
| No due date | Bugs marked but not scheduled are effectively invisible |
| PII in Linear | A serious compliance risk; redact before triage, not after |

## Weekly triage review

The product/engineering lead runs a weekly review of the triage queue:
- All P2 bugs open >14 days are re-evaluated (upgrade to P1 or close as won't fix)
- All unassigned bugs are assigned
- P3 bugs open >90 days are closed or promoted
- Feature requests with >5 unique requesters are moved from `LOUIS-FEATURES` to the roadmap backlog for prioritization

## Related skills

- [[ops-bug-report-collector]] — the upstream collection step that feeds this triage skill
- [[ops-feature-request-collector]] — the parallel upstream for feature requests
- [[ops-crash-report-formatter]] — produces the structured crash ticket that may also feed this triage
- [[ops-error-classifier]] — classifies errors before they become Linear issues