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-self-healgit 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-self-heal)<a href="https://agentmods.dev/skills/all-the-vibes/atv-phoenix/phoenix-self-heal"><img src="https://agentmods.dev/badge/skills/all-the-vibes/atv-phoenix/phoenix-self-heal/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/skills/all-the-vibes/atv-phoenix/phoenix-self-heal"><img src="https://agentmods.dev/badge/skills/all-the-vibes/atv-phoenix/phoenix-self-heal.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.00096 | $0.01143 |
| Opus 5 | $0.00048 | $0.00571 |
| Sonnet 5 | $0.00019 | $0.00229 |
| Haiku 4.5 | $0.00010 | $0.00114 |
Grade A, and why
phoenix-self-heal 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 11d 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 — 83 lines — stays where its author put it; the contents beside it link to each section on GitHub.
phoenix-self-heal — sense, snapshot, heal; the loop at the heart of Phoenix
Overview
This is the primitive every Phoenix lifecycle skill is built on, usable standalone: objectively sense whether work succeeded, keep a blessed snapshot to fall back to, and heal (bounded) when a check goes red — with recovery confirmed by an independent recheck, never by self-judgment. It gives an agent the one organ it's missing: knowing it failed, and fixing it, with evidence.
When to use
- Any code change with a runnable check (test/build/lint).
- Risky edits where you want a guaranteed rollback point.
- As the inner loop of
phoenix-build,phoenix-test, andphoenix-debug.
The four tools
- phoenix_sense(check) — objective check.
kind∈command_exit(run argv, pass iff exit==expect, default 0),file_sha256,regex_in_file. Returns{ok, signal, evidence}. No LLM, no opinion.targetaccepts an argv array (preferred) or a string;expectaccepts an int or string. - phoenix_snapshot(path, check) — save
pathas last-good only ifcheckpasses (never blesses a broken state). Returns{blessed, snap_id}. - phoenix_heal(strategy, ctx) —
rollback(restore a blessed snapshot) orretry(re-run a command ≤3×).healed=trueonly ifctx.recheckpasses after the action. Bounded; reversible. - phoenix_verify_trace() — audit the tamper-evident hash-chained log.
Example
{"check":{"kind":"command_exit","target":["pytest","-q"],"expect":0}} # sense
{"path":"src/app.py","check":{"kind":"command_exit","target":["pytest","-q"],"expect":0}} # snapshot (blesses if green)
{"strategy":"rollback","ctx":{"path":"src/app.py","snap_id":"app.py.1a2b…", # heal
"recheck":{"kind":"command_exit","target":["pytest","-q"],"expect":0}}}
The loop
baseline ─► phoenix_sense ─► ok? ──no──► (not ready; create a check first)
│ yes
▼
phoenix_snapshot (bless green state)
│
▼
── edit ──
│
phoenix_sense ─► ok? ──yes──► done (green, proven)
│ no
▼
phoenix_heal (rollback/retry, ≤3) ─► re-sense ─► green?
│ no after 3 → STOP, report what's blocking
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.
- 11d ago First seen · 83 lines · 96 tokens per session scan A 047a978cd2d5
phoenix-self-heal is a skill published in the GitHub repository All-The-Vibes/ATV-Phoenix (5 stars, last pushed 7d ago), licensed MIT. It adds 96 tokens to every session and 1,143 once invoked, about $0.0005 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.
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.
fp-check
Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSITIVE or FALSE POSITIVE verdicts with documented evidence for each bug.
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.
decision-table
Use when the user wants a code-grounded decision table for current behavior, wants to compare current behavior against a plan or work item, or needs a control-flow artifact for recovery, retry, finalization, validation, state-machine, or review-heavy edge cases.