Steadwing Agent Skill: Debug Root Cause From Your Terminal

An incident usually reaches you as a paragraph of text. Someone pastes a stack trace into a channel and asks whether anyone recognises it.

That paragraph already names the file. It names the function. It names the line. And then somebody spends the next twenty minutes finding out what that line says.

That gap is what this post is about. We shipped an Agent Skill to close it.

The Lookup Nobody Counts as Work

Say a billing service stops charging a subset of subscriptions, and this comes back:

Traceback (most recent call last):

  File "src/billing/service.py", line 45, in charge_subscription

    intent = gateway.create_intent(customer, plan["amount_cents"])

  File "src/billing/gateway.py", line 112, in create_intent

    return self._post("/v1/payment_intents", payload)

  File "src/billing/gateway.py", line 203, in _post

    raise GatewayError(resp.json()["error"]["message"])

billing.gateway.GatewayError: amount must be a positive integer

Your monitoring knows a lot about this. Error rate on the endpoint, latency, which region, which build, how many customers went uncharged. All of it true, and none of it the reason.

What it can't tell you is why plan["amount_cents"] arrived as a zero, because that answer lives in two source files and your monitoring has never read either one. It reads logs, metrics and traces.

It doesn't read your repository.

So the one artifact that explains the bug is the one artifact none of your tools have opened.

Which leaves exactly one thing in the incident holding both halves of the problem, and it's the person who goes and opens the file.

How This Normally Goes

Someone notices the failed charges. Someone opens the APM and sees the error rate, which confirms the thing everyone already knows. Someone else starts scrolling the day's deploys.

On a small team it's all the same person. They read the trace, find the repo, find

service.py, read charge_subscription, work out where plan comes from, go and read the code that builds it, then go back through the last few commits touching any of it. None of that is hard.

All of it is retrieval, and it takes twenty minutes while charges are still failing.

Then they come out the other side with two or three explanations that fit equally well, which is the worst place to be, because each one has to be checked before it's safe to act on.

We've written before that roughly 70% of incident response time goes to coordination rather than engineering. This is the quieter version of that number. Nobody logs "I read the code" as waste. It looks like work. It looks exactly like work.

How It Goes With the Skill

Your engineers already work inside a coding agent. Claude Code, Cursor, Windsurf, whichever one your team settled on. That agent is already in the repository, with the file tree, the git history and read access to every line.

It's the only tool in the incident that has the other half.

So that's what the skill uses. Paste the trace into your agent and ask what happened. The skill reads the frames, opens the files they name, src/billing/service.py and src/billing/gateway.py, and sends them with the error log. Root cause analysis comes back in one to three minutes with an incident link.

It gets better once your account is connected to your observability and infrastructure, because then the code isn't read in isolation. The analysis lines it up against your own data for that window, the logs while the charges were failing and the deploys that went out beforehand. The finding stops being that plan["amount_cents"] can be zero and becomes that this file changed in that deploy, and the failures start where the deploy lands. That correlation is the difference between a stack trace and an answer.

Two details for whoever has to approve this. There's no signup and no API key to paste, the skill registers itself on first run and you link it to your account afterwards. And it sends the log plus the handful of files the trace implicates, capped at five to ten. Never the repository.

What the Lookup Actually Costs

The number worth caring about here isn't the twenty minutes. It's how many wrong holes you dig.

That's the part that's hard to appreciate until you've skipped it. The twenty minutes of retrieval don't just cost twenty minutes, they end with two or three plausible theories and no way to choose between them. One of those gets acted on. Sometimes it's the wrong one, and then you've optimised a query that was fine, or rolled back a deploy that was innocent, and you're back where you started with less time and more people watching.

Arriving with the code already read doesn't make anyone a better debugger. It just means the first thing you do is the right thing.

You Don't Have to Paste It

The skill ships a detection hook. When a production-style traceback shows up in your agent's output, it notices and asks whether you want the analysis run.

It only detects and asks. It never sends anything without you saying yes, which is the first question your security review is going to have, so it's worth being plain about.

Installing it is one line, npx skills add steadwing/agent-skills, and it works with Claude Code, Cursor, Windsurf and 18 others off the same repo. Claude Code users can install it as a native plugin instead if you'd rather not go through the CLI.

Your agent already knows where the file is. Let it say so.

Want your alerts to arrive solved? Check it out here.

Github: Agent Skill repo.