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

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.