← ClaudeAtlas

investigate-ticketlisted

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.
ClipboardHealth/groundcrew · ★ 40 · Code & Development · score 80
Install: claude install-skill ClipboardHealth/groundcrew
# 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.