write-bug-ticket
$
npx mdskill add ClipboardHealth/core-utils/write-bug-ticketDrafts 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
- adversarial-reviewPerform an adversarial review of proposed work. Use ONLY when the user explicitly types /adversarial-review. Never auto-trigger, even if the user mentions reviewing, questioning, or challenging their approach.
- clipboard-testingEnd-to-end testing playbook for Clipboard Health changes. Use when the user wants to verify, exercise, or set up test data for a backend or frontend change against a live environment — "test my change end-to-end", "verify this works in dev", "create a test workplace / worker / shift", "get a shift through to paid / invoiced", "prove the API change works". Defaults to the `development` AWS environment, API-first (cbh CLI tokens + curl). The skill knows enough to run the core happy-path flow (workplace → worker → shift → clock in/out → pay → invoice) autonomously; for anything else, it orients around the codebase and asks the user for missing directories.
- cognito-user-analysisUse when looking up Cognito user details by sub UUID, finding duplicate accounts sharing phone or email, analyzing which duplicates to keep vs delete, or fixing orphaned UNCONFIRMED signups. Symptoms include 403 Forbidden on login, multiple accounts for same phone, backend sync issues.
- datadog-investigateInvestigate production issues by querying Datadog logs, metrics, and APM traces, then correlating findings with the codebase. Use this skill whenever the user mentions production errors, Datadog, observability, log investigation, latency spikes, error rate increases, 500s, trace IDs, monitor alerts, or wants to debug any service issue in a deployed environment.
- flaky-test-debuggerDebug and fix flaky tests including Playwright E2E, NestJS service/integration, React component, and unit tests. Use this skill when investigating intermittent test failures, triaging flaky tests, or fixing test instability.
- interview-featureUse when clarifying requirements for a feature ticket. Iteratively researches and interviews the user until the problem is well-understood, then produces a structured problem brief. Dispatched by write-feature-ticket when context is insufficient.
- investigate-ticketUse when investigating a bug, incident, or issue before implementation. Researches codebase, queries Datadog, and presents structured findings with handoff options. Also use when asked to "look into" or "investigate" something.
- local-packageUse Clipboard's internal CLI to link and unlink @clipboard-health packages across repositories for local development. Use when testing local package changes, linking @clipboard-health packages between repos, or using the cbh CLI local-package command.
- seed-dataTrigger seed data generation for test environments via GitHub Actions. Use when asked to seed, create test data, or set up HCPs/facilities/shifts.
- write-feature-ticketUse when creating a Linear feature request ticket from conversation context, a brief description, or code/PR analysis. Interviews the user for clarity when context is insufficient.