write-bug-ticket

$npx mdskill add ClipboardHealth/core-utils/write-bug-ticket

Drafts Linear bug tickets from existing evidence without diagnosing.

  • Converts user reports and investigation findings into structured bug tickets.
  • Depends on conversation context, Datadog links, and error details.
  • Validates missing symptoms before drafting and avoids inventing answers.
  • Presents draft text and metadata for team approval before creation.
SKILL.md
.github/skills/write-bug-ticketView on GitHub ↗
---
name: write-bug-ticket
description: Use when creating a Linear bug report ticket from conversation context, investigation findings, or user-provided evidence. Focuses on structuring and writing — not investigating.
---

# Write Bug Ticket

Structure and write Linear bug reports from evidence that already exists in the conversation. Never diagnose root cause or propose fixes. Never investigate — that's `investigate-ticket`'s job.

> **No evidence yet?** If the conversation lacks Datadog links, error details, or clear symptom descriptions, STOP and redirect to `investigate-ticket` first. It will hand off back here with structured findings.
>
> **Already investigated?** If the conversation contains investigation findings (Datadog links, code paths, Snowflake queries, flag state), use them directly — don't re-investigate.

## Process

1. **Gather context** — collect evidence from the conversation: investigation findings, user reports, Datadog links, error details
2. **Clarify (conditional)** — if missing: (a) expected behavior, (b) actual behavior, or (c) who's affected — ask before drafting. NEVER invent answers. Up to 3 rounds.
3. **Draft** — title + description, structure scaled to complexity (see format below)
4. **Self-review** — check every Red Flag below before presenting
5. **Present for review** — show ONLY the draft and metadata suggestions. Ask for team/assignee.
6. **Create in Linear** — only after explicit approval

## Hard Rules

- **Symptom-first, diagnosis-never.** NEVER propose a fix, root cause, or investigation steps. Technical context is fine — speculation is not.
- **Evidence belongs in the ticket, but gathering it does not.** Include Datadog links, Snowflake findings, and flag state from the conversation. If none exist, redirect to `investigate-ticket` — don't search yourself.
- **STR preferred, not required.** If not reproduced: "Not yet reproduced manually. Observed via monitoring." NEVER invent STR.
- **Clean titles.** No bracket prefixes. Describe the symptom. Under 70 characters.
- **Always document the repository.** Flag multi-repo bugs to the user for splitting.
- **Redirect non-bugs.** Features → `write-feature-ticket`, tech debt → `write-tech-debt-ticket`.

## Ticket Format

**Title:** Describes the SYMPTOM, not the cause. Under 70 characters. No bracket prefixes.

**Repository:** Always include the repository name in the ticket body. Run `git remote get-url origin | sed 's/\.git$//' | sed 's/.*[:/]\([^/]*\/[^/]*\)$/\1/'` to get the `org/repo` name. For simple bugs, include as a bold inline label. For complex bugs, include in `## Technical Context`.

**Simple bug** (<4 details): A paragraph with bold inline labels (**Expected:**, **Actual:**, **Repository:**, etc.). No `##` headers needed.

**Complex bug** (multi-service, intermittent, wide impact): Use `## Expected Behavior`, `## Actual Behavior`, `## Steps to Reproduce`, `## Evidence`, `## Technical Context` (include repository — observables only, NOT diagnosis), `## Impact`.

**Metadata:** Priority, labels (`bug`), presented BELOW the body. Always ask for team/assignee.

See reference.md for full examples.

## Red Flags — Self-Review Before Presenting

| Anti-Pattern                   | Fix                                                                     |
| ------------------------------ | ----------------------------------------------------------------------- |
| Root cause diagnosis           | Remove — describe symptom and evidence only                             |
| Proposed fix                   | Remove entirely                                                         |
| Investigation runbook          | Remove — this is a bug report, not an investigation plan                |
| Vague actual behavior          | Be specific: "Returns 500 error when..."                                |
| Missing expected behavior      | Add what should happen                                                  |
| Raw logs pasted inline         | Replace with Datadog log query link                                     |
| No evidence in conversation    | STOP drafting — redirect to `investigate-ticket` to gather evidence     |
| Searching Datadog yourself     | This skill writes, not investigates — use existing evidence or redirect |
| Diagnosis disguised as context | Rewrite as observable: "Cache misses increased 3x after deploy"         |
| STR invented from assumptions  | "Not yet reproduced. Observed via monitoring."                          |
| Guessed team assignment        | Ask the user — never guess                                              |
| Bracket title prefixes         | Describe the symptom without brackets                                   |
| Missing repository             | Include repo name in ticket body — derive from git remote               |
More from ClipboardHealth/core-utils