From elixir-phoenix
Investigates bugs and errors in Elixir/Phoenix apps with root-cause analysis for crashes, exceptions, stack traces, and test failures. Supports --parallel for deep 4-track probes.
npx claudepluginhub oliver-kriska/claude-elixir-phoenix --plugin elixir-phoenixThis skill uses the workspace's default tool permissions.
Investigate bugs using the Ralph Wiggum approach: check the
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Investigate bugs using the Ralph Wiggum approach: check the obvious, read errors literally.
/phx:investigate Users can't log in after password reset
/phx:investigate FunctionClauseError in UserController.show
/phx:investigate Complex auth bug --parallel
$ARGUMENTS = Bug description or error message. Add --parallel
for deep 4-track investigation.
Use parallel mode (spawn deep-bug-investigator) when:
bug mentions 3+ modules, spans multiple contexts, is intermittent
or involves concurrency, or user says --parallel/deep.
Otherwise: Run the sequential workflow below.
Avoid confirmatory subagents: Do NOT spawn parallel subagents to "verify" findings you already identified in the main context. If Step 3-4 already identified the root cause with high confidence, present it directly — don't spend ~80K tokens on 4 subagents to confirm what's already obvious (confirmed waste: session c135330a).
{:error, changeset} with validation failures, not viewport or JS issues.claude/solutions/ firstSearch .claude/solutions/ for relevant keywords using Grep.
If matching solution exists, present it and ask: "Apply this fix, or investigate fresh?"
If Tidewave MCP is detected, start here instead of asking the user to paste errors. Auto-capture runtime context:
mcp__tidewave__get_logs level: :error -- capture recent errorsmcp__tidewave__get_source_locationmcp__tidewave__execute_sql_query to inspect statemcp__tidewave__project_eval to test hypothesesmcp__tidewave__get_source_location with component namePresent pre-populated context to the user:
Auto-captured from runtime:
- Error: {parsed error from logs}
- Location: {file:line from get_source_location}
Investigating this. Correct if wrong.
This eliminates copy-pasting errors between app and agent. If Tidewave NOT available: Fall through to Step 1.
Run mix compile --warnings-as-errors 2>&1 | head -50, then mix ecto.migrate.
Run mix test test/path_test.exs --trace. Then read the last 200 lines of log/dev.log and search for "error" or "exception" patterns.
Parse the error message — check ${CLAUDE_SKILL_DIR}/references/error-patterns.md.
File saved? Atom vs string? Data preloaded? Pattern match correct? Nil? Return value? Server restarted?
LiveView form saves silently failing? Check changeset errors
FIRST — not viewport, click mechanics, or JS. A missing
hidden_input for a required embedded field causes {:error, changeset} with no visible UI feedback.
Find what's actually happening vs what should happen.
Use /ralph-loop:ralph-loop for autonomous debugging with
clear completion criteria and --max-iterations.
${CLAUDE_SKILL_DIR}/references/error-patterns.md — Common errors and checklist${CLAUDE_SKILL_DIR}/references/investigation-template.md — Output format${CLAUDE_SKILL_DIR}/references/debug-commands.md — Debug commands and common fixes