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/cveralyon/axel-setup/debuggit clone --depth 1 https://github.com/cveralyon/axel-setupWhat 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.00021 | $0.00435 |
| Opus 5 | $0.00010 | $0.00217 |
| Sonnet 5 | $0.00004 | $0.00087 |
| Haiku 4.5 | $0.00002 | $0.00044 |
Grade A, and why
debug 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 yesterday.
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.
What it actually says
Debug an issue systematically. Never guess — trace the actual execution path.
Step 1: Understand the problem
- What's the expected behavior vs actual behavior?
- When did it start? Check recent commits:
git log --oneline -20 - Is it reproducible? Under what conditions?
Step 2: Trace the execution path
Rails (main-api):
Route → Controller → Service → Model → Database
rails routes | grep <endpoint>- Read controller → identify service call → read service → check model/queries
- Check logs:
tail -f log/development.log
Next.js (frontend-app):
Component → Hook (useQuery/useMutation) → Service (servicesClient/Server) → API
- Find the component rendering the broken UI
- Trace the hook it uses → service it calls → endpoint it hits
Step 3: Identify root cause
- Read the relevant code — don't assume
- Check for: nil/undefined handling, race conditions, N+1 queries, stale cache, wrong environment
- Grep for related error messages or exception classes
Step 4: Fix
- Make the minimal change that fixes the root cause
- Don't refactor unrelated code
Step 5: Verify
- Write a spec that reproduces the bug FIRST
- Apply fix, verify spec passes
- Run full validation:
RAILS_ENV=test bundle exec rspec/pnpm check - Check for regressions in related features
Cross-session bugs (escalate when needed)
The flow above is for an in-session hunt. If the bug spans multiple sessions or context resets (intermittent, long investigation, needs persistent hypotheses), recommend escalating to gsd-debug, which keeps debug state across resets. Surface this as a recommendation; the main agent runs the skill.
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.
- yesterday First seen · 48 lines · 21 tokens per session scan A 0898ec1a5c01
debug is an agent published in the GitHub repository cveralyon/axel-setup (4 stars, last pushed 1mo ago), licensed MIT. It adds 21 tokens to every session and 435 once invoked, about $0.0001 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 agents, from other repositories
syllago-author
/home/hhewett/.local/src/syllago/content/agents/syllago-author/AGENT.md.
feature-flow
Build, test, verify, and review an already planned feature. Operates on a feature branch off trunk; prepares a PR but does not merge.
review
Review PR and build output for quality, security, and compliance. Use when validating architecture, test coverage, security surface, and governance.
design
Convert the specification into a clear, actionable technical design with architecture, components, interfaces, and data flows. Use when translating requirements into a buildable system design.
learn
Product retrospective agent. Runs after a release, after a measure agent anomaly flag, or at end of sprint. Maps findings to DORA AI capabilities and produces plan agent action items. Distinct from fawkes learn.md which handles platform incident postmortems.
spec
Convert a human request into a clear, structured specification with requirements, acceptance criteria, and policy alignment. Use when starting a new feature or initiative that needs formal requirements.