review-elixir
Comprehensive Elixir/Phoenix code review with optional parallel agents
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/review-elixirElixir Code Review
Arguments
--parallel: Spawn specialized subagents per technology area- Path: Target directory (default: current working directory)
Hard gates
Complete in order before writing Issues in the output (empty scope is allowed; fabricated findings are not).
- Scope gate: You have an explicit list of
.ex/.exs/.heexpaths under review (from Step 1 or user path). Pass: List printed or "No Elixir files in scope" — then stop with no Issues. - Linter gate (style): Step 2 commands ran for this Mix project; skipped tools are noted in one line (e.g. no
.credo.exs). Pass: You do not report a style issue that already passes the project's formatter/linter for that line. - Protocol gate:
beagle-elixir:review-verification-protocolis loaded before Step 6. Pass: At least one reported finding was checked against that checklist (state which item in the Review Summary or first Critical/Major note). - Evidence gate (Critical/Major): For each Critical or Major item, you re-read the file at
FILE:LINE(full surrounding context, not only the diff hunk). Pass: The Issue description matches observable code at that location.
Step 1: Identify Changed Files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.ex$|\.exs$|\.heex$'
Step 2: Verify Linter/Formatter Status
CRITICAL: Run project linters BEFORE flagging any style issues.
# Check formatting
mix format --check-formatted
# Check Credo if present
if [ -f ".credo.exs" ] || grep -q ":credo" mix.exs 2>/dev/null; then
mix credo --strict
fi
# Check Dialyzer if configured
if grep -q ":dialyxir" mix.exs 2>/dev/null; then
mix dialyzer --format short
fi
Rules:
- If a linter passes for a specific rule, DO NOT flag that issue manually
- Linter configuration is authoritative for style rules
- Only flag issues that linters cannot detect (semantic issues, architectural problems)
Step 3: Detect Technologies
# Detect Phoenix
grep -r "use Phoenix\|Phoenix.Router\|Phoenix.Controller" --include="*.ex" -l | head -3
# Detect LiveView
grep -r "use Phoenix.LiveView\|Phoenix.LiveComponent\|~H" --include="*.ex" -l | head -3
# Detect Oban
grep -r "use Oban.Worker\|Oban.insert" --include="*.ex" -l | head -3
# Check for test files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '_test\.exs$'
Step 4: Load Verification Protocol
Load beagle-elixir:review-verification-protocol skill and keep its checklist in mind throughout the review.
Step 5: Load Skills
Use the Skill tool to load each applicable skill.
Always load:
beagle-elixir:elixir-code-review
Conditionally load based on detection:
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-review-elixir": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
pytest-code-review
Reviews pytest test code for async patterns, fixtures, parametrize, and mocking. Use when reviewing test_*.py files, checking async test functions, fixture usage, or mock patterns.
reference-docs
Reference documentation patterns for API and symbol documentation. Use when writing reference docs, API docs, parameter tables, or technical specifications. Triggers on reference docs, API reference, function reference, parameters table, symbol documentation.
serde-code-review
Reviews serde serialization code for derive patterns, enum representations, custom implementations, and common serialization bugs. Use when reviewing Rust code that uses serde, serde_json, toml, or any serde-based serialization format. Covers attribute macros, field renaming, and format-specific pitfalls.