scottopell

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.

Review a proposed feature set or implementation plan for requirements whose engineering cost is disproportionately high relative to their apparent product value.

Generate a scannable PR title and description from `gh pr diff` for busy reviewers, creating a placeholder PR first when needed so the diff source is always the PR diff. The core rule: describe CONCEPTS (what changed and why), not file lists — busy reviewers already have the file list, they need the semantic summary that answers "what would I want to know before reviewing this?" Use this skill whenever the user wants to write, update, rewrite, or summarize a pull request description, including phrases like "write a PR description", "update the PR body", "summarize this PR", "make a PR title", "draft PR writeup", or asks for a PR writeup on the current branch's open PR. Also trigger proactively when the user is wrapping up work on a branch and mentions they need to update a PR before requesting review.

Analyze code for unnecessary complexity, vestigial code, over-engineering, and dependency bloat, applying YAGNI principles to identify minimal viable implementations. Use when the user wants a YAGNI review, asks "is this over-engineered?", "what can I delete?", "find dead code", "trim dependencies", "simplify this", or wants abstractions challenged and unused code paths surfaced. Also trigger when the user mentions YAGNI, vestigial code, code bloat, or minimal viable implementation.

Methodology for using AskUserQuestion to help the user work through a fuzzy decision -- one where they know they're stuck but haven't articulated the structure of the choice yet. The job is to decompose the decision into sub-decisions and ask about the one with the most downstream leverage. Use when the user says "ask me questions", "help me think through this", "use AskUserQuestion", or hands you something like "I'm not sure what the right move is for X -- help me figure it out." Also referenced by CLAUDE.md for default AskUserQuestion behavior.

Search the user's past Claude Code conversation history for a specific focused fact. Trigger ONLY when the user explicitly asks to look in past conversations — phrases like "search our past conversations", "find that conversation where...", "what did I tell Claude about X", "did I mention Y before in chat", "look in my Claude history for Z". Greps conversation transcripts (JSONL), memory files, audit logs, and session metadata under ~/.claude and the Claude desktop app's local-agent-mode-sessions directory. Do NOT trigger on "have I worked on X before" or "what was the fix I did for Y" — those are questions about the codebase or git history, not the conversation log; check the code or git log instead.

Review pull requests from an engineering manager's perspective. Use this skill whenever the user asks to review a PR, look at a pull request, check someone's code, give feedback on a diff, or anything involving GitHub PRs and code review. Also trigger when the user pastes a GitHub PR URL, mentions a PR number with a repo context, or says things like "review PR #123", "what do you think of this PR", "look at this diff", "check this change", or "review what [name] submitted". This is a manager-level review — not a nitpick pass. It focuses on design quality, operational maturity, growth signals, and making stats/data-science concepts accessible.

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.

spEARS (Simple Project with EARS) is a requirements-first specification methodology for AI agents and humans. It pairs timeless EARS requirements (requirements.md) with point-in-time design decision records (ADRs), an on-demand precise behavioral layer (Allium), and a status doc (executive.md), giving a clear shared understanding of how a system should work with grep-able traceability from requirement to test to code. Use this skill whenever the user mentions spEARS or EARS specs; works with a specs/ directory or files named requirements.md, executive.md, or adrs/; asks to write, plan, or validate requirements; wants to capture an architecture or design decision; or asks how requirements trace to tests and code — even if they don't say "spEARS" explicitly.

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