claude-elixir-phoenix: 26 Agents and 26 Iron Laws for Elixir Work in Claude Code
Claude Code plugin for Elixir/Phoenix/LiveView — 26 specialist agents, Iron Laws enforcement, and Tidewave MCP integration. Plan features with parallel research agents, execute with automatic verification, review with 4-agent parallel audits, and capture learnings as reusable knowledge.
At a glance
- What is it?
- A Claude Code plugin that splits Elixir, Phoenix, LiveView, Ecto and Oban work across specialist agents and enforces a fixed rule set at edit time. The interesting part is the enforcement layer, not the agent count.
- Who is it for?
- Adopt it if your team already runs Claude Code on an Elixir codebase and wants the Iron Laws to block edits rather than appear as review comments; the plugin's value is concentrated in that gate, not in the agent roster. Do not adopt it if you work in a runtime edition that ships skills only, because the README states hooks and custom agents are intentionally excluded there, which removes the enforcement half of the product.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The bugs the plugin is aimed at are Elixir-specific and quiet
The README opens with a concrete claim: Claude Code does not know that assign_new silently skips on reconnect, that :float will corrupt money fields, or that an Oban job is not idempotent. Those three examples set the scope precisely. The target audience is teams writing Phoenix and LiveView applications where the failure modes do not surface as compile errors or as failing tests. A money field stored as :float passes every test that does not compare exact decimals. A non-idempotent Oban job passes every test that runs the job once. A skipped assign_new on reconnect is invisible until a user reconnects mid-session and the socket state is wrong. The plugin's premise is that a general coding assistant has no reason to carry these facts, so they have to be injected as domain knowledge and then enforced as rules rather than suggested as advice. That is a narrower and more defensible pitch than general code assistance, and it is the reason the project exists as a plugin instead of a prompt collection.
Iron Laws turn domain knowledge into a gate, not a suggestion
The README describes the Iron Laws as non-negotiable rules, and the workflow shows what that means in practice: after /phx:work implements a task, the plugin compiles after each change and stops cold if code violates an Iron Law. The docs site is said to list all 26. The repository layout backs this up with hooks named auto-format, auto-compile, iron-law-verify and security, and the plugin's own dashboard counts 30 hook registrations. The distinction that matters is between a rule stated in a prompt and a rule checked by a hook. A prompt-level rule competes with everything else in the context window and degrades as the conversation grows. A hook that runs on edit and halts the workflow does not. The release notes for v3.0.1 mention a hook bypass fix and the retirement of inert CLAUDE.md prose, which reads as a correction toward exactly that position: the prose was not doing the work, the hooks were. Anyone evaluating this project should treat the hook layer as the product and the agent roster as packaging.
How a feature moves from description to merged code
The README gives a three-command loop. /phx:plan takes a feature description, dispatches four research agents against the codebase in parallel, and writes a structured plan to .claude/plans/<feature>/plan.md. /phx:work takes that path as an argument, implements task by task, compiles after each change, and stops on an Iron Law violation. /phx:review then runs four specialist agents in parallel covering idioms, security, tests and compilation, deduplicates the findings, and flags pre-existing issues separately from newly introduced ones. That last detail is a real design decision: mixing inherited problems into a review of a new change is how review output becomes noise. The agent inventory in the README divides labor by model tier, with orchestrators and the security analyzer on opus, and reviewers, architecture and domain agents on sonnet, plus haiku for some investigation work. Commands are namespaced by concern rather than by agent: /phx: for workflow, /ecto: for n1-check and constraint-debug, /lv: for assigns. The context-supervisor agent name implies context budget management across the parallel fan-out, though the README does not describe its mechanism.
Installation differs by runtime, and the editions are not equivalent
The primary target is Claude Code, and the README points to per-runtime install guides at phxagents.dev/install/ rather than listing a single install command. What the material does give is the shape of each edition. Amp gets the same 51 skills plus 40 deterministic workflow wrappers, five read-only specialist agents, parallel review and investigation, native edit and verification guards, and a native PR watch lifecycle plugin. Codex gets the native generated skills plugin covering all 51 skills including $elixir-phoenix:phx-investigate and $elixir-phoenix:phx-review, with a trust-gated destructive-command safeguard, but custom agents are intentionally not included and Tidewave MCP registration stays external. Pi gets all 51 skills with /skill:phx-investigate and /skill:phx-review, and extensions, prompt templates, MCP and custom agents are intentionally not included. OpenCode gets skills only, with the README noting that in the tested OpenCode 1.17.2 setup they are also reachable as /phx-investigate and /phx-review. DeepSeek Harness gets skills only, where a /phx-investigate or /phx-review token anywhere in a message loads the skill deterministically and dsh reads CLAUDE.md natively. The README states plainly that generated skills support does not imply full Claude Code feature parity, and points to docs/runtime-support.md as the canonical matrix.
The skills-only editions drop the enforcement half
This is the limitation worth stating without softening. On Pi and DeepSeek Harness, hooks and custom agents are intentionally not included. On Codex, custom agents are intentionally not included. If the Iron Laws are enforced through hooks, and hooks are absent from those editions, then what ships there is the knowledge layer without the gate. You get the idiom references and the workflow skills, and you get a model that has been told about assign_new and :float, but nothing stops a change that violates a rule. That is not a defect in the project so much as a constraint of the host runtimes, and the README does not pretend otherwise. It does mean the phrase 26 Iron Laws is doing different amounts of work depending on which edition you install. A team that reads the headline, installs the Codex or Pi package, and expects edit-time blocking will be disappointed by something the documentation already told them. The other unresolved item is Tidewave MCP registration, which the README describes as external on Codex and dsh; the plugin does not register it for you there.
Where a plain CLAUDE.md file is the better choice
The obvious alternative is a hand-written CLAUDE.md plus a few project conventions in the repository, which is what most Elixir teams already have. The difference in approach is that a CLAUDE.md file is prose loaded into context, while this plugin is a set of hooks that execute on edit. Prose is cheaper to write, easier to edit, and works in every runtime including the ones where this plugin ships skills only. It also degrades: the longer the session, the less reliably a stated rule is honored, and nothing halts the workflow when it is ignored. The plugin trades that flexibility for determinism and for a maintenance surface you do not control. It also brings 26 agents, 51 skills, 140 references and 30 hook registrations, which is a lot of behavior to reason about when a change does something unexpected. A team with three Elixir services and one senior engineer will likely get more from a tight CLAUDE.md. A team with a large Phoenix codebase, several contributors using Claude Code daily, and a history of shipping the same three classes of bug will get more from the gate.
Maintenance, licensing and what to check before adopting
The project is MIT licensed, which permits commercial use and modification; that is a statement about the licence text, not legal advice, and the SECURITY.md file plus the SkillSpector scan badge in the README indicate the maintainers treat the plugin's own surface as something to be scanned. The release cadence visible in the material is roughly monthly across mid-2026: v3.0.0 introduced multi-runtime skills distributions in July, v3.0.1 fixed a hook bypass and retired inert CLAUDE.md prose in August, and v3.1.0 added a DeepSeek Harness target, hook documentation and an Amp watch-pr lifecycle later that month. That cadence is the upgrade cost. A plugin that intercepts edits and runs compile and verification hooks sits in your critical path, so every upgrade is a chance to change what blocks your work, and v3.0.1 is evidence that hook behavior has changed between minor releases. Pin the version, read the release notes before moving, and check whether your Iron Law violations are actually the ones this plugin catches before you let it stop your builds.
Editorial conclusion
Adopt it if your team already runs Claude Code on an Elixir codebase and wants the Iron Laws to block edits rather than appear as review comments; the plugin's value is concentrated in that gate, not in the agent roster. Do not adopt it if you work in a runtime edition that ships skills only, because the README states hooks and custom agents are intentionally excluded there, which removes the enforcement half of the product. Before installing, read docs/runtime-support.md and confirm which of the 26 Iron Laws map to rules your codebase currently violates, since a rule that fires on every change will be disabled within a week.
Community notes