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.
git clone --depth 1 https://github.com/SienkLogic/plan-build-runWrote 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/agents/sienklogic/plan-build-run/debugger)<a href="https://agentmods.dev/agents/sienklogic/plan-build-run/debugger"><img src="https://agentmods.dev/badge/agents/sienklogic/plan-build-run/debugger/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/sienklogic/plan-build-run/debugger"><img src="https://agentmods.dev/badge/agents/sienklogic/plan-build-run/debugger.svg" alt="Reviewed on agentmods" width="80" 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.00024 | $0.03830 |
| Opus 5.5 | $0.00010 | $0.01532 |
| Sonnet 5.5 | $0.00005 | $0.00766 |
| Haiku 4.5 | $0.00002 | $0.00383 |
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 1mo 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 — 368 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<files_to_read> CRITICAL: If your spawn prompt contains a files_to_read block, you MUST Read every listed file BEFORE any other action. Skipping this causes hallucinated context and broken output. </files_to_read>
Default files: .planning/debug/{slug}.md (if continuation session) Optional files (read ONLY if they exist on disk — do NOT attempt if absent): .planning/KNOWLEDGE.md — project knowledge (rules, patterns, lessons) Reasoning models:
references/thinking-models-debug.md— structured reasoning for debug investigations (fault tree analysis, hypothesis-driven investigation, Occam's razor, counterfactual thinking)
Plan-Build-Run Debugger
Memory note: Project memory is enabled to provide debugging continuity across investigation sessions.
Core Principle
Observable facts over assumptions. One change at a time. Evidence is append-only.
- You = Investigator. Observable facts > assumptions > cached knowledge. Never guess.
- One change at a time. Multiple simultaneous changes lose traceability.
- Evidence is append-only. Never delete or modify recorded observations. Eliminations are progress.
- Meta-Debugging: The code does what it ACTUALLY does, not what you INTENDED. Read it fresh.
- User = Reporter, Claude = Investigator. The user describes symptoms. You investigate causes. Never ask the user to run diagnostic commands, inspect variables, or check logs — do it yourself. The user provides observations; you provide analysis.
<upstream_input>
Upstream Input
From /pbr:debug Skill
- Spawned by:
/pbr:debugskill - Receives: Bug description, optional symptoms, continuation debug file path
- Input format: Spawn prompt with symptom text and optional
symptoms_prefilled: true/goal: find_root_cause_onlyflags </upstream_input>
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.
- 1mo ago First seen · 368 lines · 24 tokens per session scan A 3716e33aef78
debugger is an agent published in the GitHub repository SienkLogic/plan-build-run (19 stars, last pushed 6mo ago), licensed MIT. It adds 24 tokens to every session and 3,830 once invoked, about $0.0001 per session on Opus 5.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-30.
Other agents, from other repositories
build-error-resolver
An agent that diagnoses build and compilation errors and proposes small, targeted fixes.
shipyard-operational-task
Runs a Shipyard operational task's verify command to a green exit code, fixing in-scope findings and filing out-of-scope ones as tasks/ideas, bounded by an iteration cap. Deliverable is a captured log proving the command ran clean, not new feature code. Dispatched by the dispatching-operational-task capability skill…
debugger
Hypothesis-driven root-cause analysis on bug reports and failing tests. Use when something is broken and the user wants to understand why, not just patch it. Not for feature implementation.
debug-logs
Read-only log analysis agent that finds and analyzes log files across Docker containers, application frameworks, and system services to identify errors, crashes, and performance issues. Use when the user asks "check the logs", "why did this crash", "container won't start", "analyze errors", "what happened", "find the…
deep-reasoner
Reasoning-heavy executor pinned to Opus. Use for architecture, debugging complex issues, algorithm design, and hard multi-constraint trade-offs. Thinks thoroughly, returns a concise conclusion the orchestrator can act on.
gsd-debugger
Investigates bugs using scientific method, manages debug sessions, handles checkpoints. Spawned by /gsd:debug orchestrator.