elixir-code-review
Reviews Elixir code for idiomatic patterns, OTP basics, and documentation. Use when reviewing .ex/.exs files, checking pattern matching, GenServer usage, or module documentation.
git clone --depth 1 https://github.com/existential-birds/beagle /tmp/elixir-code-review && cp -r /tmp/elixir-code-review/plugins/beagle-elixir/skills/elixir-code-review ~/.claude/skills/elixir-code-reviewSKILL.md
# Elixir Code Review ## Quick Reference | Issue Type | Reference | |------------|-----------| | Naming, formatting, module structure | [references/code-style.md](references/code-style.md) | | With clauses, guards, destructuring | [references/pattern-matching.md](references/pattern-matching.md) | | GenServer, Supervisor, Application | [references/otp-basics.md](references/otp-basics.md) | | @moduledoc, @doc, @spec, doctests | [references/documentation.md](references/documentation.md) | ## Review Checklist ### Code Style - [ ] Module names are CamelCase, function names are snake_case - [ ] Pipe chains start with raw data, not function calls - [ ] Private functions grouped after public functions - [ ] No unnecessary parentheses in function calls without arguments ### Pattern Matching - [ ] Functions use pattern matching over conditionals where appropriate - [ ] With clauses have else handling for error cases - [ ] Guards used instead of runtime checks where possible - [ ] Destructuring used in function heads, not body ### OTP Basics - [ ] GenServers use handle_continue for expensive init work - [ ] Supervisors use appropriate restart strategies - [ ] No blocking calls in GenServer callbacks - [ ] Proper use of call vs cast (sync vs async) ### Documentation - [ ] All public functions have @doc and @spec - [ ] Modules have @moduledoc describing purpose - [ ] Doctests for pure functions where appropriate - [ ] No @doc false on genuinely public functions ### Security - [ ] No `String.to_atom/1` on user input (use `to_existing_atom/1`) - [ ] No `Code.eval_string/1` on untrusted input - [ ] No `:erlang.binary_to_term/1` without `:safe` option ## Valid Patterns (Do NOT Flag) - **Empty function clause for pattern match** - `def foo(nil), do: nil` is valid guard - **Using `|>` with single transformation** - Readability choice, not wrong - **`@doc false` on callback implementations** - Callbacks documented at behaviour level - **Private functions without @spec** - @spec optional for internals - **Using `Kernel.apply/3`** - Valid for dynamic dispatch with known module/function ## Context-Sensitive Rules | Issue | Flag ONLY IF | |-------|--------------| | Missing @spec | Function is public AND exported | | Generic rescue | Specific exception types available | | Nested case/cond | More than 2 levels deep | ## When to Load References - Reviewing module/function naming → code-style.md - Reviewing with/case/cond statements → pattern-matching.md - Reviewing GenServer/Supervisor code → otp-basics.md - Reviewing @doc/@moduledoc → documentation.md ## Gates — before reporting Do these **in order** for the review batch. Do not publish findings until each step passes. 1. **Protocol loaded** — Read [review-verification-protocol](../review-verification-protocol/SKILL.md) and apply its checks for each finding category you use (unused, validation, security, performance, etc.). **Pass:** For every substantive finding, you can name which protocol subsection you satisfied or state **N/A** with reason (pure style). 2. **Anchored evidence** — **Pass:** Each finding includes a concrete locator: `path:line` (or line range), or `Module.function/arity` plus a short quoted snippet from the file. 3. **Claims backed by artifacts** — For assertions like unused code, missing validation, or security risk, **Pass:** You attach the supporting artifact (e.g. search results, file read scope) or downgrade the item to an explicit **question** / **uncertain** with what you did not verify. ## Before Submitting Findings Complete **Gates — before reporting** (section above) first; the verification protocol is mandatory input to those gates.
tag and push a release after the release PR is merged
create a release PR (auto-detects previous tag)
Guides architectural decisions for Deep Agents applications. Use when deciding between Deep Agents vs alternatives, choosing backend strategies, designing subagent systems, or selecting middleware approaches.
Reviews Deep Agents code for bugs, anti-patterns, and improvements. Use when reviewing code that uses create_deep_agent, backends, subagents, middleware, or human-in-the-loop patterns. Catches common configuration and usage mistakes.
Implements agents using Deep Agents. Use when building agents with create_deep_agent, configuring backends, defining subagents, adding middleware, or setting up human-in-the-loop workflows.
Guides architectural decisions for LangGraph applications. Use when deciding between LangGraph vs alternatives, choosing state management strategies, designing multi-agent systems, or selecting persistence and streaming approaches.
Reviews LangGraph code for bugs, anti-patterns, and improvements. Use when reviewing code that uses StateGraph, nodes, edges, checkpointing, or other LangGraph features. Catches common mistakes in state management, graph structure, and async patterns.
Implements stateful agent graphs using LangGraph. Use when building graphs, adding nodes/edges, defining state schemas, implementing checkpointing, handling interrupts, or creating multi-agent systems with LangGraph.