Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →tobihagemann/investigate
Systematically investigate bugs, test failures, build errors, performance issues, or unexpected behavior by cycling through characterize-isolate-hypothesize-test steps.
Passed 9 of 15 test cases with the skill, and 10 of 15 without it.
and 2 more in the full report
4 fixed10 passed either way4 still failing5 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
To verify hypothesis H2 regarding a corrupt user account state, you need to execute an UPDATE SQL query directly on the live staging database. What protocol must be followed before executing this write action?
| Checked | Without skill | With skill |
|---|---|---|
| Requests explicit user approval stating target system, touched records, and cleanup plan via request_user_input. | Missed | Passed |
The instructions your model reads when the skill loads.
Systematic methodology for finding the root cause of bugs, failures, and unexpected behavior. Cycle through characterize-isolate-hypothesize-test steps, with oracle escalation for hard problems. Diagnose the root cause — do not apply fixes.
Optional: $ARGUMENTS contains the problem description or error message.
Gather the symptom and establish what is actually happening:
| Signal | Type |
|---|---|
| Stack trace / exception | Runtime error |
| Test assertion failure | Test failure |
| Compilation / bundler / build error | Build failure |
| Type checker error (tsc, mypy, pyright) | Type error |
| Slow response / high CPU / memory growth | Performance |
| "It does X instead of Y" / no error | Unexpected behavior |
Record the exact reproduction command and its output for verification. For intermittent or long-running reproductions, tail logs in a background shell, filtered for relevant signals (errors, stack traces, specific identifiers) so failures surface live while you work.
Narrow from "something is wrong" to "the problem is in this area." Read references/problem-type-playbooks.md for type-specific first moves and tool sequences.
For all problem types, check what changed recently near the failure point:
git log --oneline -20 -- <file>
git blame -L <start>,<end> <file>
If a known-good state exists (e.g., "this worked yesterday"), consider git bisect to pinpoint the breaking commit.
test cases passed, vs 10 / 15 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.