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 skills add All-The-Vibes/ATV-Phoenix --skill phoenix-debuggit clone --depth 1 https://github.com/All-The-Vibes/ATV-PhoenixWrote 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/skills/all-the-vibes/atv-phoenix/phoenix-debug)<a href="https://agentmods.dev/skills/all-the-vibes/atv-phoenix/phoenix-debug"><img src="https://agentmods.dev/badge/skills/all-the-vibes/atv-phoenix/phoenix-debug.svg" alt="Measured on agentmods" 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.00080 | $0.01158 |
| Opus 5 | $0.00040 | $0.00579 |
| Sonnet 5 | $0.00016 | $0.00232 |
| Haiku 4.5 | $0.00008 | $0.00116 |
Grade A, and why
phoenix-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 8d 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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
phoenix-debug — reproduce, isolate, fix the root, prove it healed
Overview
When something breaks, the failure mode is guessing. Phoenix debugging is evidence-driven: first capture
the failure as a runnable phoenix_sense check (so you can prove when it's fixed), then isolate the
cause using the code graph instead of reading the whole repo, fix the root not the symptom, and
confirm green. Recovery is real only when the check that was red is green — and you watched it happen.
When to use
- A
phoenix_sensecheck went red and you don't immediately know why. - A regression: something that passed now fails.
- An error/stack trace you need to chase down.
When NOT to use: you already know the exact one-line fix and have a check — just phoenix-build it.
The triage flow
Break observed
│
▼
1. REPRODUCE → capture as a phoenix_sense check that is RED now
│
▼
2. ISOLATE → graph: who calls / what changed near the failure (NOT grep the repo)
│
▼
3. HYPOTHESIZE→ smallest plausible root cause
│
▼
4. FIX root → snapshot, edit, phoenix_sense
│ ├── green ─► verify no regressions (full suite) ─► done
│ └── red ──► phoenix_heal rollback ─► new hypothesis (≤3 cycles)
▼
5. If 3 cycles fail → STOP, report findings + what you ruled out
1. Reproduce as a check (don't fix blind)
Turn the break into the narrowest red phoenix_sense you can. If it's an intermittent failure, try
phoenix_heal retry first to learn whether it's transient or real. You cannot prove a fix without a
reproducer.
2. Isolate with the graph, not grep
Ask phoenix-context: "who calls the failing function?", "what changed in its blast radius?",
"what does it depend on?". This finds the cause in a bounded query instead of re-reading files turn
after turn (which burns the context budget exactly when you need it most).
3. Fix the root, not the symptom
Patching the symptom (swallowing the exception, special-casing the one failing input) leaves the real bug live. Trace to the actual cause. If you can only treat the symptom, say so explicitly and open a follow-up — don't pretend the root is fixed.
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.
- 8d ago First seen · 89 lines · 80 tokens per session scan A 09ad8937b7fa
phoenix-debug is a skill published in the GitHub repository All-The-Vibes/ATV-Phoenix (5 stars, last pushed 4d ago), licensed MIT. It adds 80 tokens to every session and 1,158 once invoked, about $0.0004 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 skills, from other repositories
semgrep-rule-creator
Creates custom Semgrep rules for detecting security vulnerabilities, bug patterns, and code patterns. Use when writing Semgrep rules or building custom static analysis detections.
variant-analysis
Find similar vulnerabilities and bugs across codebases using pattern-based analysis. Use when hunting bug variants, building CodeQL/Semgrep queries, analyzing security vulnerabilities, or performing systematic code audits after finding an initial issue.
fp-check
Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSITIVE or FALSE POSITIVE verdicts with documented evidence for each bug.
vuln-report
Turn one confirmed security finding into a disclosure-ready GitHub advisory with root cause, proof of concept, impact, and source evidence. Use for reporting an established vulnerability, not discovering or validating one.
huggingface-spaces
Build, deploy, debug, or maintain a Hugging Face Space using Gradio, Docker, or Static SDKs. Use for general Space hosting and configuration; use huggingface-zerogpu for ZeroGPU runtime constraints and lora-space-builder for LoRA demos.
azure-diagnostics
WORKFLOW SKILL — Debug and troubleshoot Azure production issues: Container Apps + Function Apps diagnostics, KQL log analysis, health checks. WHEN: 'debug production issues', 'troubleshoot container apps', 'troubleshoot function apps', 'image pull failures', 'cold start issues', 'health probe failures'. DO NOT USE…