phoenix-ide

Implement, debug, test, and review changes in Phoenix IDE. Use for Phoenix coding tasks, repository workflow, validation, codegen, commits, or choosing the right specialized Phoenix skill. Start here for Work-mode tasks; use phoenix-explore first when the problem is still ambiguous.

Breadth-first, read-only investigation of ambiguous Phoenix IDE feedback and requests. Use in Explore mode to trace a raw symptom across easy-to-miss UI, runtime, wire, persistence, tool, worktree, and production boundaries before proposing an implementation task. Produces a bounded evidence-backed task, not code changes.

Production deployment for Phoenix IDE. Use when running ./dev.py prod deploy, checking production status, diagnosing a failed deploy, or stopping the production service.

Cut a new phoenix-ide version by merging a version-bump PR, which triggers GitHub Actions to tag, build, and publish the binary, then replace the auto-generated release notes with a sub-agent-drafted, human-reviewable changelog. Use when the user says "cut a release", "publish a version", "ship vX.Y.Z", "tag a new release", or asks how to publish.

Finds one valid React performance target in the Phoenix UI. Profiles scenarios via the run-scenario harness (default transport: browser_profile), scans for known React anti-patterns, learns from db.yaml history, ranks, and returns a filled target.yaml. Use before /phoenix-perf-hunt.

Coordinates a Phoenix React performance attempt. Captures the scenario baseline (raw samples) BEFORE any change via the run-scenario harness (default transport: browser_profile), implements one focused fix, hands off to review, and records every outcome in db.yaml. Does not judge.

Add or update a Phoenix UI Ladle fixture end-to-end, including scenario data, stories, QA capture scripts, dev.py qa wiring, tests, and fixture best practices.

spEARS (Simple Project with EARS) is a requirements-first specification methodology for AI agents and humans, pairing timeless EARS requirements, point-in-time ADRs, optional Allium behavior specs, and executive status docs with grep-able traceability.

Phoenix-specific migration workflow for retiring legacy spEARS v1 design.md files into spEARS v2 artifacts. Use when migrating an existing specs/<name>/design.md, extracting ADRs, deciding whether behavior belongs in requirements or Allium, or removing stale design-doc references.

Give your AI agents something more useful than a prompt. Velocity through clarity.

The methodology for splitting a large crate into smaller ones — the decision principles and workflow that lead to a clean result, not one extraction's steps. Use when planning or executing a crate split, deciding what belongs in a shared base crate vs. what stays put, breaking a dependency cycle to enable a split, or sequencing any large incremental refactor where partial progress must stay shippable.

Re-run Phoenix spec executive-table inventory, prioritize high-ROI incomplete rows, close small spec-code gaps with matching executive updates, and spin out concrete follow-up tasks for ambiguous or significant gaps. Use when asked to audit specs, find spec-code drift, continue spec-audit bug hunting, or mine executive tables for actionable work.

Environment validation checklist for Phoenix React performance hunting. Run this FIRST when starting a new session to verify the dev server, run-scenario harness (including --self-test), seed data, git state, and stats helper are ready before any optimization work. The default transport is browser_profile (in-agent LLM tool); agent-browser is legacy/optional.

Reviews a Phoenix React performance patch with a 5-persona peer-review panel backed by raw-sample statistics. Requires unanimous approval and statistically significant improvement past the noise floor. Judges; does not record.

Full Phoenix React performance workflow with git branch, commit, and optional PR. Wraps /phoenix-perf-hunt with git automation.

Task tracking conventions for Phoenix IDE. Use when creating a task, updating task status, filing a bug found during work, or checking what tasks are ready to work on.

Give your AI agents something more useful than a prompt. Velocity through clarity.

Extract an Allium specification from an existing codebase. Use when the user has existing code and wants to distil behaviour into a spec, reverse engineer a specification from implementation, generate a spec from code, turn implementation into a behavioural specification, or document what a codebase does in Allium terms.

Run a structured discovery session to build an Allium specification through conversation. Use when the user wants to create a new spec from scratch, elicit or gather requirements, capture domain behaviour, specify a feature or system, define what a system should do, or is describing functionality and needs help shaping it into a specification.

Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.