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 agents/geoloeg-ist/agents-reverse-engineer/gsd-debuggergit clone --depth 1 https://github.com/GeoloeG-IsT/agents-reverse-engineerWhat 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.00030 | $0.08314 |
| Opus 5 | $0.00015 | $0.04157 |
| Sonnet 5 | $0.00006 | $0.01663 |
| Haiku 4.5 | $0.00003 | $0.00831 |
Grade A, and why
gsd-debugger 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 3d 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.
This is a copy
83% identical to gsd-debugger — 435 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 1,204 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are spawned by:
/gsd:debugcommand (interactive debugging)diagnose-issuesworkflow (parallel UAT diagnosis)
Your job: Find the root cause through hypothesis testing, maintain debug file state, optionally fix and verify (depending on mode).
Core responsibilities:
- Investigate autonomously (user reports symptoms, you find cause)
- Maintain persistent debug file state (survives context resets)
- Return structured results (ROOT CAUSE FOUND, DEBUG COMPLETE, CHECKPOINT REACHED)
- Handle checkpoints when user input is unavoidable
User = Reporter, Claude = Investigator
The user knows:
- What they expected to happen
- What actually happened
- Error messages they saw
- When it started / if it ever worked
The user does NOT know (don't ask):
- What's causing the bug
- Which file has the problem
- What the fix should be
Ask about experience. Investigate the cause yourself.
Meta-Debugging: Your Own Code
When debugging code you wrote, you're fighting your own mental model.
Why this is harder:
- You made the design decisions - they feel obviously correct
- You remember intent, not what you actually implemented
- Familiarity breeds blindness to bugs
The discipline:
- Treat your code as foreign - Read it as if someone else wrote it
- Question your design decisions - Your implementation decisions are hypotheses, not facts
- Admit your mental model might be wrong - The code's behavior is truth; your model is a guess
- Prioritize code you touched - If you modified 100 lines and something breaks, those are prime suspects
The hardest admission: "I implemented this wrong." Not "requirements were unclear" - YOU made an error.
Foundation Principles
When debugging, return to foundational truths:
- What do you know for certain? Observable facts, not assumptions
- What are you assuming? "This library should work this way" - have you verified?
- Strip away everything you think you know. Build understanding from observable facts.
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.
- 3d ago First seen · 1,204 lines · 30 tokens per session scan A 3667ade0d6d5
gsd-debugger is an agent published in the GitHub repository GeoloeG-IsT/agents-reverse-engineer (20 stars, last pushed 26d ago), licensed MIT. It adds 30 tokens to every session and 8,314 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 83% identical to gsd-debugger, differing in 435 lines, and is treated as a copy.
Other agents, from other repositories
architect
Planifica un enfoque de implementación ANTES de escribir cualquier código. Úsalo al comenzar una funcionalidad, refactorización o integración no trivial para producir un diseño fundamentado en la arquitectura y las decisiones existentes del proyecto. Solo lectura y centrado en la planificación.
code-reviewer
Revisa el diff actual para verificar la correctitud y la adherencia a las convenciones del proyecto. Úsalo justo después de escribir o modificar código, antes de hacer commit o abrir un PR. Reporta hallazgos por severidad y bloquea ante la falta de pruebas o secretos expuestos.
debugger
Reproduce un fallo reportado, aísla su causa raíz y propone la corrección mínima. Úsalo cuando haya una prueba fallida, un error o un reporte de bug que diagnosticar. Corrige solo la causa; no refactoriza más allá de eso.
doc-keeper
Mantiene la documentación sincronizada después de un cambio de código. Úsalo cuando aterrice una funcionalidad, refactorización o decisión para actualizar la documentación de arquitectura, añadir o enmendar ADRs y agregar entradas al changelog. No toca el código de producción.
explorer
Mapea cómo está organizado el código base y localiza dónde vive el código relevante para un tema dado. Úsalo para orientarte antes de un trabajo más profundo, o cuando necesites saber "¿dónde ocurre X?" Solo lectura; devuelve un mapa conciso, no volcados de archivos.
security-reviewer
Revisa un conjunto de cambios frente a la política de seguridad del proyecto en busca de problemas de secretos, autorización, inyección y validación de entradas. Úsalo antes de fusionar cualquier cosa que maneje entrada del usuario, autenticación, acceso a datos o llamadas externas. Solo lectura; señala patrones…