All-The-Vibes

Full autonomous engineering workflow

Session kickoff protocol - the opposite of "land the plane". Use this skill whenever the user says "takeoff", "take off", "/takeoff", "starting a new session", "what should I work on", "kickoff", "what's next", or wants a prioritized view of the backlog at the start of work. Surfaces the top-priority backlog tasks as a table with status, dependencies, and blockers pulled from Backlog.md (CLI + MCP). Use this at the start of a coding session to orient on what to work on.

Full autonomous engineering workflow

Produce two independent agent reviews on the current PR (an existing Copilot review when present, otherwise two distinct subagent reviewers), adjudicate findings with a third independent subagent, post inline PR comments for verified issues, run a tight inline fix-and-reply-and-resolve loop, then deliver a verdict — APPROVE if clean, APPROVE-WITH-CHANGES if findings were verified (and fixed or noted), CLOSE if the PR is fundamentally unsound, or WITHHELD if CI is red post-fix and the regression cannot be resolved. The skill is read-only with respect to GitHub reviewer assignment — it never adds reviewers. Use whenever the user invokes /ghcp-review-resolve, asks to "run copilot review and resolve", asks to "review and fix my PR with copilot", asks for a "dual review and fix pass", or wants automated review triage, remediation, and verdict on a pull request they just opened. Submits APPROVE or CLOSE; never submits REQUEST_CHANGES and never merges.

Session completion protocol - the opposite of "takeoff". Use this skill whenever the user says "land", "/land", "land the plane", "land it", "let's land", "land this", "bring it in", "wrap it up", "land the plan", "land plane", "time to land", "ok land", "go ahead and land", or any variation that signals they want to finish, close out, ship, or wrap up the current session's work. Executes the full commit → push → PR → handoff checklist without asking. If the user's message contains "land" in the context of finishing work, invoke this skill — it is a keyword trigger, not an exact match.

Full autonomous engineering workflow using swarm mode for parallel execution

Full autonomous engineering workflow using swarm mode for parallel execution

Transform feature descriptions or requirements into structured implementation plans grounded in repo patterns and research. Also deepen existing plans with interactive review of sub-agent findings. Use for plan creation when the user says 'plan this', 'create a plan', 'write a tech plan', 'plan the implementation', 'how should we build', 'what's the approach for', 'break this down', or when a brainstorm/requirements document is ready for technical planning. Use for plan deepening when the user says 'deepen the plan', 'deepen my plan', 'deepening pass', or uses 'deepen' in reference to a plan. Best when requirements are at least roughly defined; for exploratory or ambiguous requests, prefer ce-brainstorm first.

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.

Systematic code review guidance covering correctness, maintainability, security, and performance. Activates for PR reviews and code quality checks.

Audience-first documentation guidance for READMEs, API docs, architecture docs, and tutorials. Ensures clarity, completeness, and maintainability.

Project-agnostic skill for delegating execution work to subagents with skill activation, parallel execution, and quality verification.

Defines the technical lead role for main thread in agentic coding workflows - planning, delegation, coordination, and quality oversight

Comprehensive testing guidance covering test planning, TDD workflow, testing pyramid, and coverage targets. Ensures confidence through layered testing.

Bind agent-authored `.DESIGN.md` files to paperboard's design doctrine. Loads the impeccable anti-slop methodology (vendored, Apache 2.0, pinned to commit `4af581e23f17d112d8f9d6b7a5b7ff37823494e1`) and the binding rules in `core/designs/DESIGN-AUTHORITY.md`. Read these BEFORE writing or editing any `.DESIGN.md` file.

Render a structured input (JSON or Markdown) into a paired HTML + DESIGN.md + meta.yaml artifact triple. Serves the result on loopback HTTP and opens a browser tab (unless running headless/remote). Invokes `paperboard render` via the atv-paperboard CLI.

Regenerate the Paperboard Gallery — a local HTML index of all rendered artifact triples. Invokes `paperboard gallery` via the atv-paperboard CLI.

3-step differentiated retry for a failing artifact slug: switch tier, drop optional components, fall back to default design. Invokes `paperboard regenerate`.

Run ENFORCE checks on a rendered artifact slug: Google design.md lint + HTML-side color-token trace. Reports ACCEPT or FAIL with fail_class. Invokes `paperboard validate`.