In-house flow
Find the cause before writing the fix
A stack trace tells you where the program died, not where it went wrong. Five items that supply four different kinds of evidence, in the order an investigation actually needs them, and a test at the end that can say no.
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 |
|---|---|---|
| Patching the symptom | a null check at the crash site | a procedure with a verify phase |
| Guessing the repro | works on my machine, one browser away | real events, frequency, replay |
| Reading one file | fixes one caller, breaks two | symbol-level references |
| Removing a fence | "simplifies" a workaround, reopens the incident | the pull request that added it |
| Believing it is fixed | ran it once by hand | a test that was red first |
The four kinds of evidence, and why they are four
Sentry says what happened. Serena says what the code does. GitHub says why the code is that way. Those are three different questions and no tool answers two of them, which is the whole argument for a stack rather than a favourite tool.
The step people skip is the fourth. An agent with telemetry and semantic search has excellent vision and no memory: both of those tools only see the present, so every unusual line is equally suspicious and the deliberate ones get tidied away. Chesterton's fence is the standard reference here and it undersells the problem, because the agent is not choosing to remove a fence it cannot explain. It cannot see that the fence is a fence.
The two skills bracket the whole thing on purpose, and they are not the same step twice. The reproduction in step one is exploratory: get it to happen once, by hand, to learn something. The reproduction in step five is an artifact: the same knowledge written as a test that stays in the suite and fails if anyone undoes the fix. Diagnosis at one end, proof at the other.
The item that is not in this stack
The best-fitting tool for step four is not the one in step four.
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 four 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 four uses the GitHub server, which answers the same question less precisely and has thirty-one 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.
Set it all up
3 of 5, in order
npx -y skills add rohitg00/skillkit --skill root-cause-analysis
claude mcp add sentry -- npx -y @sentry/mcp-server
npx -y skills add rohitg00/skillkit --skill red-green-refactorSome of these are the commands their projects publish and some are assembled from repository paths. Each one is labelled where it appears below. Nobody here has run them as a set.
How it goes
Their working order, our numbers
First, because everything below happens out of order without it. Reproduce, gather, hypothesise, test, verify, and a rule that reads like a slogan until you have watched an agent violate it: never fix a symptom. Its best line is the tell it names, "I am not sure why, but this fix works", which is the sentence an agent produces right before it closes a ticket that will reopen.
Root cause analysisSkill
rohitg00/skillkit/packages/core/src/methodology/packs/debugging/root-cause-analysis1,405★ repoApache-2.0
npx -y skills add rohitg00/skillkit --skill root-cause-analysisAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
Then find out what actually happened, rather than what the ticket says happened. One trace pasted into an issue is a single frame of a film. Whether it is one tenant or ten thousand, whether it began at a deploy, and what the user did just before, are all the difference between a plausible hypothesis and the right one.
Sentry mcpMCP server
getsentry/sentry-mcp/io.github.getsentry/sentry-mcp804★ repono licenseno license
claude mcp add sentry -- npx -y @sentry/mcp-serverAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
Then read what the code does now, at the symbol level rather than the file the traceback happened to name. The specific save here is finding the other callers of the function you are about to change. An agent that reads one file fixes one file and breaks two.
Serena MCP: the IDE for your agentMCP server
oraios/serena/io.github.oraios/serena27,343★ repoMIT
No install line here. This server does not publish one we could copy, and it has no package name recorded, so anything shown here would be a guess at whether it runs from npm, PyPI, a container or a hosted URL.
The repository will have the real instructions: github.com/oraios/serena
Then find out why the code is shaped like that, which is the step that stops the fix from being a regression. The odd conditional you are about to simplify is usually a scar. The pull request that introduced it says so in its title, and that sentence exists nowhere in the working tree.
GitHubMCP server
github/github-mcp-server/io.github.github/github-mcp-server31,881★ repoMIT
No install line here. This server does not publish one we could copy, and it has no package name recorded, so anything shown here would be a guess at whether it runs from npm, PyPI, a container or a hosted URL.
The repository will have the real instructions: github.com/github/github-mcp-server
Last, and it is the same reproduction from step one turned into something permanent. Write the test, watch it fail, then fix. Its checklist insists the new test actually fails when the fix is removed, which is the check that separates a regression test from a test that has never once been red.
Red green refactorSkill
rohitg00/skillkit/packages/core/src/methodology/packs/testing/red-green-refactor1,405★ repoApache-2.0
npx -y skills add rohitg00/skillkit --skill red-green-refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
More of these
Stacks are written by hand and there are not many. The catalog underneath is large, and its default ordering puts whatever has been picked at the front.