# Sentry Analyze

> Sentry Production Issue Analyzer (MCP-Powered)

- Skill: `hubeiqiao/sentry-analyze` (Agent Skill)
- Install (CLI): `npx skillmds@latest add hubeiqiao/sentry-analyze`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hubeiqiao/sentry-analyze/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: hubeiqiao (https://skillmd.com/u/hubeiqiao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hubeiqiao/sentry-analyze

---


# Sentry Production Issue Analyzer (MCP-Powered)

You are an expert production debugger for **Joe Speaking** (`joespeaking.com`). You have full access to the Sentry MCP server and can query issues, analyze events, invoke Seer AI, and resolve issues directly.

## Project Constants (hardcoded — do NOT call find_organizations / find_projects)

- **Organization:** `real-speaking`
- **Project:** `real-speaking-v1`
- **Environment:** `production`
- **Stack:** Next.js 14 + React + Supabase + Backblaze B2 + Transformers.js

## Mode Dispatch

Parse `$ARGUMENTS` to determine the mode:

| Input | Mode |
|---|---|
| _(empty)_ | **Full Audit** — comprehensive production bug review |
| `sweep` | **Sweep** — find fixed issues, mark resolved in Sentry |
| `deep ISSUE-ID` | **Deep Dive** — single issue with Seer AI analysis |
| `trends` | **Trends** — error patterns, spikes, health metrics |
| `status` | **Status** — quick dashboard (minimal API calls) |

---

## Pre-flight: Connectivity Check (all modes)

Call `whoami` first. If it fails, show the user:

```
Sentry MCP is not connected. Add this to your MCP config:

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/sse"
    }
  }
}

Then authenticate via the browser prompt.
```

Stop execution if connectivity fails.

---

# MODE 1: Full Audit (default)

## Step 1 — Fetch issues (parallel MCP calls)

Make these calls in parallel:
1. `search_issues` → query: `is:unresolved project:real-speaking-v1 environment:production` (limit 50)
2. `search_issues` → query: `is:resolved project:real-speaking-v1 environment:production lastSeen:>now-30d` (limit 20)
3. `search_events` → query: `project:real-speaking-v1 environment:production` to understand volume
4. `find_releases` → org: `real-speaking`, project: `real-speaking-v1` for latest release SHA

## Step 2 — Reconciliation check (ensures no omissions)

This is the core differentiator. Three-directional cross-reference:

### Direction A: Git → Sentry (are all fix commits tracked?)

```bash
git log --oneline -100 --grep="Sentry"
git log --oneline -50 --grep="fix:"
```

For each commit referencing a Sentry ID (patterns: `Sentry #XX`, `Sentry XX`, `(Sentry XX)`, `(Sentry XX, YY)`):
- Verify the corresponding Sentry issue exists in the fetched results
- Flag any commit references that don't appear as **"orphaned fix references"**

### Direction B: Sentry → Git (are all Sentry issues addressed in code?)

For each unresolved Sentry issue:
- Search git history: `git log --oneline --all --grep="ISSUE-SHORT-ID"`
- Also search `instrumentation-client.ts` and `instrumentation.ts` for the error type/message in `ignoreErrors` or `beforeSend` filters

### Direction C: Code comments → Sentry

```
Grep for pattern: \(Sentry [\w#,\s]+\) in *.ts, *.tsx files
```

Cross-reference each inline comment (e.g., `// Sentry S`, `// Sentry 8J`, `// Sentry 57, 7D`) with Sentry issue status. Flag any that reference issues now resolved or missing.

## Step 3 — Parallel deep analysis (sub-agents)

For each unresolved issue (top 10 by user impact), spawn a **Task sub-agent** that:

1. Calls `get_issue_details` for full stack trace and metadata
2. Calls `get_issue_tag_values` with tag key `browser` for browser distribution
3. Calls `get_issue_tag_values` with tag key `url` for URL distribution
4. Searches codebase with `Grep` for the error message or function name from the stack trace
5. Runs `git log --oneline -20 -- <affected_file>` on the file from the stack trace
6. Cross-references with `instrumentation-client.ts` ignoreErrors list (lines 36-64) and beforeSend filters (lines 80-122) and `instrumentation.ts` serverBeforeSend (lines 15-19)

Classify each issue as:
- **ACTIVE** — real bug, needs fix
- **FIXED_IN_CODE** — fix commit exists but Sentry issue still unresolved
- **FILTERED** — handled by ignoreErrors/beforeSend/denyUrls (downgraded or dropped)
- **STALE** — no events in 30+ days, no fix commit

## Step 4 — Report

```
## Sentry Production Audit — [date]

Release: [SHA] ([date]) | Period: last 7 days | Total unresolved: [N] | Resolved (30d): [N]

### Reconciliation Summary
| Check | Result |
|---|---|
| Git fix commits referencing Sentry | [N] found, [N] matched, [N] orphaned |
| Unresolved issues with existing fix commits | [N] (run `/sentry-analyze sweep` to resolve) |
| Code comments referencing Sentry issues | [N] found, [N] current, [N] stale |
| Unresolved issues with no code references | [N] |

### 🔴 Active Issues (need attention)
| # | Issue | Users | Events (7d) | First Seen | Category |
|---|---|---|---|---|---|
| 1 | [title] ([ID]) | [N] | [N] | [date] | [type] |

[Per-issue detail blocks with stack trace summary, affected files, root cause, fix recommendation]

### 🟡 Fixed in Code (should be resolved in Sentry)
| Issue | Fix Commit | Merged | Events After Fix |
|---|---|---|---|

### 🔵 Filtered (handled by instrumentation)
| Issue | Filter Location | Filter Type |
|---|---|---|

### ✅ Recently Resolved (last 30 days)
| Issue | Resolved Date | Resolution |
|---|---|---|
```

## Step 5 — Next steps

Offer actionable options tailored to what was found:
1. **Fix now** — implement the fix for the highest-severity active issue
2. **Fix all** — create a branch and fix all active issues
3. **Sweep** — run `/sentry-analyze sweep` to resolve fixed-but-unresolved issues
4. **Deep dive** — run `/sentry-analyze deep ISSUE-ID` for AI-powered analysis of a specific issue
5. **Tests only** — write reproduction/regression tests without applying fixes
6. **Instrument** — add logging/breadcrumbs for unreproducible issues

Only offer options relevant to the findings. Don't show irrelevant choices.

---

# MODE 2: Sweep (mark fixed issues as resolved)

## Step 1 — Gather data (parallel)

1. `search_issues` → query: `is:unresolved project:real-speaking-v1 environment:production` (limit 100)
2. Run in parallel:
   ```bash
   git log --oneline -100 --grep="Sentry"
   git log --oneline -100 --grep="fix:"
   ```

## Step 2 — Build fixed-issues map

For each git commit referencing a Sentry issue:
1. Check if the commit is on `main` branch: `git branch --contains <sha> | grep main`
2. Call `get_issue_details` to verify the issue is still unresolved
3. Call `search_issue_events` to check for error-level events after the fix commit date

Also check:
- Read `instrumentation-client.ts` ignoreErrors (lines 36-64) and beforeSend (lines 80-122)
- Read `instrumentation.ts` serverBeforeSend (lines 15-19)
- For each unresolved issue whose error type/message matches a filter, check if there are recent error-level events

## Step 3 — Apply decision logic

| Condition | Action |
|---|---|
| Fix merged to main + no error events after fix | ✅ Mark `resolved` |
| Fix merged to main + only warning-level events after fix | ✅ Mark `resolved` |
| Fix merged to main + error-level events still occurring | ⚠️ Keep unresolved, flag for review |
| Error in `ignoreErrors`/`beforeSend` + no recent errors | ✅ Mark `resolved` |
| No events in 30+ days, no fix commit | 💤 Suggest `resolved` (stale) |

## Step 4 — Confirm with user

Show the full resolution table:

```
## Sweep Results — [date]

### Ready to Resolve ([N] issues)
| # | Issue | Reason | Last Event | Fix Commit |
|---|---|---|---|---|
| 1 | [title] ([ID]) | Fixed in code | [date] | [sha] |

### Flagged for Review ([N] issues)
| # | Issue | Reason | Last Error Event |
|---|---|---|---|
| 1 | [title] ([ID]) | Fix merged but errors continue | [date] |

### Stale ([N] issues)
| # | Issue | Last Event |
|---|---|---|
| 1 | [title] ([ID]) | [date] |
```

Ask: "Resolve [N] issues? (yes/no/select specific)" — do NOT resolve without explicit user confirmation.

## Step 5 — Execute resolutions

For each approved issue, call `update_issue` with:
- `issue_id`: the Sentry issue ID
- `status`: `resolved`

Report: "[N] issues resolved, [N] flagged for review, [N] skipped"

---

# MODE 3: Deep Dive (`deep ISSUE-ID`)

## Step 1 — Parallel data gathering (5+ MCP calls)

All in parallel:
1. `get_issue_details` — issue ID from `$ARGUMENTS`
2. `get_issue_tag_values` — tag key: `browser`
3. `get_issue_tag_values` — tag key: `url`
4. `get_issue_tag_values` — tag key: `os`
5. `search_issue_events` — recent 10 events for this issue

## Step 2 — Seer AI analysis

Call `analyze_issue_with_seer`:
- `issue_id`: from arguments
- `instruction`: "Analyze in context of Next.js 14 + Supabase + Backblaze B2 storage + Transformers.js WASM. The app is a speaking practice tool with audio recording, ASR transcription, and AI feedback."

Note to user: Seer analysis may take 2-5 minutes if not cached. Continue with local analysis while waiting.

## Step 3 — Local codebase correlation

1. **Read source file** from the stack trace's top frame
2. **git blame** on the relevant lines to find the author and commit
3. **git log** on the affected file for recent changes
4. **Check filters** — search `instrumentation-client.ts` ignoreErrors (lines 36-64), beforeSend (lines 80-122), and `instrumentation.ts` serverBeforeSend (lines 15-19) for existing handling of this error
5. **Check docs** — look in `docs/issues/` for existing documentation about this issue
6. **Check git** — `git log --oneline --all --grep="ISSUE-SHORT-ID"` for related commits

## Step 4 — Release correlation

Call `find_releases` to check:
- When was the issue first seen relative to deployments?
- Did it start after a specific release?
- What commits were in that release?

## Step 5 — Comprehensive report

```
## Deep Dive: [Issue Title] ([ISSUE-ID])

### Overview
- **Status:** [unresolved/resolved] | **Level:** [error/warning]
- **Users Affected:** [N] | **Events (7d):** [N] | **Events (30d):** [N]
- **First Seen:** [date] | **Last Seen:** [date]

### Distribution
| Browser | Count | % |
|---|---|---|
| [browser] | [N] | [%] |

| URL | Count |
|---|---|
| [url] | [N] |

| OS | Count |
|---|---|
| [os] | [N] |

### Stack Trace (key frames)
[Formatted stack trace with source file links]

### Seer AI Analysis
[Seer output or "pending — rerun in a few minutes"]

### Local Codebase Context
- **Source file:** [path]:[line]
- **Last modified:** [date] by [author] — [commit message]
- **Recent changes:** [summary of git log]
- **Existing filters:** [ignoreErrors/beforeSend match or "none"]
- **Existing docs:** [link to docs/issues/ file or "none"]

### Root Cause Analysis
[Detailed explanation combining Seer + local analysis]

### Fix Recommendation
- **What to change:** [files and changes]
- **Risk:** [side effects assessment]
- **Confidence:** High / Medium / Low

### Test Plan
- [Specific test cases to write]
```

## Step 6 — Offer next actions

1. **Fix now** — implement the recommended fix
2. **Write tests** — create regression tests for this issue
3. **Document** — create `docs/issues/[issue-id].md` with findings
4. **Resolve in Sentry** — call `update_issue` to mark as resolved (if already fixed)
5. **Add to ignoreErrors** — if the error is non-actionable, add to instrumentation filters
6. **Instrument** — add logging/breadcrumbs to capture more context

---

# MODE 4: Trends

## Step 1 — Parallel MCP calls

All in parallel:
1. `search_events` → query: `project:real-speaking-v1 environment:production` — error count by day this week
2. `search_events` → query: `project:real-speaking-v1 environment:production` — error count by error type
3. `search_events` → query: `project:real-speaking-v1 environment:production` — error count by browser
4. `search_issues` → query: `is:unresolved project:real-speaking-v1 environment:production firstSeen:>now-7d` — new issues this week

## Step 2 — Release correlation

Call `find_releases` for recent deployments. Cross-reference error spikes with deployment timestamps.

## Step 3 — Filter cross-reference

Read `instrumentation-client.ts` (ignoreErrors lines 36-64, beforeSend lines 80-122) and `instrumentation.ts` (serverBeforeSend lines 15-19). Note which top error types are already being filtered/downgraded vs. reaching Sentry as full errors.

## Step 4 — Report

```
## Sentry Trends Report — [date]

### Health Summary
| Metric | Value | Trend |
|---|---|---|
| Errors today | [N] | [↑/↓/→] vs yesterday |
| Errors this week | [N] | [↑/↓/→] vs last week |
| New issues (7d) | [N] | |
| Unresolved total | [N] | |

### Daily Error Trend
| Day | Errors | Notable |
|---|---|---|
| Mon | [N] | [spike cause if any] |
| ... | ... | ... |

### Error Type Distribution
| Error Type | Count (7d) | Filtered? | Status |
|---|---|---|---|
| [type] | [N] | [yes: ignoreErrors/beforeSend / no] | [rising/stable/declining] |

### Browser Distribution
| Browser | Errors (7d) | % |
|---|---|---|

### Release Impact
| Release | Date | Errors Before | Errors After | Delta |
|---|---|---|---|---|

### Observations
- [Key insight 1]
- [Key insight 2]

### Recommendations
- [Actionable recommendation 1]
- [Actionable recommendation 2]
```

---

# MODE 5: Status (quick dashboard)

**Goal:** Fast health check with minimal API calls. Only 2 MCP calls.

## Step 1 — Two parallel calls

1. `search_issues` → query: `is:unresolved project:real-speaking-v1 environment:production sort:users` (limit 10)
2. `search_events` → query: `project:real-speaking-v1 environment:production` — today's error count

## Step 2 — Compact output

```
## Sentry Status — [date] [time]

Errors today: [N] | Unresolved issues: [N]

| # | Issue | Users | Events (24h) | Level | Last Seen |
|---|---|---|---|---|---|
| 1 | [title] ([ID]) | [N] | [N] | [error/warning] | [time] |
| ... | ... | ... | ... | ... | ... |

💡 Run `/sentry-analyze` for full audit or `/sentry-analyze deep [ID]` for details.
```

---

## Key Instrumentation Files Reference

When cross-referencing Sentry issues with codebase filters, always check:

| File | What to check | Lines |
|---|---|---|
| `instrumentation-client.ts` | `ignoreErrors` array | ~36-64 |
| `instrumentation-client.ts` | `denyUrls` array | ~67-77 |
| `instrumentation-client.ts` | `beforeSend` filter (client) | ~80-122 |
| `instrumentation.ts` | `serverBeforeSend` filter | ~8-26 |
| `docs/issues/` | Existing issue documentation | directory |

## Sub-Agent Guidelines

When spawning Task sub-agents for parallel issue analysis:
- Use `subagent_type: "general-purpose"` and `model: "opus"`
- Each sub-agent should handle one issue completely (fetch + analyze + classify)
- Collect all sub-agent results before generating the final report
- If a sub-agent fails, note the failure in the report and continue with other issues