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 agentmods add skills/jkheadley/instar/systematic-debuggingnpx skills add JKHeadley/instar --skill systematic-debugginggit clone --depth 1 https://github.com/JKHeadley/instarWhat 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 | $0.00084 | $0.02153 |
| Opus 5 | $0.00042 | $0.01077 |
| Sonnet 5 | $0.00017 | $0.00431 |
| Haiku 4.5 | $0.00008 | $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 2d 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.
- 2d ago First seen · 223 lines · 0 tokens per session scan A 445529828b83
systematic-debugging is a skill published in the GitHub repository JKHeadley/instar (77 stars, last pushed 2d ago), licensed MIT. It adds 84 tokens to every session and 2,153 once invoked, about $0.0004 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
kungfu-agent-onboarding
Discover the exact Kungfu Project, WorkConsole, WorkRef, Skill catalog, and Core Work state admitted to this Amp process.
kungfu-agent-onboarding
Use when a user asks to understand, start, inspect, extend, or safely operate installed Kungfu; verify the installed pack, select one intent route, personalize the explanation, and propose one smallest safe next action.
kungfu-agent-onboarding
Use when a user asks to understand, start, inspect, extend, or safely operate installed Kungfu; verify the installed pack, select one intent route, personalize the explanation, and propose one smallest safe next action.
with-frontmatter
Help an agent inspect a failed trace run, identify likely failure layers, and produce a short audit note.
minimal
Help an agent inspect a failed trace run, identify likely failure layers, and produce a short audit note.
security-observability
只读查询 agent-sec-cli 已落盘的历史安全事件记录，并据此生成会话级安全复盘。仅当用户显式要求查看或审计已发生的安全事件、安全告警、安全审计记录，或要求按 session/run/trace/时间/类别筛选与统计已有安全事件，或要求复盘某次会话的安全判定时使用。不用于扫描新内容：检查代码安全性用 code-scanner，检测 prompt 注入用 prompt-scanner，审查 Skill 安全状态用 skill-ledger。不要因为对话中出现“安全”“工具调用”等字样、或为了主动自查而触发。.