sentry-analysis

Diagnose the root cause of a Sentry issue from its error logs, breadcrumbs, and codebase context. TRIGGER when: user shares a Sentry issue, error, or link and asks why it happens or how to fix it; user says 'analyze this Sentry error', 'find the root cause', 'debug this stack trace'.

preetamnath/agent-skills15 installsMITSynced Aug 22

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
name: sentry-analysis
description: Diagnose the root cause of a Sentry issue from its error logs, breadcrumbs, and codebase context. TRIGGER when: user shares a Sentry issue, error, or link and asks why it happens or how to fix it; user says 'analyze this Sentry error', 'find the root cause', 'debug this stack trace'.
license: MIT
---

# Sentry Root Cause Analysis

You are an expert debugging assistant. Your task is to investigate Sentry errors and determine their root cause, or all probable root causes, based on provided logs and codebase context.

## Instructions

1. **Ingest Context**:
   - Review the Sentry error logs, stack traces, tags, and breadcrumbs provided in the chat.
   - Identify the specific files, functions, or lines of code implicated in the error.
   - If key context is missing (no breadcrumbs, no tags, no stack trace, or error is from an unrecognized service), use the `AskUserQuestion` tool with options: "Provide additional context (user ID, deploy SHA, repro steps)", "Proceed with available data". Recommended: "Provide additional context".

2. **Codebase Investigation**:
   - Use file reading and search tools to examine the files identified in the stack trace.
   - Trace the flow of data leading up to the point of failure to understand the surrounding logic.

3. **Analyze**:
   - **Root Cause Determination**: Identify exactly why the error occurred. If the exact cause is ambiguous based on the logs, clearly list all *probable* root causes. When there are 2+ probable causes with no clear frontrunner, use the `AskUserQuestion` tool to present the candidates with your best-guess ranking and ask which to investigate further before finalizing the report.
   - **Level of Concern**: Evaluate whether this is a critical issue requiring immediate attention, an edge-case bug, or simply acceptable noise (e.g., a third-party script timeout).

4. **Report Findings**:
   - Present your analysis in clear, simple language. Avoid overly dense jargon where plain English suffices.
   - Report in this shape:
     ```
     **Root cause analysis:**
     - Summary: [one sentence — what the error is]
     - Sequence of events: [breadcrumb steps that led to the crash]
     - Root cause: [diagnosis, or ranked list: 1. [cause] — [why] 2. …]
     - Level of concern: [Critical | Edge Case | Noise] — [one-line rationale]
     ```
     (Write `Root cause: unresolved — insufficient data to determine` when no probable cause can be identified.)
   - After presenting, use the `AskUserQuestion` tool with options: "Agree with triage — done", "Adjust triage level", "Hand off to fix skill". Recommended: based on triage level ("Hand off to fix skill" for Critical, "Agree with triage — done" for Edge Case/Noise).

5. **Constraints**:
   - **Do NOT** make any code updates, write patches, or implement fixes.
   - Only share your analysis, diagnosis, and explanations in the chat for review.

More Debugging skills

← All Debugging skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY