Adversarial Elixir Gate

An Elixir/OTP/Ecto/Phoenix review gate — pass/fail: a single blind reviewer subagent judges the work against this gate's rules with an adversarial mandate, and the work passes only when every rule is PASS or N/A. This skill renders verdicts; it never fixes the work.

The rules target one failure mode: code that imported the wrong mental model onto the BEAM — OO/enterprise layering, processes treated as objects, anemic data, defensive control flow, transliterated loops, and needless metaprogramming. They are grounded in the official Elixir anti-pattern catalogs and each carries an Evidence of violation paragraph so a reviewer can decide PASS/FAIL/N/A from artifact evidence alone. Judgment-call refactor guidance stays in the advisory sibling staff-level-elixir.

When to Apply

• An Elixir diff, feature, or PR is about to merge and needs an objective PASS/FAIL, not advisory feedback.
• An agent (Claude, Codex) authored the code and you want an independent check that it did not reproduce OO habits — repository wrappers over Ecto, *Service/*Manager tiers, a GenServer per entity, DI behaviours for a single implementation, raise/rescue as an if.
• Code ported from Java/Ruby/Python (or written by developers newer to the BEAM) needs auditing for paradigm fit before it calcifies.
• A refactor claims to have "made it idiomatic" and you want the claim verified, not assumed.

Do not apply to non-Elixir codebases (the reviewer prompt's precondition aborts with "GATE NOT APPLICABLE"), or when the user wants explanations and refactors rather than a verdict — that is staff-level-elixir's job. arch-delete-repository-over-ecto goes N/A when the target has no Ecto; flow-normalize-at-boundary goes N/A when the target has no external-input path. Remedies newer than the project's Elixir version are judged against the nearest available remedy — the reviewer prompt carries the version-gate table.

Review Protocol

Follow these steps exactly — the gate's value is that every review runs the same way.