ATV-Phoenix

Assemble the cheapest sufficient context for a task — route structural questions (who calls X, what breaks if I change Y, what inherits from Z) to the prebuilt code graph instead of grepping and re-reading files, and pull the relevant subgraph/snippet rather than whole directories. Use on any non-trivial codebase, before a change with unclear blast radius, or when the user says /phoenix-context or "what uses this".

Decompose a high-level vague intent into N concrete /goal instances (≤5), each with its own phoenix_sense acceptance check, proven complete via composite phoenix_accept (all N saw_red AND green_after_red AND currently_green). Use when a task is multi-faceted (build + integrate + configure + notify) with independent or sequentially-dependent sub-goals. Use when the user says /intent, /phoenix-intent, "decompose this", "parallel goals", or gives a multi-outcome intent. For a single goal use phoenix-goal instead.

Dynamic, state-sensing router for autonomous multi-step work — chooses the next Phoenix skill at runtime from the current objective state (what's green/red, what stage, is there a backlog) instead of following a fixed pipeline. This is Phoenix's autopilot. Use for open-ended autonomous execution where the next step depends on results, when the user says /phoenix-auto, "autopilot", "drive this", "orchestrate", or "figure out the steps as you go". For a fixed lifecycle just use the phoenix meta-router; for a persistent backlog loop use phoenix-ralph.

Turn ONE high-level, possibly-vague goal into a runnable, objective acceptance check and a verifiable backlog, then drive it to completion. The critical step is FORMALIZE — deriving an executable done-check before any code, because a goal with no objective acceptance criterion has no honest termination. This is the DEFAULT entry for any hands-off "just go and finish it" request. Use at the start of an open-ended ask, when the user says /phoenix-goal, "achieve", "build me", "get this working end to end", "go", "go autonomous", "let's go", "just do it", "run it to done", or gives a goal without a spec. Hands off to phoenix-ralph for the loop. Not for an already-scoped backlog (use phoenix-ralph) or a single known fix (use phoenix-build).

The meta-skill that routes a task to the right Phoenix lifecycle skill and enforces the non-negotiable operating laws. Use at the start of any session or task to decide which Phoenix skill applies. Phoenix is a self-healing, token-efficient engineering harness — every stage verifies its work with an objective check instead of self-judging. Invoke when starting work, when unsure which skill fits, or when the user says /phoenix.

Diagnose and repair a Phoenix install with the same objective discipline Phoenix gives the agent — check whether the installed agent, skills, and MCP registration match what this build ships, and re-sync any drift with a snapshot-backed fix that is re-verified red→green. Use when Copilot says "No such agent: phoenix", a skill is missing or behaving oddly, after upgrading Phoenix, or when the user says /phoenix-doctor, "doctor", "diagnose my install", "repair phoenix", or "is phoenix installed right".

Install the ATV-Phoenix self-healing harness into GitHub Copilot. Builds the Rust MCP server (if needed) and registers the phoenix agent plus its MCP server so Copilot can call phoenix_sense / phoenix_snapshot / phoenix_heal / phoenix_verify_trace. Use when the user types /phoenix-setup or asks to install or enable Phoenix.

Produce, validate, and consume Open Knowledge Format (OKF v0.1) bundles — turn Phoenix's code graph (graph.json) into browsable, diffable markdown knowledge, make the skill pack an OKF bundle, and ingest any external OKF bundle as token-cheap progressively-disclosed context. Use when the user says /phoenix-okf, "export the graph", "make an OKF bundle", "knowledge bundle", or wants portable, inspectable knowledge instead of an opaque graph.json.

Implement one planned step at a time under the verify-heal loop — snapshot before risky edits, make the smallest change, sense the objective check, and heal (rollback or retry) if it goes red. Never advance to the next step on a red check, never claim a step done without a green sense. Use during implementation, or when the user says /phoenix-build, "implement this", or "write the code".

Code-craft guardrails that reduce the most common LLM coding mistakes — think before coding, simplicity first, surgical changes, and verifiable success — gated by objective phoenix_sense checks so "simpler" and "done" are proven, not asserted. Grounded in Andrej Karpathy's observations on LLM coding pitfalls. Use when writing, refactoring, or reviewing any code, or when the user says /phoenix-craft, "keep it simple", or "don't over-engineer".

Systematic triage and self-healing when something breaks — reproduce with an objective check first, isolate the cause with the code graph, fix the root not the symptom, and confirm with phoenix_sense before claiming it resolved. Use when a test/build is red, a regression appears, or the user says /phoenix-debug, "it broke", or "fix this error".

Design-engineering craft for interfaces that feel right — the animation decision framework (should it animate at all, what's the purpose, what curve), the invisible details that compound, and a required Before/After review table. Gated where possible by objective checks (lint, build, visual/interaction verification). Grounded in Emil Kowalski's design-engineering philosophy. Use when building or reviewing UI, animations, or interactions, or when the user says /phoenix-design, "make it feel better", or "review this UI".

Decompose a clear intent into small, individually-verifiable steps before writing code — each step a slice you can prove pass/fail with phoenix_sense, ordered so the build stays green between them. Use after phoenix-think, when you have an Intent Contract and need an executable plan, or when the user says /phoenix-plan, "break this down", or "make a plan".

Persistence loop that keeps working a backlog until the goal is OBJECTIVELY proven done — not until the agent thinks it's done. Wraps Geoffrey Huntley's Ralph loop (fresh context per iteration, filesystem as memory) with Phoenix's failure-first gate ledger, so completion is derived from the tamper-evident trace, never self-reported. Use when a task must run to completion across many iterations, when the user says /phoenix-ralph, "ralph", "don't stop", "keep going until it's done", or "run until the tests pass". Not for one-shot fixes (use phoenix-build) or scoping a vague idea (use phoenix-goal).

Review completed work against the Intent Contract's acceptance criteria using objective evidence, not opinion — re-run every check, confirm no regressions, inspect the tamper-evident trace, and surface only real issues (bugs, unmet criteria, regressions). Use before shipping, after a feature is built, or when the user says /phoenix-review or "review this".

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".

The final gate before declaring a task done — run the acceptance check one last time, verify the tamper-evident trace is intact, and report success only on green evidence with the proof attached. Use as the last step of any task, before merging or telling the user it's complete, or when the user says /phoenix-ship, "ship it", or "is it done".

Drive development and bug-fixing with tests where the test IS the objective phoenix_sense gate. Write a failing test before the code, reproduce a bug with a test before fixing it, and let phoenix_sense decide pass/fail — never "looks right". Use when implementing logic, fixing a bug, changing behavior, or when the user says /phoenix-test, "write tests", or "TDD".

The thinking-first stage of the Phoenix lifecycle. Before any code, deeply understand what is actually wanted through Socratic deep interview and evidence-grounded deep research, surface and resolve hidden assumptions, and converge on a crystal-clear intent whose deliverable is a runnable objective acceptance check. Use at the start of any non-trivial task, when an ask is vague or ambiguous, or when the user says /phoenix-think, "think first", "interview me", "don't assume", or "research this before building".

TypeScript craft where the type-checker IS the objective gate — treat `tsc --noEmit` as a phoenix_sense check, work strict, derive types instead of duplicating them, and eliminate `any`/unsafe casts. Grounded in Mat Pocock's (Total TypeScript) philosophy that types exist to power a fast feedback loop. Use on any TypeScript/JavaScript change, when configuring a TS project, or when the user says /phoenix-typescript, "fix the types", or "make it type-safe".

Turn on token-efficient code-graph routing for the current repository. Builds a structural code index and installs the routing agent so the host CLI answers "who calls X / what breaks if I change Y" from a prebuilt graph instead of repeated grep, cutting cumulative context tokens. Use when the user types /token-master or asks to enable token-efficient routing.