Skip to main content

phoenix-self-heal

The core verify-then-heal loop usable on its own for any change with a checkable outcome — sense success objectively, snapshot known-good state, and recover (bounded rollback or retry) when a check goes red, confirmed by an external recheck. Use whenever you make a change that has a runnable test/build/lint, or when the user says /phoenix-self-heal, "verify and fix", or "make sure it works".

Ir a la instalación

Datos de origen

Repositorio
All-The-Vibes/ATV-Phoenix
Última actividad en el origen
18 de junio de 2026 a las 02:25
Idioma detectado de SKILL.md
inglés
Estrellas
6
Forks
4

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
type
Phoenix Skill
name
phoenix-self-heal
description
The core verify-then-heal loop usable on its own for any change with a checkable outcome — sense success objectively, snapshot known-good state, and recover (bounded rollback or retry) when a check goes red, confirmed by an external recheck. Use whenever you make a change that has a runnable test/build/lint, or when the user says /phoenix-self-heal, "verify and fix", or "make sure it works".
license
MIT
# 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`, and `phoenix-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. `target` accepts an argv array (preferred) or a string; `expect` accepts an int or string. - **phoenix_snapshot(path, check)** — save `path` as last-good **only if `check` passes** (never blesses a broken state). Returns `{blessed, snap_id}`. - **phoenix_heal(strategy, ctx)** — `rollback` (restore a blessed snapshot) or `retry` (re-run a command ≤3×). `healed=true` only if `ctx.recheck` passes **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 ``` ## Rules - **Snapshot only blesses green.** You can never accidentally save a broken state as your fallback. - **Heal is confirmed externally.** `healed=true` requires the independent `recheck` to pass *after* the action — the heal never grades itself. - **Bounded.** ≤3 attempts, then stop and report. Unbounded healing is token-burning, not progress. - **Reversible by default.** Rollback restores a blessed snapshot atomically; nothing is destroyed without a known-good point to return to. ## Common Rationalizations | Rationalization | Reality | |---|---| | "I'll just check the output myself." | Your read of the output is self-grading. `phoenix_sense` is the objective signal; use it. | | "Snapshot is overkill for this edit." | The edit you don't snapshot is the one that breaks three files. It costs one call; the regret costs an hour. | | "Keep healing until it's green." | After 3 attempts you're masking a deeper problem. Stop, report, re-plan. | | "It healed because the file looks right now." | "Looks right" isn't healed. `healed=true` only when the external recheck is green. | ## Red Flags - Claiming success with no `phoenix_sense`. → Run the check. - Editing without a snapshot on a risky change. → Snapshot the blessed state first. - 4th heal attempt. → Stop; this is a planning problem (`phoenix-plan`) or a real bug (`phoenix-debug`). - Trusting "healed" without the external recheck. → Confirm green via the recheck, not the diff. ## Next Standalone, this is enough to verify-and-fix one change. For full work, route through the lifecycle: `phoenix-think → plan → build (↔ test/debug) → review → ship`.
Ver en GitHub