Menu
Recommend the right `$elixir-phoenix-*` skill for the current task.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Elixir/Phoenix: Review lifecycle, state-machine, Oban, persistence, pause/resume, retry, and restart-sensitive changes before commit, push, or PR. Use for concurrency-sensitive runtime work to produce explicit blocking vs optional findings, require durability checks, and verify smoke plus restart resilience when applicable.
Capture a solved Phoenix problem as a reusable solution doc.
Audit LiveView assigns for memory bloat, dead assigns, and stream candidates.
Audit project health across architecture, security, performance, tests, and deps.
Analyze Phoenix context boundaries and coupling with `mix xref`.
Brainstorm Phoenix features, tradeoffs, and requirements before planning.
| name | elixir-phoenix-help |
| description | Recommend the right `$elixir-phoenix-*` skill for the current task. |
| metadata | {"short-description":"Route to the right Phoenix skill"} |
Helps users find the right command, skill, or agent for their situation.
`$elixir-phoenix-help` # Analyze context, suggest commands
`$elixir-phoenix-help` how do I debug this? # Route to `$elixir-phoenix-investigate`
`$elixir-phoenix-help` add a new feature # Route to `$elixir-phoenix-plan` -> `$elixir-phoenix-work`
$ARGUMENTS — optional description of what the user wants to doIf $ARGUMENTS is non-empty, use it as primary signal.
Always gather ambient context (run in parallel):
rg --files on .codex/plans/*/plan.md — active work in progress?rg --files on .codex/solutions/**/*.md — prior knowledge?Read references/tool-catalog.md for the full routing table.
Map the user's situation to one of these categories:
| Category | Signals | Primary Commands |
|---|---|---|
| Starting out | No plans, new to plugin | $elixir-phoenix-intro |
| Ideation | "explore", "brainstorm", "not sure", "how to approach", "vague idea" | $elixir-phoenix-brainstorm |
| New feature | "add", "build", "implement", multi-file | $elixir-phoenix-plan → $elixir-phoenix-work |
| Quick change | Single file, <50 lines, "fix typo" | $elixir-phoenix-quick |
| Bug | Error, stack trace, "broken", "failing" | $elixir-phoenix-investigate |
| Review | "check", "review", PR ready | $elixir-phoenix-review |
| Runtime durability | "race", "state machine", "retry semantics", "pause/resume", "restart safety", "durability", "Oban flow" | $elixir-phoenix-runtime-durability-review |
| Performance | "slow", "N+1", "memory" | $elixir-phoenix-perf, $elixir-phoenix-n1-check, $elixir-phoenix-assigns-audit |
| Research | "how to", "best practice", "evaluate lib" | $elixir-phoenix-research |
| Resume work | Existing plan with unchecked tasks | ``$elixir-phoenix-work --continue |
| Post-fix | "that worked", solved a hard bug | $elixir-phoenix-compound |
| Full cycle | Large feature, new domain area | $elixir-phoenix-full |
| Project health | "audit", "tech debt", "overall quality" | $elixir-phoenix-audit, $elixir-phoenix-techdebt |
| Deployment | "deploy", "release", "production" | $elixir-phoenix-verify then deploy skill |
| Permissions | "too many prompts", "allow", "permission fatigue" | $elixir-phoenix-permissions |
If high confidence (clear match to one category): Present the recommendation with:
If medium confidence (2-3 possible matches):
Use ask the user directly with the top options, each with a one-line explanation.
If low confidence (vague or no signal): Ask ONE focused clarifying question. Examples:
Then recommend based on the answer.
After recommending, always add:
$elixir-phoenix-help anytime to get routing advice"$elixir-phoenix-intro for a full plugin walkthrough" Add user notifications not just "use the plan command"intent-detection (auto-trigger) with explicit invocation$elixir-phoenix-intro for onboarding