| name | help |
| description | Choose Phoenix review, plan, debug, or test command. Use when user asks which /phx: command or plugin skill handles a task; do not route only to a domain skill. NEVER for bare /help; NOT for ambiguous requests (use intent-detection) or a plugin tour. |
| argument-hint | [description of what you want to do] |
| effort | low |
Plugin Help — Interactive Command Advisor
Helps users find the right command, skill, or agent for their situation.
Usage
/phx:help # Analyze context, suggest commands
/phx:help how do I debug this? # Route to /phx:investigate
/phx:help add a new feature # Route to /phx:plan -> /phx:work
Arguments
$ARGUMENTS — optional description of what the user wants to do- Empty = analyze current context (git status, existing plans, file patterns)
Execution Flow
Step 1: Gather Context
If $ARGUMENTS is non-empty, use it as primary signal.
Always gather ambient context (run in parallel):
- Check for existing plans: use Glob on
.claude/plans/*/plan.md — active work in progress?
- Check git status: uncommitted changes? which files?
- Check for solution docs: use Glob on
.claude/solutions/**/*.md — prior knowledge?
Step 2: Classify Intent
Read ${CLAUDE_SKILL_DIR}/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 | /phx:intro |
| Ideation | "explore", "brainstorm", "not sure", "how to approach", "vague idea" | /phx:brainstorm |
| New feature | "add", "build", "implement", multi-file | /phx:plan → /phx:work |
| Quick change | Single file, <50 lines, "fix typo" | /phx:quick |
| Bug | Error, stack trace, "broken", "failing" | /phx:investigate |
| Review | "check", "review", PR ready | /phx:review |
| Performance | "slow", "N+1", "memory" | /phx:perf, /ecto:n1-check, /lv:assigns |
| Research | "how to", "best practice", "evaluate lib" | /phx:research |
| Resume work | Existing plan with unchecked tasks | /phx:work --continue |
| Post-fix | "that worked", solved a hard bug | /phx:compound |
| Full cycle | Large feature, new domain area | /phx:full |
| Project health | "audit", "tech debt", "overall quality" | /phx:audit, /phx:techdebt |
| Dep update audit | "audit deps", "supply chain", "post-mix deps.update", "review mix.lock PR" | /phx:deps-audit |
| Manual dep vetting | "vet this package", "approve dep", "trust ledger", "after /phx:deps-audit findings" | /phx:deps-vet |
|
Step 3: Respond or Clarify
If high confidence (clear match to one category):
Present the recommendation with:
- The command to run (with exact syntax)
- One-line explanation of what it does
- What artifacts it creates (if any)
- Suggested next step after it completes
If medium confidence (2-3 possible matches):
Use AskUserQuestion with the top options, each with a one-line explanation.
If low confidence (vague or no signal):
Ask ONE focused clarifying question. Examples:
- "Are you starting something new or continuing existing work?"
- "Is this a bug fix or a new feature?"
- "How many files do you expect to change?"
Then recommend based on the answer.
Step 4: Offer Follow-up
After recommending, always add:
- "Run
/phx:help anytime to get routing advice"
- If they seem new: "Try
/phx:intro for a full plugin walkthrough"
Iron Laws
- ONE recommendation — don't dump the full catalog, pick the best match
- MAX ONE clarifying question — don't interrogate, make your best guess
- Show exact syntax —
/phx:plan Add user notifications not just "use the plan command"
- Context over keywords — existing plans + git state matter more than word matching
- NEVER block — if user already knows what they want, DO NOT redirect
Integration
- Complements
intent-detection (auto-trigger) with explicit invocation
- References same routing logic but adds interactive clarification
- Can recommend
/phx:intro for onboarding
