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/ezraapple/skills-init/systematic-debuggingnpx skills add EzraApple/skills-init --skill systematic-debugginggit clone --depth 1 https://github.com/EzraApple/skills-initWhat 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.00054 | $0.00848 |
| Opus 5 | $0.00027 | $0.00424 |
| Sonnet 5 | $0.00011 | $0.00170 |
| Haiku 4.5 | $0.00005 | $0.00085 |
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 — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systematic Debugging
Find the causal mechanism before changing code. Treat logs, traces, failing tests, runtime state, and exact reproduction output as evidence; treat plausible code as a hypothesis.
Preserve the Requested Boundary
Diagnosis does not imply authorization to fix. Stay read-only when the user asks for investigation, explanation, or review. If the user asks to fix the problem, diagnose first and then make the smallest causal change.
Pin Down the Failure
Record:
- actual behavior, including exact errors or wrong output;
- expected behavior and the source of that expectation;
- environment, input, identity, and relevant configuration;
- frequency and timing;
- last known good version, deploy, or state when available;
- the witness that can reproduce or directly observe the failure.
Separate the reported explanation from the observed symptom. Users are reliable about what they experienced; their proposed cause is still a hypothesis.
Trace Before Hypothesizing
- Reproduce or observe the failure with the closest available witness.
- Start at the visible failure and trace control and data backward toward the earliest divergence.
- Read full functions and directly relevant callers instead of judging an isolated diff or matching filename.
- Inspect recent history only when regression timing or design rationale can narrow the cause.
- Identify the invariant that should have held and the boundary that owns it.
If reproduction is unsafe or unavailable, state that limitation and use the strongest static or runtime evidence available.
Maintain a Hypothesis Ledger
Use a small ledger when more than one cause is plausible:
| Hypothesis | Supporting evidence | Contradicting evidence | Next discriminating probe | Status |
|---|---|---|---|---|
| Specific causal claim | Concrete observation | Concrete observation | One check that separates it from alternatives | open / confirmed / ruled out |
Form hypotheses that can be falsified. Prefer one probe that distinguishes several hypotheses over several probes that merely collect more logs.
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 · 109 lines · 54 tokens per session scan A bbe3ce67cf83
systematic-debugging is a skill published in the GitHub repository EzraApple/skills-init (2 stars, last pushed 29d ago), licensed MIT. It adds 54 tokens to every session and 848 once invoked, about $0.0003 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-31.
Other skills, from other repositories
etsy-category-listing
Etsy category page scraper: given an Etsy category URL (e.g. https://www.etsy.com/c/jewelry) and optional page number, returns paginated product listings with listingId, shopId, title, url, image, salePrice, originalPrice, currency, rating, reviewCount, shopName, isAd, freeShipping, badge from category and subcategory…
human-approval
Request human approval before performing a SAFETY-CRITICAL, IRREVERSIBLE, or SCOPE-EXPANDING action — submit a structured context (action, scope, risk, consequence) plus options, then STOP the current turn. The platform redispatches the agent after the human decides. NEVER use for routine deliverables (writing docs /…
firebase-analytics
Use when logging analytics events, setting user properties, configuring default event parameters, building funnels, or adding screen-view tracking.
firebase-remote-config
Use when implementing feature flags, running A/B tests, setting parameter defaults, fetching/activating config, or enabling real-time config updates.
git-master
MUST USE whenever a task needs a commit or git-history investigation. Covers atomic commits, staging, commit-message style, rebase, squash, fixup/autosquash, blame, bisect, reflog, git log -S/-G, and questions like who wrote this or when was this added. Do not use for ordinary code edits unless the user asks for git…
prismer-evolve-record
Record the outcome of applying an evolution strategy. Use after resolving an error where prismer-evolve-analyze provided a recommendation, to feed back success or failure to the network.