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 JKHeadley/instar --skill systematic-debugginggit clone --depth 1 https://github.com/JKHeadley/instarWrote 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/jkheadley/instar/systematic-debugging)<a href="https://agentmods.dev/skills/jkheadley/instar/systematic-debugging"><img src="https://agentmods.dev/badge/skills/jkheadley/instar/systematic-debugging/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/jkheadley/instar/systematic-debugging"><img src="https://agentmods.dev/badge/skills/jkheadley/instar/systematic-debugging.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.00000 | $0.02153 |
| Opus 5.5 | $0.00000 | $0.00861 |
| Sonnet 5.5 | $0.00000 | $0.00431 |
| Haiku 4.5 | $0.00000 | $0.00215 |
Grade A, and why
systematic-debugging 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 1mo 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 — 223 lines — stays where its author put it; the contents beside it link to each section on GitHub.
systematic-debugging — Structured Root Cause Analysis for Agents
When something breaks, the instinct is to start changing code — adding logs, tweaking values, commenting things out. This is probing, not debugging. Probing works sometimes, but it scales poorly and teaches nothing. Structured debugging finds the root cause, fixes it once, and leaves you understanding why.
This skill enforces a 4-phase process. You do NOT skip phases. You do NOT jump to a fix before completing Phase 2. Each phase has a clear deliverable that must exist before the next phase begins.
When to Activate This Skill
Use this skill when:
- An error occurs and the cause is not immediately obvious (> 30 seconds of uncertainty)
- A test fails and you don't know exactly why
- Something that was working has stopped working
- The user reports unexpected behavior
- You've already tried one fix and it didn't work (this is the clearest signal — stop guessing, start debugging)
- A job or scheduled task is failing silently
- Behavior differs between environments (local vs production, different machines)
Do NOT use this skill for:
- Typos, missing imports, or syntax errors with clear error messages pointing to the exact line
- Known issues with documented fixes
- Configuration that just needs to be set
Phase 1: Identify — What exactly is broken?
Goal: Establish the precise boundary between "works" and "doesn't work."
Steps:
-
Reproduce the failure. Run the exact command, API call, or user action that triggers the bug. Capture the FULL output — error messages, stack traces, logs, HTTP status codes.
-
Establish the expected behavior. What SHOULD happen? Check documentation, tests, previous working state, or ask the user. Write it down explicitly.
-
Narrow the scope. Answer these questions:
- When did it last work? (Check git log, deployment history, recent changes)
- What changed since then? (
git diff,git log --oneline -10, env var changes, dependency updates) - Is it consistent or intermittent?
- Does it affect all cases or specific inputs?
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.
- 1mo ago First seen · 223 lines · 0 tokens per session scan A 445529828b83
systematic-debugging is a skill published in the GitHub repository JKHeadley/instar (84 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,153 tokens. 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
debugging-typescript-errors
Systematically investigates TypeScript compiler errors, traces the real type mismatch, and applies a minimal verified fix. Use when the user wants to debug TypeScript type errors.
simplify
Use after writing or modifying code to improve its clarity, reuse, simplicity, and efficiency without changing behavior. Not for finding correctness bugs — that is code review.
typescript-circular-dependency
Detect and resolve TypeScript/JavaScript circular import dependencies. Use when: (1) "Cannot access 'X' before initialization" at runtime, (2) Import returns undefined unexpectedly, (3) "ReferenceError: Cannot access X before initialization", (4) Type errors that disappear when you change import order, (5) Jest/Vitest…
build-error-resolver
Build and TypeScript error resolution specialist. Use PROACTIVELY when build fails or type errors occur. Fixes build/type errors only with minimal diffs, no architectural edits. Focuses on getting the build green quickly.
migrate-oxlint
Guide for migrating a project from ESLint to Oxlint. Use when asked to migrate, convert, or switch a JavaScript/TypeScript project's linter from ESLint to Oxlint.
browser-edge-cases
SOP for debugging browser automation failures on complex websites. Use when browser tools fail on specific sites like LinkedIn, Twitter/X, SPAs, or sites with Shadow DOM.