Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add duthaho/claudekit --skill investigate-root-causegit clone --depth 1 https://github.com/duthaho/claudekitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/duthaho/claudekit/investigate-root-cause)<a href="https://agentmods.dev/skills/duthaho/claudekit/investigate-root-cause"><img src="https://agentmods.dev/badge/skills/duthaho/claudekit/investigate-root-cause/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/duthaho/claudekit/investigate-root-cause"><img src="https://agentmods.dev/badge/skills/duthaho/claudekit/investigate-root-cause.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00121 | $0.02927 |
| Opus 5 | $0.00060 | $0.01463 |
| Sonnet 5 | $0.00024 | $0.00585 |
| Haiku 4.5 | $0.00012 | $0.00293 |
Grade A, and why
investigate-root-cause scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 195 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Investigate Root Cause
Overview
A four-phase debugging workflow that forces an engineer to gather evidence and write down a hypothesis before changing any code. The skill exists because the most common debugging failure isn't a missing technique — it's the engineer skipping past the error message, forming a vague mental theory, and patching the symptom. Every phase here produces an artifact you could paste into a code review. If you can't produce the artifact, you haven't done the phase. The skill is for senior ICs and tech leads who already know how to debug; what it adds is the discipline to refuse to fix what you don't yet understand.
When to Use
- A test is failing and you don't already know why
- An error message appeared that you cannot immediately point to a line of code for
- A reproduction is intermittent (sometimes passes, sometimes fails)
- A previously passing system started failing after no obvious cause
- Production is misbehaving and the cause isn't in the most recent commit
- You catch yourself about to write a fix while still uncertain why the bug happens
When NOT to Use
- The error message names a missing import, typo, or syntax error and the fix is one character. Just fix it.
- The runbook for this exact failure exists and the documented fix has been applied before. Follow the runbook.
- The "bug" is a config value that needs flipping in an environment variable. Flip it.
Process
Four phases. Each phase has a gate. You do not advance until the gate's evidence artifact exists.
Phase 1: Gather
Goal: Surface every fact that already exists about this bug, before forming any theory.
Inputs: A bug report, a failing test, an error message, or a complaint ("it doesn't work").
Actions:
- Capture the literal error. Copy the full text of the error message and the complete stack trace. Do not paraphrase. If there is no error message, write down the exact observed-vs-expected behavior in one sentence each.
- Find the reproduction. Run the failing scenario yourself. Record the exact command, environment, and inputs. If you cannot reproduce it, that is the bug to investigate first — go to Step 3 and Step 4 and stay in Phase 1 until you can.
- Read recent history. Run
git log --oneline -30and read the last 30 commits. Note which commits touch files in the stack trace. - Collect logs. Pull logs around the failure window. If structured logs exist, filter to the request or session that hit the bug. If not, raise the verbosity and re-run the reproduction.
- Look at the data. If the bug involves a record, fetch the record. If it involves a query, run the query. If it involves a request body, capture the body.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 195 lines · 121 tokens per session scan A 0f2ea68f1362
investigate-root-cause is a skill published in the GitHub repository duthaho/claudekit (97 stars, last pushed 1mo ago), licensed MIT. It adds 121 tokens to every session and 2,927 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
debug-systematic
Systematic 4-phase debugging methodology for complex, intermittent, or mysterious issues. Use when investigating bugs, race conditions, or unexplained failures.
healthcheck
System health monitoring and diagnostics - checks profClaw API, Redis, Docker, disk, memory, and processes with actionable status reports.
debug-helper
Analyze errors and stack traces, trace through code execution, and suggest targeted fixes.
system-admin
System diagnostics, process management, disk and memory checks, and service health monitoring.
manage-skills
A maintenance workflow for checking whether project verification skills still cover the code and rules that changed during a session.
systematic-debugging
Structured debugging methodology — use before proposing fixes for any error or failure. Covers: code bugs, build errors, deploy failures, config conflicts, dependency issues, infra problems. Also use when previous fix attempts failed or root cause is unclear.