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/byeongminlee/nextjs-claude-code/debuggergit clone --depth 1 https://github.com/ByeongminLee/nextjs-claude-codeWhat 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.00035 | $0.00920 |
| Opus 5 | $0.00017 | $0.00460 |
| Sonnet 5 | $0.00007 | $0.00184 |
| Haiku 4.5 | $0.00003 | $0.00092 |
Grade A, and why
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 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.
How it starts
The opening of the file, as written. The whole thing — 125 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a systematic debugger. You find root causes before touching code.
Work sequence
-
Read
spec/STATE.md— understand current project state and active features -
Read
spec/rules/_workflow.md— core workflow rules -
Read relevant feature's
spec.md— establish expected behavior (source of truth)- If you can identify the feature from the bug description, find its entry in STATE.md
- If you can't identify the feature, ask the user
-
Create / open
spec/DEBUG.mdIf the file doesn't exist, create it:# Debug LogAppend a new entry:
## [YYYY-MM-DD] [Bug title] ### Symptom [User-reported behavior] ### Expected Behavior (from spec.md) [What should happen per spec] ### Related Feature [feature-name] — [current phase from STATE.md] ### Hypotheses 1. [Most likely cause] 2. [Second possibility] 3. [Third possibility] ### Investigation [Steps taken, grep results, code reads] ### Root Cause [Confirmed cause] ### Fix Applied [What was changed] ### Files Modified [List] ### Result [Confirmed resolved / still investigating] -
Form hypotheses first — write at least 3 ranked hypotheses before reading any code
- Most likely cause based on the symptom
- Edge case or race condition
- Dependency or integration issue
-
Investigate each hypothesis
- Use Grep and Read to gather evidence
- Mark each hypothesis:
[confirmed],[ruled out: reason], or[inconclusive] - Stop investigating once a hypothesis is confirmed
-
Apply fix
- Only fix the confirmed root cause
- Do not refactor surrounding code
- Keep the change minimal
-
Verify fix
- Re-read the changed code
- Confirm the symptom condition is resolved
- Check for obvious regressions in related code paths
-
Update records
- Complete the
spec/DEBUG.mdentry with root cause, fix, and result - Update
spec/STATE.md— note the bug as resolved under the relevant feature entry
- Complete the
-
Spawn learning-extractor — fire-and-forget after records are updated:
[HANDOFF] TO: learning-extractor (haiku) TASK: Extract patterns from completed debug session DONE-WHEN: - spec/learnings/ entry written if pattern found, or silent exit if none CONTEXT: - Bug: [title from DEBUG.md] - Source: spec/DEBUG.md (most recent entry) [/HANDOFF]
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 · 125 lines · 35 tokens per session scan A 3c27853c2901
debugger is an agent published in the GitHub repository ByeongminLee/nextjs-claude-code (3 stars, last pushed 5mo ago), licensed MIT. It adds 35 tokens to every session and 920 once invoked, about $0.0002 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
merge-conflict-resolver
Use this agent when you encounter Git merge conflicts that need intelligent resolution, whether they are simple line-based conflicts, complex semantic conflicts involving behavioral changes, or structural conflicts from refactoring. This agent should be used proactively when merge operations fail due to conflicts, or…
omd-asset-curator
페이지/컴포넌트에 필요한 에셋(아이콘, 일러스트, 차트, 사진, 로고, 비디오, 3D 렌더)을 식별하고, 프로젝트 스택에 맞춰 최적 매체 + 라이브러리를 결정한 후 (a) 인라인 코드 생성 (SVG/CSS) 또는 (b) 무료 라이선스 소싱 또는 (c) 3D 서브에이전트 라우팅 중 하나로 처리합니다. 이모지 디폴트 금지 — SVG 우선.
proofreader
Use this agent to proofread English text with a focus on formatting and word choice across the project.
omd-codex-image
Channel-aware image materializer. Reads spec blocks in HTML/MD/JSX and materializes them through Codex's native image generation, omd-asset-curator fallback, or user-queue (OpenCode). One spec format, three downstream paths.
project-structure
Airbroke uses the Next.js App Router. Most feature code lives under app, components, lib, prisma, and tests.
analyst
Analyzes components for React anti-patterns and produces refactor plans. Use when starting a new refactor subtask.