review-elixir

Elixir Code Review

Arguments

• --parallel: If the agent supports subagents, dispatch one specialized subagent per technology area (otherwise reviews run sequentially with identical output)
• 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).

1. Scope gate: You have an explicit list of .ex/.exs/.heex paths under review (from Step 1 or user path). Pass: List printed or "No Elixir files in scope" — then stop with no Issues.
2. 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.
3. Protocol gate: review-verification-protocol is 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).
4. 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)