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/KevinZai/commanderWrote 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/commands/kevinzai/commander/ccc-debug-session)<a href="https://agentmods.dev/commands/kevinzai/commander/ccc-debug-session"><img src="https://agentmods.dev/badge/commands/kevinzai/commander/ccc-debug-session/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/commands/kevinzai/commander/ccc-debug-session"><img src="https://agentmods.dev/badge/commands/kevinzai/commander/ccc-debug-session.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.00042 | $0.00889 |
| Opus 5.5 | $0.00017 | $0.00356 |
| Sonnet 5.5 | $0.00008 | $0.00178 |
| Haiku 4.5 | $0.00004 | $0.00089 |
Grade A, and why
ccc-debug-session 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 6d 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 — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/ccc-debug-session — hypothesis-driven bug hunt
CC Commander · /ccc-debug-session · root cause first, then a tested fix and a recorded lesson.
Issue: $ARGUMENTS. If it is empty, ask the user for the error message or the unexpected behavior before starting.
Phase 1: Gather context
-
Recent changes:
git log --oneline -10 git diff HEAD~3If
HEAD~3does not exist, usegit diffagainst the first commit. -
Reproduce: capture the exact error message, stack trace or wrong output, and the command that produces it.
-
Find related files with Grep/Glob on the symbols, messages and paths in the error.
-
Read
tasks/lessons.md(if present) for related past fixes. -
git blame -L <start>,<end> <file>on the suspect lines to see when they last changed.
Phase 2: Hypotheses
List 3 to 5 candidate root causes, most likely first:
HYPOTHESIS 1 (most likely): <description>
Evidence for: <what supports it>
Evidence against: <what contradicts it>
Test: <the read, grep or experiment that confirms or eliminates it>
Phase 3: Investigate
For each hypothesis, starting with the most likely:
- Design the smallest test that confirms or eliminates it.
- Run it and record the result.
- Confirmed: go to Phase 4. Eliminated: next hypothesis.
Test hypotheses with reads, greps, logs and targeted experiments. Do not edit code to try things. If every hypothesis is eliminated, gather more evidence and write a new set before touching code.
When the root cause is confirmed, ask with AskUserQuestion (Codex: a plain-text question):
- 🟢 Fix it now — write a failing test, then the minimal fix
- Report only — stop with the root cause and the proposed fix
- Investigate further — test the remaining hypotheses first
Phase 4: Resolve
- Write a reproduction test first and run it; it must fail for the reason found (red).
- Implement the minimal fix and rerun the test; it must pass (green).
- Rerun the original reproduction from Phase 1 and confirm the symptom is gone.
- Run the project's full test command (from
package.json,Makefile,pyproject.tomlor the projectCLAUDE.md, for examplenpm test,pytest,go test ./...). Report the actual pass/fail line. - Append to
tasks/lessons.md:
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.
- 6d ago Changed · +20 lines · +27 tokens per session be2c3d8e2219
- 1mo ago First seen · 75 lines · 15 tokens per session scan A 0e77c4622dfd
ccc-debug-session is a command published in the GitHub repository KevinZai/commander (6 stars, last pushed today), licensed MIT. It adds 42 tokens to every session and 889 once invoked, about $0.0002 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-09-03.
Other commands, from other repositories
quick-fix
Implement→review subagent loop with no planning phase, for a fix whose cause is known and whose shape is obvious, however many files it touches. No spec, no worktree, no docs or signals at the end; one audit. Routes to /subagent-diagnose on an unknown cause and to /atomic-plan on an open approach or contract choice.
dashboard
Compact visual progress dashboard with progress bar, task table, dependency graph, and active/blocked/next status.
dev-error-handling
Implements a robust and consistent error handling strategy.
fix-issue
A command that takes a GitHub Issue—a tracked bug, request, or question—and guides its fix from investigation through testing and submission. TDD means writing a failing test first, then changing the code until the test passes.
dare-bugfix-design
Diagnostica bug em projeto existente e planeja correção cirúrgica via Método DARE. Gera DARE/DESIGN-Bugfix-[Nome].md com causa raiz, riscos de regressão e plano de ação mínimo.
bug-blitz
Emit and fire a canonical bug-backlog queue grind; dispatch, don't defer.