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...

Security Scan

The skill is internally coherent for performing Elixir code reviews — it asks for no credentials, installs nothing, and its runtime instructions align with the stated purpose, though one instruction references a sibling verification file outside the bundle which you should confirm is safe and available in your environment.

Purpose & Capability

Name, description, and included reference docs (code-style, pattern-matching, otp-basics, documentation) match the stated purpose of reviewing .ex/.exs Elixir code; no unrelated binaries, env vars, or external services are requested.

Instruction Scope

SKILL.md contains detailed review/checklist instructions and requires the reviewer to produce anchored findings with file:line locators and code snippets — appropriate for a code-review skill. However, the 'Gates — before reporting' step mandates reading '../review-verification-protocol/SKILL.md' (a path outside this bundle). That could cause the agent to attempt to access files outside the reviewed repo; confirm the platform's file-access constraints and that the referenced protocol file is present and trustworthy.

Install Mechanism

Instruction-only skill with no install spec or code files to execute; lowest install risk.

Credentials

No environment variables, credentials, or config paths are requested. Required artifacts (code snippets, file locators) are proportional to a code-review workflow.

Persistence & Privilege

always is false, the skill is user-invocable and allows normal autonomous invocation. It does not request persistent presence or modify other skills; this is consistent with its purpose.

Assessment

This skill appears to do exactly what it claims: offline/static Elixir code review using the provided checklists. Before installing, confirm two platform details: (1) whether the agent is allowed to read files outside the reviewed project (the SKILL asks you to read ../review-verification-protocol/SKILL.md), and (2) what controls exist on sending review artifacts (the skill expects to include file:line locators and quoted snippets in findings). If you are uncomfortable with the agent accessing parent directories or embedding code snippets in reports, ask the platform to restrict file-system scope or require explicit user approval before including code excerpts in outputs.

Quick Reference

Issue Type	Reference
Naming, formatting, module structure	references/code-style.md
With clauses, guards, destructuring	references/pattern-matching.md
GenServer, Supervisor, Application	references/otp-basics.md
@moduledoc, @doc, @spec, doctests	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 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.