# claude-elixir-phoenix: 26 Specialist Agents for Claude Code on Elixir and Phoenix

> A Claude Code plugin that coordinates 26 domain agents, 51 skills and 26 enforced Iron Laws for Elixir, Phoenix, LiveView, Ecto and Oban work, with generated editions for Amp, Codex, Pi, OpenCode and DeepSeek Harness. The full enforcement stack is Claude Code only.

**oliver-kriska/claude-elixir-phoenix** — 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.

- Repository: https://github.com/oliver-kriska/claude-elixir-phoenix
- Website: https://phxagents.dev
- Stars: 556 · Forks: 43
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/oliver-kriska-claude-elixir-phoenix

## What claude-elixir-phoenix solves, and who it is for

The README opens with a blunt claim: Claude Code is a capable coding assistant that 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 are Elixir-specific failure modes. A general model writes plausible Phoenix code that passes a shallow test suite and then misbehaves in production, because the mistakes live in framework semantics rather than in syntax.

The plugin is aimed at teams that already use Claude Code on an Elixir codebase. Its answer is not a better prompt. It is a set of 26 specialist agents, 51 skills and 140 references that get loaded based on which files are being edited, plus 26 Iron Laws that the plugin treats as non-negotiable. The project describes the workflow as plan, implement, review and verify, with each stage handled by agents that run in parallel and start with fresh context.

The framing matters. This is not a linter and not a formatter. It is a knowledge and enforcement layer for one language ecosystem inside one editor's assistant. If your team writes Go or TypeScript, nothing here applies.

## How the agent orchestration and Iron Laws actually work

The repository layout shows the mechanism. Agent definitions live under `.claude/` and `.agents/`, the plugin manifest under `.claude-plugin/`, and runtime-specific builds under `targets/`. A `Makefile` target called `generated-skills-sync` regenerates those runtime targets, which is why the same 51 skills can be shipped to Amp, Codex, Pi, OpenCode and DeepSeek Harness. The Python code in `lab/eval/` and `scripts/` is the scoring framework, not the plugin runtime.

The documented workflow is a three-command loop. `/phx:plan` dispatches four research agents in parallel and writes a structured plan to `.claude/plans/<feature>/plan.md`. `/phx:work` takes that path, implements task by task, and compiles after each change. `/phx:review` runs four specialist agents in parallel: idioms, security, tests and compilation. The README states that review deduplicates findings and flags pre-existing issues separately, which is the detail that decides whether a review pass is usable on a legacy codebase.

Iron Laws are the enforcement half. The README says `/phx:work` stops cold if code violates one. That is a deliberate design choice with a cost: the plugin will halt a task rather than let a known-bad pattern through, so a rule you disagree with becomes a blocker you have to work around rather than a warning you can ignore. The full list of 26 laws is published at phxagents.dev/iron-laws/.

## Installing the Claude Code plugin and running a first plan

The README does not inline the install command. It points to per-runtime guides at phxagents.dev/install/, with the Claude Code edition as the reference target. Treat that page as the source of truth for the exact command, since the plugin ships through the Claude Code plugin mechanism rather than a package registry.

Once installed, the loop starts with a plain description of the feature. The README gives this example:

```bash
/phx:plan Add real-time comment notifications
```

The documented result is a plan file written to a predictable path:

```bash
# A structured plan lands in .claude/plans/comment-notifications/plan.md
```

Execution takes that path as its argument, and the README states that the plugin compiles after each change:

```bash
/phx:work .claude/plans/comment-notifications/plan.md
```

Review is a bare command with no arguments, and the README describes four agents auditing in parallel:

```bash
/phx:review
```

What you should see is a plan document, a sequence of compile-checked edits, and a deduplicated findings list. There are also narrower entry points, including `/phx:quick`, `/phx:investigate`, `/ecto:n1-check` and `/lv:assigns`, for when a full plan is more ceremony than the task deserves.

## The runtime matrix is the real limitation

The plugin ships generated editions for Amp, Codex, Pi, OpenCode and DeepSeek Harness, and it is explicit that these are not ports of the full product. The README states that generated skills support does not imply full Claude Code feature parity, and the canonical comparison lives in docs/runtime-support.md.

The differences are concrete. On Amp you get 51 skills, 40 deterministic workflow wrappers, five read-only specialist agents, parallel review and native edit guards, but not the full 26-agent set. On Codex and DeepSeek Harness, custom agents are intentionally not included and Tidewave MCP registration stays external. On Pi, extensions, prompt templates, MCP and custom agents are not included yet. On OpenCode the target is skills-only. So the Iron Laws enforcement and the 26 specialist agents are a Claude Code feature; on other runtimes you are mostly getting the skills library.

Two further constraints are worth stating plainly. The README does not document rollback behaviour for a stopped `/phx:work` run, so recovering from an Iron Law halt is not described. And the Tidewave MCP integration, which is what would let agents inspect a running application, is registration-external on every runtime except the Claude Code edition. If your workflow depends on live introspection, verify that before you plan around it.

## How it compares with a plain CLAUDE.md and a style guide

The obvious alternative is the one most Elixir teams already have: a hand-written `CLAUDE.md` plus a style guide and a CI linter. That approach is free, versioned with the code, and tuned to your own conventions. It also degrades as it grows, because a long prose file competes for the same context window as the code being edited, and nothing enforces what it says.

The plugin's difference in approach is structural. Knowledge is split into 51 skills and 140 references that get loaded based on the files in play, so the LiveView rules arrive when you touch a LiveView and the Ecto rules arrive when you touch a schema. Enforcement moves from prose to hooks: the README lists hook registrations for auto-format, auto-compile, iron-law-verify and security, and the v3.0.1 release notes mention a hook bypass fix alongside retiring inert `CLAUDE.md` prose. That release note is the clearest statement of the project's own position, that prose in a memory file does not reliably change behaviour.

The trade-off is the reverse of the usual one. You get enforcement and domain loading, and in exchange you accept someone else's 26 rules, a regenerated `targets/` tree, and a plugin lifecycle you do not control.

## Maintenance, releases and the MIT licence

The last push to the repository was on 2026-09-10, and the most recent release in the list is v3.1.0 from 2026-08-27, described as a DeepSeek Harness target with hook documentation and an Amp watch-pr lifecycle. The two releases before it, v3.0.1 and v3.0.0, landed in August and July 2026. That is a steady cadence, and the release titles track runtime targets rather than Elixir features, which tells you where the maintenance effort is going.

Upgrade cost is real and worth budgeting. Because the runtime targets are generated, a version bump can change the `targets/` tree, the skill set and the hook registrations at once. The repository carries a `lab/eval/` scoring framework with pytest tests and a `Makefile` target named `eval-ci`, described as a lint plus all gate, so there is machinery for validating a change before you take it. There is no documented migration guide in the repository, so read the CHANGELOG before moving between major versions.

The licence is MIT, which permits commercial use and modification. The generated runtime targets inherit that, but the repository does not address how third-party contributions to `targets/` are licensed, so that is a question for your own review rather than something this article can settle.

## Conclusion

Adopt it if your team writes Elixir, Phoenix or LiveView daily and already pays for Claude Code, because the Iron Laws and the four-agent review pass only exist in the Claude Code target. Do not adopt it if you are on a different runtime and expect parity, or if you want a tool that reasons about your Ecto schemas without a running app. Before you commit, read docs/runtime-support.md and the Iron Laws list at phxagents.dev, then check whether the rules match your own conventions, since the plugin will stop a task rather than let a violation through.

## FAQ

### What is claude-elixir-phoenix?

It is a Claude Code plugin for Elixir, Phoenix and LiveView work, built around 26 specialist agents, 51 skills, 140 references and 26 Iron Laws. The README describes the workflow as planning with parallel research agents, implementing with compile checks after each change, and reviewing with four parallel audits.

### Which runtimes does claude-elixir-phoenix support besides Claude Code?

The README documents generated editions for Amp, Codex, Pi, OpenCode and DeepSeek Harness, all sharing the 51 skills. It states that generated skills support does not imply full Claude Code feature parity, and docs/runtime-support.md is the canonical comparison.

### What happens if code violates an Iron Law during /phx:work?

The README states that execution stops cold if code violates an Iron Law, and that the plugin compiles after each change. The full list of 26 laws is published at phxagents.dev/iron-laws/.

### Does claude-elixir-phoenix work on Codex or Pi?

Yes, but with deliberate omissions. On Codex and DeepSeek Harness custom agents are intentionally not included and Tidewave MCP registration remains external; on Pi, extensions, prompt templates, MCP and custom agents are not included yet.

## Sources

- [License: MIT](https://github.com/oliver-kriska/claude-elixir-phoenix/blob/main/LICENSE)
- [oliver-kriska/claude-elixir-phoenix on GitHub](https://github.com/oliver-kriska/claude-elixir-phoenix)
- [Project website](https://phxagents.dev)
- [README](https://github.com/oliver-kriska/claude-elixir-phoenix/blob/main/README.md)
- [Releases](https://github.com/oliver-kriska/claude-elixir-phoenix/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oliver-kriska-claude-elixir-phoenix