investigate-ticket

---
name: investigate-ticket
description: Use 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.
---

# Investigate Ticket

Research-only workflow — no code changes, no fixes, no PRs. Produces a structured summary with evidence, then hands off to ticket creation or the user.

## Process

1. **Gather context** — accept a ticket ID/URL, Slack thread, Datadog alert, or verbal description. If a Linear ticket exists, fetch it.
2. **Initial Datadog scan** — quick, broad search for obvious signals. The goal is orientation, not root cause. **Do not form a hypothesis yet.**
3. **Trace the full execution path** — from the entry point (controller, webhook handler, cron job), trace through **every branch, early return, and conditional** to the expected outcome. For each branch, note:
   - What condition triggers it
   - What log message it produces (exact string and structured attributes)
   - Whether a feature flag gates it (note the flag key)
     Do NOT skip branches that seem unlikely — those are where non-obvious bugs hide.
4. **Check feature flags** — if you found flags in step 3, look up each flag's current state in LaunchDarkly (see reference.md for details).
5. **Validate each branch in Datadog** — search for the exact log messages and structured attributes from the code using `@field:value` queries, not free-text. This tells you which code path was actually taken (see reference.md for search strategy).
6. **Check data state in Snowflake** — if the issue involves unexpected data or "works for some users but not others," query Snowflake to verify actual data state (see reference.md). Skip if purely code/config.
7. **Cross-reference** — check git history for recent changes. Look for related Linear tickets. Check if the issue correlates with a deploy or flag change.
8. **Summarize findings** — present a structured summary (see Findings Format in reference.md).
9. **Hand off** — ask the user what to do next:
   - Update an existing Linear ticket with findings
   - Create a new ticket (redirect to appropriate ticket skill, carrying context forward)
   - Keep findings, no ticket action

## Hard Rules

1. **Always search Datadog** before concluding. Not optional.
2. **Always include file paths and line numbers.** "The booking service" is not acceptable.
3. **NEVER implement fixes.** This is research only. If you're writing production code, STOP.
4. **Present findings before any ticket action.** The user decides next steps, not you.
5. **Don't invent root causes.** If you can't determine it from evidence, say so.
6. **Carry context forward.** When handing off to a ticket skill, pass all findings.
7. **Trace the full path before forming a hypothesis.** Walk every branch from entry point to outcome.
8. **Use structured Datadog queries, not free-text guesses.** Read the code's logger calls first.

## Red Flags — STOP If You Notice These

| You're about to...                                         | STOP and...                                                                                                         |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Write a fix for the bug you found                          | This is investigation only — present findings first                                                                 |
| Skip Datadog because "I already understand the issue"      | Search Datadog anyway — you might find something unexpected                                                         |
| Form a root cause theory before tracing the full code path | Trace entry point → every branch → expected output first. Hypotheses from partial code reads miss early-return bugs |
| Search Datadog with free-text keywords only                | Read the code's logger calls first, then search using structured attributes (`@field:value`)                        |
| Assume the code is wrong without checking data             | Query Snowflake to verify actual data state before blaming code logic                                               |
| Ignore a feature flag in the code path                     | Look up the flag state in LaunchDarkly — it may be gating the behavior you're investigating                         |

## Cross-Referenced Skills

- `write-bug-ticket`, `write-tech-debt-ticket`, `write-feature-ticket` — for creating tickets from findings
- `datadog-investigate` — API reference for Datadog queries when no Datadog MCP is available