agentsclimarketplace

Elixir code review

Skill dbernazal/elixir_research/skills/elixir-code-review

Elixir content for agents to assess and improve Elixir design and implementations

Install
npx -y skills add dbernazal/elixir_research --skill elixir-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review Elixir, Phoenix, Ecto, and OTP pull requests for concrete correctness, reliability, data-boundary, error-contract, public-API, concurrency, supervision, and testing problems. Use for GitHub Copilot code review or any review containing .ex or .exs changes, especially changes involving external input, tagged tuples, processes, background work, HTTP clients, or ExUnit tests.

SKILL.md

3.4 KB, 648 tokens by cl100k_base, as published. Nobody here has run it

Elixir Code Review

Review the changed code and enough surrounding code to understand its callers, public contract, process ownership, supervision context, and existing tests.

Apply the authority order

  1. Follow the target repository's established public APIs, tests, architecture, and intentional conventions.
  2. Follow official Elixir, Erlang/OTP, Phoenix, Ecto, and dependency documentation.
  3. Apply the relevant rule cards from this skill.
  4. Use general model knowledge last.

Do not apply Phoenix- or Ecto-specific rules unless the repository uses that framework. When local architecture intentionally differs from a valid rule-card default, do not report the difference unless the change creates a concrete risk.

Perform the review

  1. Identify the behavior changed by the pull request.
  2. Select and read only the relevant references:
    • Pattern matching, guards, external input, or dynamic atoms: PM001
    • with, case, cond, if, or branching: CF001
    • Public functions, visibility, arities, options, or return contracts: FN001
    • Maps, structs, keyword lists, schemas, changesets, or options: DATA001
    • Tagged tuples, exceptions, error translation, or process failure: ERR001
    • GenServer, Task, Agent, Registry, ETS, supervision, or concurrency: OTP001
    • ExUnit, mocks, HTTP testing, process tests, or dependency injection: TEST001
  3. Use the design principles when a change crosses several of these concerns.
  4. Confirm that each suspected problem is reachable and introduced or materially worsened by the pull request.
  5. Check whether existing tests, callers, or documented behavior disprove the suspected problem.
  6. Report only findings with a concrete correctness, reliability, security, operability, or maintainability consequence.
  7. Explain the failure mode and the smallest reasonable correction.

Prioritize high-value findings

  • Unsafe handling of untrusted external data or dynamic atom creation.
  • Broken or inconsistent public return contracts.
  • Expected failures that are swallowed, leaked, or raised unexpectedly.
  • Processes without a concrete state, concurrency, lifecycle, isolation, or fault-recovery requirement.
  • Missing restart, state-recovery, timeout, or supervision semantics.
  • Race-prone process tests and arbitrary sleeps.
  • Tests that mock ordinary internal implementation instead of observable behavior.
  • Missing coverage for newly introduced success, failure, or boundary paths.

Do not report formatter issues, subjective style preferences, speculative rewrites, or an alternative design that is merely equally valid. Do not require a broad refactor when the changed lines can be corrected locally.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.