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/thebeardedbearsas/claude-craft/debug-methodicalnpx skills add TheBeardedBearSAS/claude-craft --skill debug-methodicalgit clone --depth 1 https://github.com/TheBeardedBearSAS/claude-craftWrote 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/thebeardedbearsas/claude-craft/debug-methodical)<a href="https://agentmods.dev/skills/thebeardedbearsas/claude-craft/debug-methodical"><img src="https://agentmods.dev/badge/skills/thebeardedbearsas/claude-craft/debug-methodical.svg" alt="Measured on agentmods" height="20"></a>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.00038 | $0.01307 |
| Opus 5 | $0.00019 | $0.00654 |
| Sonnet 5 | $0.00008 | $0.00261 |
| Haiku 4.5 | $0.00004 | $0.00131 |
Grade A, and why
debug-methodical scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- Reproduire avec `curl` ou client minimal How it starts
The opening of the file, as written. The whole thing — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debug-Methodical — Debugging en 4 phases
Skill inspiré de obra/superpowers. Objectif : forcer une méthode rigoureuse au lieu de "try random fixes until it works".
Règle d'or : un bug sans reproduction stable est un bug mal compris. Ne JAMAIS fixer avant de reproduire.
Les 4 phases (strictes, dans l'ordre)
Phase 1 : REPRODUCE
Objectif : exécuter le bug à volonté, dans un environnement contrôlé.
Checklist :
- Étapes de reproduction documentées (Given/When/Then)
- Reproduction déterministe (>= 3 runs consécutifs identiques)
- Environnement isolé (local, container, test env)
- Inputs minimaux (le moins de données/steps possible)
- Version/commit exacts identifiés
Sortie : test automatisé qui échoue en exposant le bug (test de régression).
Signal rouge : "ça marche sur ma machine" / "parfois ça fail" → reproduction insuffisante, retour Phase 1.
Phase 2 : ISOLATE
Objectif : identifier la cause racine, pas juste un symptôme.
Techniques :
- Bisect :
git bisectpour trouver le commit fautif - Binary search dans le code : commenter la moitié, puis itérer
- Print-driven debugging : logs aux frontières (entrée/sortie fonctions)
- Debugger : breakpoints, step-through, variable watch
- Diff environnements : que diffère-t-il entre "qui marche" et "qui casse" ?
- Question the premise : l'hypothèse initiale est-elle correcte ?
Checklist :
- Cause identifiée (ligne / condition / input exact)
- Explication du pourquoi (pas juste le quoi)
- Chaîne de causalité documentée (A cause B cause C)
- Autres manifestations potentielles du même bug identifiées
Signal rouge : "je pense que c'est X" sans preuve → retour isolate avec instrumentation.
Phase 3 : FIX
Objectif : corriger la cause racine avec le minimum de changement.
Checklist :
- Fix au bon niveau (cause racine, pas symptôme)
- Changement minimal (KISS, voir rule 05)
- Pas d'effet de bord sur autres features
- Pas de fix "au cas où" / spéculatif (voir rule 23 Karpathy)
- Fix dans le bon layer (domain / infra / UI)
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 · 127 lines · 38 tokens per session scan A 022350db841f
debug-methodical is a skill published in the GitHub repository TheBeardedBearSAS/claude-craft (105 stars, last pushed 3d ago), licensed MIT. It adds 38 tokens to every session and 1,307 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
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.
extracting-code-structure
Use when listing all methods, functions, or classes in a file, exploring unfamiliar code, getting API overviews, or deciding what to read selectively without loading entire files.
audit-dead-code
Hunt dead code across a whole repository through four labelled lanes of unequal confidence. Knip (TS/JS unused files, exports, types, enum members), vulture (Python symbols), gopls (Go unexported symbols), and a portable grep lane (shell and other symbol languages), then adjudicate every candidate against the…
analyzing-code-structure
Use when editing code structure with text matching ambiguity, handling "oldstring not unique" problems, or performing formatting-independent pattern matching across function signatures, method calls, and class structures.
fortify
Fortify existing code by splitting large functions, adding edge-case coverage, and backfilling unit tests. Use when user asks to "fortify", "harden", "bulletproof", "make robust", "make solid", "strengthen", "add missing tests", "split functions", or wants to improve reliability of existing code. Don't use for new…
devils-advocate
Stress-test plans and proposals via systematic adversarial review. Assumption extraction, evidence check, failure scenarios, operational gotchas. Before implementation begins. Use when: asked to attack a plan or proposal ('devil's advocate', 'stress test', 'poke holes', 'what could go wrong'), or before implementation…