Find the cause before writing the fix

The failure this is for

An agent handed a stack trace patches the line the stack trace names. It adds a null check at the crash site, or wraps the failing call in a try, or coerces the input. Tests pass, the ticket closes, and the same defect returns in a fortnight under a different trace, because the actual defect was three calls upstream in a state transition nobody logged.

This is not a reasoning failure. The trace is genuinely the only evidence in the context window, and the crash site is genuinely the only place in it that looks wrong. The fix is to put the other evidence in the room.

The failure	What it looks like	What answers it
Guessing the repro	works on my machine, one browser away	real events, frequency, replay
Removing a fence	"simplifies" a workaround, reopens the incident	the pull request that added it
Patching the symptom	a null check at the crash site	a procedure — see "What is not here"
Believing it is fixed	ran it once by hand	a test that was red first — same

Two kinds of evidence, and why the second one is the one people skip

Sentry says what happened. GitHub says why the code is shaped the way it is. Those are different questions, neither is answerable from the trace, and no single tool answers both. That is the argument for a pair rather than a favourite tool.

Reaching for the error monitor is the obvious half. The trace in the ticket is one frame of a film, and the monitor has the rest of it: how many users, which tenants, whether it started at a deploy, what the session did just before. An agent working from the pasted trace alone is reasoning about a still.

The half people skip is the second. An agent with live telemetry has excellent vision and no memory. It sees the present state of the code and nothing about how the code got that way, so every unusual line is equally suspicious and the deliberate ones get tidied away. Chesterton's fence is the standard reference and it undersells the problem: the agent is not choosing to remove a fence it cannot explain. It cannot see that the fence is a fence. The pull request that added the odd conditional says why in its title, and that sentence exists nowhere in the working tree.

Run them in that order. What happened, then why the code is like that, then write the fix.

The item that is not in this stack

The best-fitting tool for step two is not the one in step two.

There is an MCP server called wisegit that does exactly the job this stack needs: it parses git history at the AST level rather than as line diffs, classifies commits by intent, and assigns each function a freeze score, so a function whose current shape was the resolution of a prior incident comes back marked as one an agent may not quietly modify. Its tagline is the Chesterton line. It is a better answer to step two than reading pull request titles, and it is the only tool found here built for that question specifically.

It has one star.

That is not a judgment about the software, which may well be good. It is the rule this catalog runs on: an install command is a recommendation that somebody grant a process access to their repository, and a one-star project asking to read your entire commit history is not something to hand out on the strength of a well-written README. So step two uses the GitHub server, which answers the same question less precisely and has thirty-two thousand stars and an owner who is the host.

The rule costs something here, and saying what it costs is more useful than pretending the substitution was free.

What is not here, and it used to be

Checked 2026-08-13.

This page had five items. Three are gone, and the two that carried the actual procedure are among them, so the page now describes half of what it used to. Saying which half is missing is more useful than quietly shipping a shorter list.

The procedure, at both ends. Steps one and five were rohitg00/skillkit: a root-cause-analysis pack that ordered the investigation, and a red-green-refactor pack that turned the reproduction into a regression test. They bracketed the stack on purpose, diagnosis at one end and proof at the other.

Symbol-level reading. Step three was Serena, for finding the other callers of the function you are about to change.

Every stack in this directory then went through one grounded question: does any public source describe somebody running this combination, rather than these tools individually. This one returned the sharpest answer in the set.

• Sentry MCP with the GitHub MCP server, in an incident-to-pull-request workflow — but the procedure layer is Sentry's own sentry-code-review skill, not skillkit, and Serena is absent.
• Sentry MCP with a GitHub workflow driven by the gh CLI rather than the MCP server. Again no skillkit, no Serena.
• Sentry MCP again with gh pr create. Same shape.
• Serena, in a daily stack that is Serena plus Playwright MCP plus Superpowers plus Context7 — a codebase-reading stack, with no error monitor in it at all.
• All five items named together exactly once, in this catalog's own entry. No independent adopter.

That last line is the finding. The only source describing the five-item stack was us.

Two further things the search reported. Sentry now ships its own skills and Seer, which occupy the root-cause layer skillkit was here for, from inside the tool that already holds the evidence. And running several MCP servers together has a documented context cost that lands before any investigation starts, which penalises the long version of this stack specifically.

So the pair stays and the procedure layer does not get replaced with another guess. If you want the bracket back, Sentry's own review skill is where the evidence points, and this page will name it once somebody here has run it.

claude mcp add sentry -- npx -y @sentry/mcp-server