# Debug With Sentry

Root-cause a production error with Sentry's evidence before touching code, pull the...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill debug-with-sentry -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill debug-with-sentry -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill debug-with-sentry -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill debug-with-sentry -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

Root-cause a production error with Sentry's evidence before touching code, pull the issue, read the stack trace and breadcrumbs, and separate the crash from its trigger. Use when the user pastes a Sentry link or issue ID, reports a production error, or asks why something is crashing for users.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Root-cause with the evidence, not the guess

A Sentry issue is a claim about what broke. The job is to turn it into a claim
about *why* it broke, backed by the event data, before anyone edits code.

## 1. Get the real issue, not the search hit

A pasted URL or short ID (`PROJECT-123`) goes straight to `get_issue_details`.
A described error ("users can't check out") goes through `search_issues` first,
but treat the results as candidates: match on the error type and the affected
code path, not on title similarity. If two issues share a message but differ in
stack trace, they are two bugs.

## 2. Read the stack trace like a diff

Fetch the newest event's stack trace. The top frame is where it *crashed*, not
where it *broke*, walk down until you leave library code and hit the first
frame owned by this repo. That frame and its local variables are the starting
point. Cross-check the file against the working tree: production runs a
release, and the line numbers may belong to code that has since changed.
`find_releases` tells you which version the events come from.

## 3. Use the distribution before the theory

Before proposing a cause, check what the events have in common:

- **Tags** (`get_issue_tag_values`): one browser, one endpoint, one tenant, one
  release? A bug scoped to a dimension names its own trigger.
- **Breadcrumbs**: what the user did right before. A crash after a retry storm
  is a different bug than the same crash on first click.
- **First seen / volume**: an issue that started with a release points at that
  release's diff. One that grew slowly points at data or traffic.

Seer (`analyze_issue_with_seer`) is worth running for a second opinion, but
verify its suggested cause against the frames yourself before repeating it.

## 4. Report cause, scope, and blast radius

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/sentry/skills/debug-with-sentry/SKILL.md