# SentryFixer: reading a Sentry error against the code and drafting the fix

> A Claude Code skill that reads a Sentry issue against the working tree and proposes a fix as a diff and a regression test, touching no file until approved.

- What it does today: Reads a Sentry issue against the working tree, produces a root-cause analysis and a fix plan, and touches no file without explicit approval. Anyone using Claude Code who needs to triage a production error can install the skill.
- Form: Open source
- Maturity: Release candidate
- State: Stable
- Focus: AI-assisted development
- Started: 2026-07-01
- Technologies: Python, Bash, Sentry API, sentry-cli, MCP, Claude Code
- Tags: #ai, #debugging, #automation
- Source code: https://github.com/muhammetsafak/SentryFixer.Skill
- Source: https://www.muhammetsafak.com.tr/en/labs/sentryfixer/
- Language: en-US
- Author: Muhammet Şafak

---
The gap between error monitoring and the fix always sits in the same place:
Sentry tells you what blew up, but working out how that line looks today,
whether the code path changed since the error, and what a fix might break is
still on you. SentryFixer is the Claude Code skill I wrote to automate that
middle step.

## Four steps from event to fix plan

Given a Sentry issue, the skill runs through:

1. Compressing 50–300 KB of event data into a redacted summary.
2. Mapping stack trace frames onto the real source files in the working tree.
3. Checking freshness — whether the failing code changed since the error fired.
4. Reasoning about the root cause and proposing a concrete fix with tests.

The strict part comes last: **no file changes until the plan is approved.** No
automatic commits, no git operations beyond read-only history. Once approved,
the diff is applied, the tests run, and the result is reported as-is.

## Narrow dependencies, hard approval gate

The dependency surface is deliberately narrow: Python 3.8+ with the standard
library only, plus `curl`/bash. There are three ways into Sentry — the API
directly, `sentry-cli` or the Sentry MCP server — whichever is available. MIT
licensed, repository public.

Two decisions sit at the centre of the design. First, **context compression**:
raw event data never goes to the model as-is; it is reduced to the frames that
matter, and personal data is redacted at that step. Second, the **approval
gate**: the skill's write access stays shut until someone reads the plan and
says go.

## The limit of the freshness check

The open question on the bench: freshness currently checks whether the file
changed. What I actually want is a verdict on how much the diff between the
error's commit and today's code touches the root cause. That is the next round.