claude-elixir-phoenix

oliver-kriskaMIT活跃维护

给 Claude Code 装上 Elixir/Phoenix/LiveView 专家团队,26 个专职 agent 并行调研、自动验证和审查代码,把开发经验沉淀成可复用知识。

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.

v3.2.2发布于 2026-11-02 12:18 UTC574star +1 / 7 天45fork同步于 2026-11-10 17:58 UTC

怎么上手

由 README 提炼,执行前请确认
/plugin marketplace add oliver-kriska/claude-elixir-phoenix
/plugin install elixir-phoenix
硬件要求按 README 说明

README 未说明

下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

给 Claude Code 装上 Elixir/Phoenix 领域专家,用 26 个 agent 并行规划、实现、审查并强制 Iron Laws

给 Claude Code 装上 Elixir/Phoenix/LiveView 专家团队,26 个专职 agent 并行调研、自动验证和审查代码,把开发经验沉淀成可复用知识。

核心能力

  • 用 26 个专职 agent 并行做规划、实现、审查与验证
  • 以 Iron Laws 强制拦截 assign_new、:float 金额等生产级陷阱
  • /phx:plan 派 4 个研究 agent 并行产出结构化计划文件
  • /phx:review 由 4 个专家 agent 并行审计并去重发现
  • 按编辑文件自动加载 LiveView、Ecto、Oban 等领域知识

容易踩的坑

需要 Claude Code 2.1.110 或更新版本;从 v2.x 升级时不能单独跑 claude plugin update,要先按顺序装 ecto、lv 两个兼容插件,否则整个插件加载失败;更新后需 /reload-plugins 或重启会话,命令是 /phx:* 而非 /elixir-phoenix:*

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

5 个版本v3.2.2
  1. v3.2.2v3.2.2 — deps-audit gate covers mix setup, aliases and igniter.install最新正式版2026-11-02 · 2026-11-02 12:18 UTC

    Patch: the deps-audit gate now judges mix setup, other dep-fetching aliases and mix igniter.install, and its test suite runs in CI.

    Added

    • deps-audit-gate.sh warns Claude when mix deps.update moves a branch-pinned git dep. A dep pinned to a branch (or to no ref) pulls new commits with no mix.exs change, and a vetted pin still matches. The gate allows the command and passes an additionalContext note naming the deps that will move, the commit mix.lock holds now, and the git -C deps/<name> log command to review what arrived. It never blocks on this
    • The gate's smoke suite (lab/deps-audit/smoke-test/gate-test.sh, now 30 checks) runs in make test and GitHub CI through scripts/tests/test_deps_audit_gate.py. It ran nowhere automatically before, which is how the github: gap in #160 went unnoticed. The same file checks that every last-run.json field the gate reads is documented in the /phx:deps-audit sidecar schema, the drift behind #160 §4

    Fixed

    • mix setup and other dep-fetching commands no longer skip the deps-audit gate. The hook fired only on a literal mix deps.*, so Phoenix's mix setup alias (the first command in every generated README) fetched a new git dep unchecked, and so did mix igniter.install. hooks.json now fires on Bash(*mix *), and the script judges deps.get/deps.update/deps.compile, igniter.install, and any mix.exs alias whose task list reaches them (comments stripped, up to three alias levels). Other mix commands exit at the first check with no output. For mix igniter.install name@github:org/repo (also @git:, @path:) the pin comes from the argument, since igniter writes the tuple only after the hook runs
    • hooks/docs/safety-gates.md: the deps-audit tier table was split by a paragraph, so the Tier 2 row rendered as stray text

    Docs, install guides, and the runtime compatibility matrix: https://phxagents.dev

  2. v3.2.1v3.2.1 — deps-audit gate fixes, foreground pins for dependent spawns2026-11-02 · 2026-11-02 11:25 UTC
    查看更新说明

    Patch: the deps-audit gate catches new github: deps and every block it raises can be cleared in-session (#160); dependent subagent spawns pinned to the foreground for Claude Code 2.1.302+.

    Changed

    • Single subagent spawns whose result the next step reads now run in the foreground. The context-supervisor spawns in /phx:audit, deep-bug-investigator and planning-orchestrator, the review and compounding spawns in workflow-orchestrator, and the /phx:trace example pass run_in_background: false. Since Claude Code 2.1.302 a subagent's own Agent calls default to foreground on desktop, VS Code and the SDK but stay background in the CLI, so a spawn without the flag could be read before it finished on one surface and not the other
    • hooks/docs/safety-gates.md notes that both Bash gates also cover commands started by the Monitor tool (Claude Code 2.1.314+, verified on 2.1.316)

    Fixed

    • deps-audit-gate.sh no longer lets new non-Hex deps through, and every block it raises can be cleared in-session (#160, reported by @vknez). Rule 5 now catches github: deps (it only grepped for git:/path:), joins formatter-split tuples, and ignores commented-out deps. Each new non-Hex dep normalizes to a pin (my_dep github:org/repo@tag:v1.0). A matching hex_vet.exs entry clears it, and the block message prints the /phx:deps-vet <dep> <pin> command for each dep. /phx:deps-vet now records these pins. The Tier 0 cache vouches for mix.lock only, so it no longer skips rule 5: a new git dep isn't in the lock yet. The override hint no longer suggests a PHX_SKIP_DEPS_AUDIT=1 command prefix, which never worked because the hook reads Claude Code's environment. A prefix Claude could type itself would also make every block advisory. A :new_only mode inferred from a ledger that has no block_on_unvetted key is now named in the block message, and /phx:deps-vet says the gate turns blocking when it creates the ledger. The /phx:deps-audit sidecar schema now documents the lock_sha, audit_passed and policy_mode fields the cache actually reads; the old doc described a 10-minute window the gate never checked
    • .gitattributes now pins eol=lf on its * text=auto rule. The plugin directory scanner refuses a repository whose line-ending rule leaves eol unset, so every commit since 80926d7 failed to fetch

    Docs, install guides, and the runtime compatibility matrix: https://phxagents.dev

  3. v3.2.0v3.2.0 — experimental rewrite plugin, plugin-directory hook fixes2026-10-16 · 2026-10-16 16:27 UTC
    查看更新说明

    New, experimental: rewrite 0.1.0 (Elixir Rewrite Architect) plans a rewrite of an existing app from any stack into idiomatic Elixir, hands each slice to /phx:plan, and verifies parity. It runs on Claude Code only. Install it with /plugin install rewrite@oliver-kriska; it pulls in elixir-phoenix. Two trials ported RealWorld backends (django-ninja and ASP.NET Core), and each port's release passed the whole RealWorld Hurl spec. Read the Limitations before using it on a real app.

    Adds the experimental rewrite plugin (Elixir Rewrite Architect 0.1.0) and fixes the hook scripts that still blocked v3.1.3 in the plugin directory.

    Added

    • test_hook_scripts_run_only_paths_the_directory_can_follow (contributor tooling). Rejects inline programs, eval, source, bash/command invocations and $0/BASH_SOURCE paths in hook scripts.
    • New rewrite plugin (Elixir Rewrite Architect, 0.1.0, experimental). Plans a rewrite of an app from any language into idiomatic Elixir. Five commands (/rewrite:start, analyze, architect, roadmap, verify), one reference skill (elixir-way, with stack packs for Rails, Django, Laravel/PHP, Node, Go and JVM/.NET plus a generic method), seven agents (six sonnet, elixir-way-architect on opus) and four stdlib scripts (inventory.py, ledger.py, fingerprint.py for the content identity of both trees, and evidence.py, which writes every verify record). Slices reach phx as an interview.md seed for /phx:plan; phx itself is unchanged. The dependency on elixir-phoenix lives in the marketplace entry, not plugin.json, so the plugin still loads beside --plugin-dir ./plugins/elixir-phoenix (phx@inline). Versions independently. See plugins/rewrite/README.md.
    • The rewrite inventory grades the legacy app's oracles. inventory.py (inventory version 3) adds an oracles section: tests by framework with approximate case counts, black-box API suites (Hurl requests and asserts, Postman, Bruno, REST Client, Tavern, Dredd), E2E suites, benchmark and load harnesses, API contracts and coverage config (paths only). A deterministic grade (correctness strong | moderate | weak | none, performance harness | none) states the counts and the threshold each one crossed. --oracle DIR adds a suite outside the source, such as RealWorld's specs/api, with the same symlink, special-file and stat-fence safety and outside the source fingerprint; a directory inside the source is not scanned twice. --compare still accepts version 2 inventories. The contract-surveyor names a legacy witness per contract and confirms or downgrades the grade. Roadmap puts characterization tests first on a weak grade, names each slice's black-box files and command in a new seed ## Oracle section, and writes a port-only load script when no harness exists. Verify requires a fresh passing run of those files, against the port only. It also re-runs every other command an acceptance criterion names, such as a release smoke, since a /phx:work log is a claim, and the parity auditor proposes implemented for each slice row whose code exists, so passing rows stop counting as unverified. A record missing its identity values is re-run before the audits, not after them. Verify writes its run list (commands.md) before running anything: the default commands, every command an acceptance criterion names exactly as named (a seed, --force, the full suite) and every ## Oracle command. The parity auditor checks the list against the criteria and the records, and a missing list is a finding: verify writes it before auditing, where two trial runs had skipped it. Each listed command keeps the arguments its criterion names, and a command is left out only when it cannot run: a trial verify had swapped a named seed for a rando
  4. v3.1.3v3.1.3 — Anthropic plugin directory readiness2026-09-29 · 2026-09-29 13:30 UTC
    查看更新说明

    Ready for the Anthropic plugin directory. Every hook command is a single script path, four skills no longer pre-approve Bash, the plugin has an icon and its own README, and Amp-only code no longer ships to Claude Code. The branch-freshness hook no longer runs git fetch with your credentials, and it only runs in Elixir projects.

    Added

    • Plugin icon and README. .claude-plugin/icon.svg (the phxagents.dev mark) and plugins/elixir-phoenix/README.md, which lists what the plugin runs on your machine: hooks, network calls (the Tidewave probe on localhost:4000, hex.pm, your own gh and codex) and the files it writes.
    • test_hook_scripts_parse (contributor tooling). Every hook script must pass bash -n and contain no merge-conflict markers.

    Changed

    • The Bash safety gate's hook command is now one quoted script path. The plugin directory rejects hook commands with shell operators, and block-dangerous-ops.sh was the only one with || exit 0. That suffix had kept a corrupted script (bash exits 2 on a syntax error, and exit 2 blocks the call) from blocking every Bash command. The script now checks its own syntax first (bash -n "$0" || exit 0), and test_hook_scripts_parse checks every hook script in CI. test_hook_commands_are_one_literal_script replaces the quoting test and also rejects operators, arguments and missing scripts. The Codex target keeps || exit 0.
    • Narrower allowed-tools. /lv:assigns, /phx:boundaries and /ecto:n1-check no longer pre-approve Bash, so their mix commands ask for permission like any other. /phx:deps-audit pre-approves WebFetch only for hex.pm and diff.hex.pm, not every domain, and no longer pre-approves Bash.
    • The Amp-only watch-pr sources moved out of the Claude Code plugin. plugins/elixir-phoenix/amp/ (the phx-watch-pr.ts Amp plugin, which keeps a webhook credential under ~/.config/amp/, and its skill overlay) is now scripts/port_lib/amp_overlay/. Claude Code installs no longer receive it. The generated targets/amp output is byte-identical.

    Fixed

    • check-branch-freshness no longer runs git fetch, and it only runs in Elixir projects. At every session start on a non-main branch, the hook fetched from your remotes with your SSH key or credential helper, in any git repository, Elixir or not. It now needs a mix.exs and compares against origin/main as of your last fetch.
    • /release skill (contributor tooling): git describe matches v* tags only. After claude plugin tag it returned lv--vX.Y.Z as the last release.

    Docs, install guides, and the runtime compatibility matrix: https://phxagents.dev

  5. v3.1.2v3.1.2 — Claude Code 2.1.284 and 5.5-model compatibility2026-09-29 · 2026-09-29 12:08 UTC
    查看更新说明

    Claude Code 2.1.284 and the 5.5 models. Hooks now work when the plugin's install path contains a space. Workflow rules are re-injected after compaction. Agents run on Sonnet 5.5 at medium effort, and the prompts are reworded for the new models. Six skills that rarely fired on Sonnet 5.5 have new descriptions.

    Added

    • make eval-quality, an output-quality eval (contributor tooling). Six claude plugin eval cases run each workflow with and without the plugin (--ablation with-without) and grade the resulting code, plan or findings. The cases are money stored as a float, queries in mount on a 50k-row list, an idempotent Oban worker, a plan with checkbox tasks, an investigation that can reuse a prior solution doc, and a review with nine seeded defects. On Sonnet 5.5, five runs per arm, the plugin's clearest gains are writing code against a bad local convention (money field +0.20, LiveView list +0.20) and reusing .claude/solutions/ (+0.16). Review is a tie: Claude without the plugin found all nine defects in 5 of 8 runs. Paid and not part of make ci (about $2 per run of all six cases).

    Changed

    • Aligned with the Claude 5.5 models (Opus 5.5 default since CC 2.1.280, Sonnet 5.5 since CC 2.1.284). /phx:audit pins its two general-purpose tracks to model: "sonnet": Opus is now the default model on every plan, including Pro and Team Standard, so an unpinned track ran on Opus for everyone. The eval tooling follows the new models — trigger_scorer's sonnet/opus aliases resolve to claude-sonnet-5-5/claude-opus-5-5, make eval-plugin pins Sonnet 5.5, with a new baseline of 164/269 positive recall and 233/233 clean negatives (Sonnet 5: 176/269), and /session-scan knows the 1M context window of Sonnet 5+, Opus 4.8+ and Fable. Contributor docs record that effort: high is now a step above the Opus 5.5/Sonnet 5.5 default of medium, and that Haiku 4.5 ignores effort.
    • make validate now runs claude plugin validate --strict, so a validator warning fails the gate instead of printing "passed with warnings". A pytest guard checks hook quoting in GitHub CI, which has no claude binary.
    • The five former Haiku agents run on Sonnet 5.5: context-supervisor, web-researcher, xref-analyzer, codex-reviewer and verification-runner. Haiku 4.5 is a generation behind, has a 200K window, ignores effort, and its retirement window opens on October 15, 2026; Sonnet 5.5 costs twice as much. Every agent now runs at effort: medium, the CC default for the 5.5 models — three of the four Opus agents drop from high, since Opus 5.5 at medium matches Opus 5 at high.
    • Prompts reworded for the 5.5 models. Anthropic's prompting guide for this generation warns that emphatic CRITICAL/MUST/NEVER wording over-triggers. About 100 edits across skills, agents, hook messages and CLAUDE.md replace unexplained caps, duplicated prohibitions, session-ID history notes and narration suppressors with the instruction and its reason. Iron Laws, headings, and text the port builders anchor on are unchanged.
    • /phx:full Iron Law 7 now says when to write text, instead of banning it. It was an older-model rule: a list of banned phrases and "if you catch yourself narrating, delete the text". Opus 5.5 follows such rules literally, which risks a silent autonomous run. The law now asks for a one-line status at each phase transition, a reason for each non-obvious decision, and a report of every error and blocker.
    • Amp specialists follow the canonical agent models instead of Haiku 4.5. The security specialist runs on anthropic/claude-opus-5-5; the other reviewers and the four investigation tracks run on anthropic/claude-sonnet-5, because Amp does not offer Sonnet 5.5 to plugin agents. Amp accepts any model ID at load and fails each child run at inference, so the build now fails on a canonical model alias it has

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    Elixir Phoenix Plugin for Claude Code

    Docs: phxagents.dev Security: scanned with SkillSpector

    Docs: phxagents.dev -- install guides per runtime, the runtime compatibility matrix, all 26 Iron Laws, and a browsable skill and agent catalog.

    Claude Code is great. But it doesn't know that assign_new silently skips on reconnect, that :float will corrupt your money fields, or that your Oban job isn't idempotent.

    This plugin does. It coordinates 26 specialist agents that plan, implement, review, and verify your Elixir/Phoenix code in parallel -- each with domain expertise, fresh context, and enforced Iron Laws that catch the bugs your tests won't.

    Using Amp? Install the generated edition for the same 51 Elixir, Phoenix, LiveView, Ecto, Oban, testing, and security skills, plus 40 deterministic workflow wrappers, five read-only specialist agents, parallel review/investigation, and native edit/verification guards, and the native PR watch lifecycle plugin. See Use with Amp for the important differences from the full Claude Code plugin, or the Amp install guide on phxagents.dev.

    Using Codex? Install the native generated skills plugin for all 51 skills, including $elixir-phoenix:phx-investigate and $elixir-phoenix:phx-review workflows. See Use with Codex or the Codex install guide; a trust-gated destructive-command safeguard is included, while custom agents are intentionally not included and Tidewave MCP registration remains external.

    Using Pi? Install the native generated skills package for all 51 skills, including Pi-compatible /skill:phx-investigate and /skill:phx-review workflows. See Use with Pi or the Pi install guide; extensions, prompt templates, MCP, and custom agents are intentionally not included yet. Tidewave can be used when the Pi host exposes it independently.

    Using OpenCode? Install the generated skills-only target for all 51 skills, including phx-investigate and phx-review. In the tested OpenCode 1.17.2 setup, they are also available as /phx-investigate and /phx-review; the skill tool is the portable explicit interface. See Use with OpenCode, the OpenCode guide, or the OpenCode install guide.

    Using DeepSeek Harness (dsh)? Install the generated skills-only target for all 51 skills. A /phx-investigate or /phx-review token anywhere in your message loads the skill deterministically, and dsh reads your CLAUDE.md natively. See Use with DeepSeek Harness, the dsh guide, or the dsh install guide; hooks and custom agents are intentionally not included, and Tidewave MCP registration is external.

    Compare native invocation, installation, and deliberately deferred capabilities in the canonical runtime support matrix. Generated skills support does not imply full Claude Code feature parity.

    # You describe the feature. The plugin figures out the rest.
    /phx:plan Add real-time comment notifications
    
    # 4 research agents analyze your codebase in parallel.
    # A structured plan lands in .claude/plans/comment-notifications/plan.md
    # Then:
    
    /phx:work .claude/plans/comment-notifications/plan.md
    # Implements task by task. Compiles after each change.
    # Stops cold if code violates an Iron Law.
    
    /phx:review
    # 4 specialist agents audit in parallel:
    # idioms, security, tests, compilation.
    # Deduplicates findings. Flags pre-existing issues separately.
    

    No prompt engineering. No "please check for N+1 queries." The plugin auto-loads the right domain knowledge based on what files you're editing and enforces rules that prevent the mistakes Elixir developers actually make in production.

    ┌─────────────────────────────────────────────────────────────────────┐
    │  ⚗  Elixir/Phoenix Plugin for Claude Code                           │
    │                                                                     │
    │  ┌──────────┬──────────┬──────────┬──────────┬──────────┐           │
    │  │    26    │    51    │   140    │    30    │    26    │           │
    │  │  Agents  │  Skills  │   Refs   │Hook Regs │Iron Laws │           │
    │  └──────────┴──────────┴──────────┴──────────┴──────────┘           │
    │                                                                     │
    │  AGENTS                          COMMANDS                           │
    │  ─────────────────────           ──────────────────────────         │
    │  Orchestrators (opus)            Workflow                           │
    │    workflow-orchestrator           /phx:plan    /phx:work           │
    │    planning-orchestrator           /phx:review  /phx:full           │
    │    parallel-reviewer               /phx:compound /phx:quick         │
    │    context-supervisor              /phx:brief   /phx:triage         │
    │                                                                     │
    │  Reviewers (sonnet)              Investigation & Debug              │
    │    elixir-reviewer                 /phx:investigate /phx:trace      │
    │    testing-reviewer                /ecto:n1-check   /phx:perf       │
    │    security-analyzer (opus)        /ecto:constraint-debug           │
    │    iron-law-judge                  /lv:assigns                      │
    │                                                                     │
    │  Architecture (sonnet)           Analysis & Review                  │
    │    liveview-architect              /phx:audit    /phx:verify        │
    │    ecto-schema-designer            /phx:techdebt /phx:boundaries    │
    │    phoenix-patterns-analyst        /phx:pr-review /phx:challenge    │
    │    otp-advisor                     /phx:research  /phx:document     │
    │                                                                     │
    │  Investigation (sonnet)          Knowledge (auto-loaded)            │
    │    deep-bug-investigator           liveview-patterns  ecto-patterns │
    │    call-tracer                     elixir-idioms      security      │
    │    xref-analyzer                   phoenix-contexts   oban          │
    │    verification-runner             testing   deploy   tidewave      │
    │                                                                     │
    │  Domain (sonnet)                 Hooks                              │
    │    oban-specialist                 auto-format · auto-compile       │
    │    deployment-validator            iron-law-verify · security-scan  │
    │    hex-library-researcher          debug-stmt-detect · error-critic │
    │    web-researcher                  progress-tracking · block-danger │
    │                                                                     │
    │  ───────────────────────────────────────────────────────────        │
    │  26 Iron Laws · Tidewave-aware · plan→work→verify→review→compound   │
    │  github.com/oliver-kriska/claude-elixir-phoenix                     │
    └─────────────────────────────────────────────────────────────────────┘
    

    v3.0.0 -- all 51 canonical skill trees have generated distributions for Amp, Codex, Pi, OpenCode, and DeepSeek Harness. Nine core workflows are fully adapted: the six flagship lifecycle workflows plus phx-trace, phx-audit, and phx-research. The remaining projections preserve domain knowledge but may require the runtime to translate Claude-specific orchestration. Claude Code remains the full canonical plugin; hooks, agents, MCP, instructions, and workflow portability intentionally vary by runtime. See the support matrix before assuming feature parity. Issues welcome.

    Installation

    Claude Code

    From GitHub (recommended)
    # In Claude Code, add the marketplace
    /plugin marketplace add oliver-kriska/claude-elixir-phoenix
    
    # Install the plugin
    /plugin install elixir-phoenix
    

    Requires Claude Code 2.1.110 or newer. The install name stays elixir-phoenix, while its public workflow commands remain /phx:* — Claude Code namespaces commands by the plugin's manifest name, not its install name. A fresh install also pulls in two small compatibility namespaces for /ecto:* and /lv:* automatically; you do not need to install them separately. After an update, run /reload-plugins before trying the commands in an already-open session.

    Updating from v2.x

    [!WARNING] Do not run claude plugin update on its own. v3 introduced two compatibility plugins (ecto, lv) that v2 never declared, and claude plugin update does not install dependencies a new version newly declares. The updated plugin then fails to load entirely — you lose all 36 /phx:* commands, not just /ecto:* and /lv:*. Install the two compatibility plugins first, using the exact order below.

    claude plugin marketplace update oliver-kriska
    claude plugin install ecto@oliver-kriska
    claude plugin install lv@oliver-kriska
    claude plugin update elixir-phoenix@oliver-kriska
    

    Restart Claude Code afterward. In an already-open session, /reload-plugins reloads the updated skills, agents, and hooks. Confirm that /phx:help, /ecto:n1-check, and /lv:assigns appear before continuing work.

    Already updated in the wrong order?

    If claude plugin list reports ✘ failed to load with Dependency "ecto@oliver-kriska" is not installed, install the two compatibility plugins to recover — nothing is lost, and no reinstall is needed:

    claude plugin install ecto@oliver-kriska
    claude plugin install lv@oliver-kriska
    

    Note that claude plugin install elixir-phoenix@oliver-kriska also repairs the state, but resolves only one missing dependency per run, so it needs two invocations here.

    Commands are /phx:*, not /elixir-phoenix:*

    Plugin versions before v3.0.0 shipped a manifest named elixir-phoenix, so their commands resolved as /elixir-phoenix:work even though /phx:init wrote /phx:* into CLAUDE.md. v3.0.0 renamed the manifest to phx, which is what makes /phx:* correct. If Claude Code reports /phx: commands as unknown, you are on a pre-v3 version — follow the upgrade steps above, then re-run /phx:init --update.

    Claude Code subagent compatibility

    No configuration is required. Claude Code 2.1.219+ defaults to a maximum subagent spawn depth of 3, so /phx:full, deep /phx:plan, parallel /phx:investigate, and /phx:trace can use their nested orchestrators. Claude Code 2.1.217–2.1.218 defaulted to depth 1; on those versions, or when you explicitly configure depth 1–2, the workflows keep orchestration in the main conversation and spawn leaf specialists directly. They preserve the same decisions, artifacts, verification, and review gates; only the agent topology changes.

    To explicitly enable the full nested topology, start Claude Code with depth 3:

    CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=3 claude
    

    Depth 2 is sufficient for /phx:trace's call-tracer alone. This must be set in the environment that starts Claude Code; a plugin hook cannot change its parent process environment.

    Multi-stack tip — project-scope enable. This plugin is opinionated for Elixir/Phoenix. If you work across multiple language stacks, prefer enabling it per-project rather than globally — drop this into <project>/.claude/settings.json:

    { "enabledPlugins": { "elixir-phoenix@oliver-kriska": true } }
    

    Hooks self-gate on mix.exs presence (v2.10.1+), so global enable is safe — project-scoping is just a tidiness preference.

    Companion plugin: catchup

    The same marketplace also ships catchup — a framework-agnostic /catchup return-from-absence briefing (PRs, reviews, git, Linear, calendar → one prioritized Context Brief, including which upstream changes touch your in-flight files). Independent plugin, separate manifest, install only if you want it:

    /plugin install catchup@oliver-kriska
    

    See plugins/catchup/README.md. Not coupled to Elixir/Phoenix.

    Companion plugin: rewrite (experimental)

    rewrite (Elixir Rewrite Architect) plans a rewrite of an existing app from any language into idiomatic Elixir: features as goals, why each legacy mechanism exists, a compatibility bar before any design, then vertical slices handed to /phx:plan and checked by /rewrite:verify. Stack packs for Rails, Django, Laravel/PHP, Node, Go and JVM/.NET; a generic method for the rest. It depends on elixir-phoenix. Version 0.1.0, tested on small apps only:

    /plugin install rewrite@oliver-kriska
    

    See plugins/rewrite/README.md.

    From Local Path (for development)
    git clone https://github.com/oliver-kriska/claude-elixir-phoenix.git
    
    # Option A: Add as local marketplace
    /plugin marketplace add ./claude-elixir-phoenix
    /plugin install elixir-phoenix
    
    # Option B: Test the plugin and its command namespaces directly
    claude \
      --plugin-dir ./claude-elixir-phoenix/plugins/elixir-phoenix \
      --plugin-dir ./claude-elixir-phoenix/plugins/ecto \
      --plugin-dir ./claude-elixir-phoenix/plugins/lv
    

    Keep all three --plugin-dir arguments when testing public command compatibility. The main directory provides /phx:*; the ecto and lv directories provide the legacy /ecto:* and /lv:* aliases.

    Use with Amp

    Amp supports two profiles from the same generated snapshot:

    • Hosted-native: publish the skills and plugin independently to Amp personal or workspace repositories. Use Amp's native skill: invoke command. The plugin still provides specialists, parallel analysis, and edit lock, but its filesystem wrappers cannot load hosted-only skills and native phx-full does not arm the plugin verification gate.
    • Paired-full: install matching skills and plugin locally. This preserves all 40 phx:*/ecto:*/lv:* wrappers and the wrapper-activated phx-full gate.

    Project-local paired installation is recommended for reproducible full behavior:

    cd /path/to/your-phoenix-project
    
    # Install the 51 skills into this project
    amp skill add \
      https://github.com/oliver-kriska/amp-elixir-phoenix/tree/stable/skills \
      --target "$PWD/.agents/skills"
    
    # Add deterministic workflows, read-only agents, and native guards
    mkdir -p .amp/plugins
    plugin=".amp/plugins/elixir-phoenix.ts"
    temporary="$(mktemp "${plugin}.XXXXXX")"
    curl --fail --silent --show-error --location \
      https://raw.githubusercontent.com/oliver-kriska/amp-elixir-phoenix/stable/plugins/elixir-phoenix.ts \
      --output "$temporary" && mv "$temporary" "$plugin"
    

    Open Amp's command palette with Ctrl+O, run skill: invoke, choose phx-investigate, and send the bug details. This native path resolves the effective skill whether it is local, built-in, personal hosted, or workspace hosted. With paired-full, the familiar phx: investigate, phx: review, ecto: n1-check, and lv: assigns wrappers are also available; they inject the matching local skill for one turn. phx: full activates the plugin verification gate only through that wrapper, not through native skill: invoke.

    amp skill add --global means machine-local, under ~/.config/agents/skills/; it is not personal hosted/account-wide. Personal hosted artifacts are managed through Amp's Personal Settings or personal Git repositories and work across machines and orbs. See the complete Amp guide for hosted publication, source precedence, wrapper limits, updates, fallback installation, specialists, safety boundaries, and verification.

    phx-watch-pr additionally needs the separate phx-watch-pr.ts plugin. Install it into the project where the worker Orb opens and watches PRs:

    mkdir -p .amp/plugins
    plugin=".amp/plugins/phx-watch-pr.ts"
    temporary="$(mktemp "${plugin}.XXXXXX")"
    curl --fail --silent --show-error --location \
      https://raw.githubusercontent.com/oliver-kriska/amp-elixir-phoenix/stable/plugins/phx-watch-pr.ts \
      --output "$temporary" && mv "$temporary" "$plugin"
    

    It holds a bounded Orb keep-alive lease, filters deployment-like checks out of readiness, persists reload-safe state, and wakes the same worker thread only for failed/cancelled required CI, unresolved feedback, and terminal outcomes. With --fix, actionable feedback and branch-owned CI failures are repaired in one serialized same-thread workflow. It never blindly reruns shared CI, merges, or deploys.

    Use with Codex

    Codex installs the generated target as a native skills plugin. Registration and installation are separate steps:

    codex plugin marketplace add oliver-kriska/claude-elixir-phoenix --ref main
    codex plugin add elixir-phoenix@oliver-kriska
    codex plugin list
    

    Start a fresh Codex session, then invoke workflows explicitly with $elixir-phoenix:phx-investigate or $elixir-phoenix:phx-review, browse them with /skills, or let Codex select a relevant skill from its description. Codex namespaces plugin skills; unqualified $phx-investigate is not an explicit alias. This edition also ships one synchronous native hook that blocks destructive Ecto resets/drops, unguarded force pushes, and accidental MIX_ENV=prod mix commands. Codex requires users to review and trust plugin hooks before they run; the skills work without it. Custom agents, plugin-root instructions, the remaining Claude hooks remain deferred; Tidewave MCP registration is external. See the complete Codex guide for updates, uninstall, isolation, troubleshooting, tested version, and capability details.

    Use with Pi

    Install the repository as a Pi package globally, or add -l to scope it to the current project:

    pi install git:github.com/oliver-kriska/claude-elixir-phoenix
    pi list
    

    Start a fresh Pi session, then invoke workflows explicitly with /skill:phx-investigate or /skill:phx-review. Pi can also select a skill from its description automatically. This edition ships skills and their complete bundled resources only—not extensions, prompt templates, custom agents, or package-root instructions. Tidewave MCP registration is external. See the complete Pi guide for project-local installation, updates, uninstall, isolation, troubleshooting, tested version, and capability details.

    Use with OpenCode

    OpenCode 1.17.2 discovers the generated skills recursively. Install a sparse checkout into one project (recommended) or the global OpenCode config root:

    git clone --filter=blob:none --sparse https://github.com/oliver-kriska/claude-elixir-phoenix.git .opencode/skills/elixir-phoenix
    git -C .opencode/skills/elixir-phoenix sparse-checkout set targets/opencode
    

    Start a fresh session and explicitly say “Use the skill tool to load the phx-investigate skill, then …”. In the tested OpenCode 1.17.2 setup, /phx-investigate and /phx-review also work when they do not collide with existing commands, but the skill tool is the documented portable interface. OpenCode selects the model implicitly. This target contains skills and complete bundled resources only—not hooks or custom agents. Tidewave MCP registration is external. Investigation, review, plan, work, PR-review, and full-lifecycle workflows are explicitly adapted; some other skills may still describe optional Claude-specific orchestration APIs. See the OpenCode installation and support guide for global setup, updates, uninstall, feature-branch review, discovery debugging, and limitations.

    Use with DeepSeek Harness

    DeepSeek Harness scans a fixed set of skill roots and does not recurse, so point its provider at the generated directory rather than nesting a checkout:

    cd /path/to/your-phoenix-project
    git clone --filter=blob:none --sparse https://github.com/oliver-kriska/claude-elixir-phoenix.git .dsh/vendor/elixir-phoenix
    git -C .dsh/vendor/elixir-phoenix sparse-checkout set targets/dsh
    

    Then add customSkillDirs: [<abs-path>/.dsh/vendor/elixir-phoenix/targets/dsh/skills] to the skill-filesystem row in your profile's cordis.patch.yml, or simply copy targets/dsh/skills/. into .agents/skills/.

    Use a /phx-investigate or /phx-review token anywhere in a message — dsh's pre-step boundary injects the full skill body deterministically — or ask the model to load the skill through its skill tool. dsh reads CLAUDE.md natively, so /phx:init output applies with no porting. This target contains skills and complete bundled resources only: not hooks, custom agents, or MCP. Custom agents are not applicable rather than deferred, because dsh has no markdown agent registry. Tested against dsh 0.1.1-rc.2, which is a developer preview with breaking changes expected. See the dsh guide for both install options, discovery roots, and the full capability boundary.

    Getting Started

    The remainder of this README describes the full Claude Code plugin and uses Claude Code /phx:*, /ecto:*, and /lv:* syntax. For generated runtimes, translate invocations using the runtime guide: Amp natively uses skill: invoke and paired-full also provides generated entries such as phx: investigate; Codex uses $elixir-phoenix:<skill>, Pi uses /skill:<name>, OpenCode uses its skill tool, and dsh uses a /phx-<skill> token or its skill tool. Generated editions do not install Claude Code's complete custom agent, lifecycle-hook, permission, or MCP configuration.

    New to the plugin? Run the interactive tutorial:

    /phx:intro
    

    It walks through the workflow, commands, and features in 6 short sections (~5 min). Skip to any section with /phx:intro --section N.

    Quick Examples

    # Just describe what you need — the plugin detects complexity and suggests the right approach
    > Fix the N+1 query in the user dashboard
    
    # Plan a feature with parallel research agents, then execute
    /phx:plan Add email notifications for new comments
    /phx:work .claude/plans/email-notifications/plan.md
    
    # Full autonomous mode — plan, implement, review, capture learnings
    /phx:full Add user profile avatars with S3 upload
    
    # 4-agent parallel code review (idioms, security, tests, compilation)
    /phx:review
    
    # Quick implementation — skip ceremony, just code
    /phx:quick Add pagination to the users list
    
    # Structured bug investigation with 4 parallel tracks
    /phx:investigate Timeout errors in the checkout LiveView
    
    # Project health audit across 5 categories
    /phx:audit
    

    The plugin auto-loads domain knowledge based on what files you're editing (LiveView patterns for *_live.ex, Ecto patterns for schemas, security rules for auth code) and enforces Iron Laws that prevent common Elixir/Phoenix mistakes.

    How It Works

    The Lifecycle

    The plugin implements a Brainstorm, Plan, Work, Verify, Review, Compound lifecycle. Each phase produces artifacts in a namespaced directory:

    /phx:brainstorm → /phx:plan → /phx:work → /phx:verify → /phx:review → /phx:compound
           │               │           │            │              │              │
           ↓               ↓           ↓            ↓              ↓              ↓
      interview.md    plans/{slug}/  (in namespace) (in namespace) (in namespace) solutions/
    
    • Plan -- Research agents analyze your codebase in parallel, then synthesize a structured implementation plan
    • Work -- Execute the plan task-by-task with quick compile checks after each change
    • Verify -- Full verification loop (compile, format, credo, test) before review
    • Review -- Four specialist agents audit your code in parallel (idioms, security, tests, static analysis)
    • Compound -- Capture what you learned as reusable knowledge for future sessions

    Key Concepts

    • Filesystem is the state machine. Each phase reads from the previous phase's output. No hidden state.
    • Plan namespaces. Each plan owns all its artifacts in .claude/plans/{slug}/ -- plan, research, reviews, progress, scratchpad.
    • Plan checkboxes track progress. [x] = done, [ ] = pending. /phx:work finds the first unchecked task and continues.
    • One plan = one work unit. Large features get split into multiple plans. Each is self-contained.
    • Agents are automatic. The plugin spawns specialist agents behind the scenes. You don't manage them directly.

    Plan Namespaces

    Every plan gets its own directory with all related artifacts:

    .claude/
    ├── plans/{slug}/          # Everything for ONE plan
    │   ├── plan.md            # The plan itself (checkboxes = state)
    │   ├── research/          # Research agent output
    │   ├── reviews/           # Review findings (individual tracks)
    │   ├── summaries/         # Compressed multi-agent output
    │   ├── progress.md        # Session progress log
    │   └── scratchpad.md      # Auto-written decisions, dead-ends, handoffs
    ├── reviews/               # Ad-hoc reviews (no plan context)
    └── solutions/             # Compound knowledge (reusable across plans)
    

    No more scattered files across .claude/planning/, .claude/progress/, .claude/reviews/. One plan, one directory, everything together.

    Architecture

    Agent Hierarchy

    The plugin uses 26 agents organized into 3 tiers:

                        ┌──────────────────────────────┐
                        │  Orchestrators (opus model)  │
                        │  Coordinate phases, spawn    │
                        │  specialists, manage flow    │
                        └──────────┬───────────────────┘
                                   │
            ┌──────────────────────┼──────────────────────┐
            │                      │                      │
            ▼                      ▼                      ▼
    ┌───────────────┐  ┌───────────────────┐  ┌────────────────────┐
    │ workflow-     │  │ planning-         │  │ parallel-          │
    │ orchestrator  │  │ orchestrator      │  │ reviewer           │
    │ (full cycle)  │  │ (research phase)  │  │ (review phase)     │
    └───────────────┘  └───────────────────┘  └────────────────────┘
                                   │                      │
                        ┌──────────┼──────────┐    ┌──────┼──────┐
                        ▼          ▼          ▼    ▼      ▼      ▼
                 ┌──────────┐ ┌────────┐ ┌──────┐ ... 4 specialist
                 │ liveview │ │ ecto   │ │ web  │     review agents
                 │ architect│ │ schema │ │ rsch │
                 └──────────┘ └────────┘ └──────┘
                                   │
                        ┌──────────┴──────────┐
                        ▼                     ▼
                 ┌────────────┐      ┌──────────────┐
                 │  context-  │      │ Orchestrator  │
                 │ supervisor │ ───► │ reads ONLY    │
                 │  (sonnet)  │      │ the summary   │
                 └────────────┘      └──────────────┘
    

    Orchestrators (opus, medium effort) -- Primary workflow coordinators, security-critical analysis. Specialists (sonnet) -- Domain experts, secondary orchestrators, judgment-heavy tasks. sonnet resolves to Sonnet 5.5 (1M context, half Opus 5.5's price).

    The Context Supervisor Pattern

    When an orchestrator spawns 4-8 research agents, their combined output can exceed 50k tokens -- flooding the parent's context window. The context-supervisor solves this using an OTP-inspired pattern:

    ┌────────────────────────────────────────────────────┐
    │  Orchestrator (thin coordinator, ~10k context)     │
    │  Only reads: summaries/consolidated.md             │
    └──────────────────┬─────────────────────────────────┘
                       │ spawns AFTER workers finish
    ┌──────────────────▼─────────────────────────────────┐
    │  context-supervisor (sonnet, fresh 1M context)     │
    │  Reads: all worker output files                    │
    │  Applies: compression strategy based on size       │
    │  Validates: every input file represented           │
    │  Writes: summaries/consolidated.md                 │
    └──────────────────┬─────────────────────────────────┘
                       │ reads from
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
      worker 1      worker 2      worker N
      research/     research/     research/
      patterns.md   security.md   liveview.md
    

    How compression works:

    Total OutputStrategyCompressionWhat's Kept
    Under 8k tokensIndex~100%Full content with file list
    8k - 30k tokensCompress~40%Key findings, decisions, risks
    Over 30k tokensAggressive~20%Only critical items

    The supervisor also deduplicates -- if two agents flag the same issue (e.g., both the security analyzer and code reviewer find a missing authorization check), it merges them into one finding with both sources cited.

    Used by: planning-orchestrator (research synthesis), parallel-reviewer (review deduplication), audit skill (cross-category analysis).

    How Planning Works

    When you run /phx:plan Add real-time notifications:

    1. planning-orchestrator analyzes your request
       │
    2. Spawns specialists IN PARALLEL based on feature needs:
       ├── phoenix-patterns-analyst  (always -- scans your codebase)
       ├── liveview-architect        (if UI/real-time feature)
       ├── ecto-schema-designer      (if database changes needed)
       ├── security-analyzer         (if auth/user data involved)
       ├── oban-specialist           (if background jobs needed)
       ├── web-researcher            (if unfamiliar technology)
       └── ... up to 8 agents
       │
    3. Each agent writes to plans/{slug}/research/{topic}.md
       │
    4. context-supervisor compresses all research into one summary
       │
    5. Orchestrator reads the summary + synthesizes the plan
       │
    6. Output: plans/{slug}/plan.md with [P1-T1] checkboxes
    

    How Review Works

    When you run /phx:review:

    1. parallel-reviewer collects your git diff
       │
    2. Delegates to 4 EXISTING specialist agents:
       ├── elixir-reviewer      → Idioms, patterns, error handling
       ├── security-analyzer    → SQL injection, XSS, auth gaps
       ├── testing-reviewer     → Test coverage, factory patterns
       └── verification-runner  → mix compile, format, credo, test
       │
    3. Each writes to plans/{slug}/reviews/{track}.md
       │
    4. context-supervisor deduplicates + consolidates
       │
    5. Output: plans/{slug}/summaries/review-consolidated.md
    

    Hooks — the deterministic layer

    Skills and agents are instructions a model may or may not follow. Hooks are shell scripts that always run. The plugin ships 23 of them across 10 lifecycle events:

    • Block destructive commands — mix ecto.reset/drop, force pushes, MIX_ENV=prod tasks other than release builds, and pkill -f beam-style pattern kills are denied before they execute (also inside a script the command runs), with a safer alternative attached
    • Verify Iron Laws on every edit — the lines you just wrote are scanned for :float money fields, String.to_atom on user input, raw/1 with a variable, implicit cross joins, unsupervised start_link
    • Inject context where models can't reach it — all 26 Iron Laws into every spawned subagent; /phx: routing suggestions on PR URLs and stack traces
    • Keep the plan workflow coherent — hard-stop after planning, re-inject phase rules and scratchpad dead ends across compaction
    • Break debugging loops — repeated mix failures escalate from hints to a structured critic that consolidates the error history

    Everything Elixir-specific self-gates on mix.exs, so the plugin is inert in your non-Elixir repos. Hooks fail open — a broken hook means the guard is off, never that the session is unusable.

    → HOOKS.md for the full list, the lifecycle diagram, and per-hook deep dives.

    Usage Guide

    Quick tasks (bug fixes, small changes)

    Just describe what you need. The plugin auto-detects complexity and suggests the right approach:

    > Fix the N+1 query in the dashboard
    
    Claude: This is a simple fix (score: 2). I'll handle it directly.
    

    Or use /phx:quick to skip ceremony:

    /phx:quick Add pagination to the users list
    

    Medium tasks (new features, refactors)

    Use /phx:plan to create an implementation plan, then /phx:work to execute it:

    /phx:plan Add email notifications for new comments
    

    The plugin will:

    1. Spawn research agents to analyze your codebase patterns
    2. Show a completeness check (every requirement mapped to a task)
    3. Ask you how to proceed (start implementation, review plan, adjust)

    When starting implementation, the plugin recommends a fresh session for plans with 5+ tasks. The plan file is self-contained, so no context from the planning session is needed:

    # In a new Claude Code session:
    /phx:work .claude/plans/email-notifications/plan.md
    

    Large tasks (new domains, security features)

    Use deep research planning:

    /phx:plan Add OAuth login with Google and GitHub --depth deep
    

    This spawns 4+ parallel research agents, then produces a detailed plan. For security-sensitive features, the plugin will ask clarifying questions before proceeding. Or use /phx:full for fully autonomous development.

    Fixing review issues

    After implementing, run a review:

    /phx:review
    

    Four parallel agents check your code (idioms, tests, security, compilation). If blockers are found, the plugin asks whether to replan or fix directly:

    Review found 2 blockers:
    1. Missing authorization in handle_event -- security risk
    2. N+1 query in list_comments -- performance issue
    
    Options:
    - Replan fixes (/phx:plan --existing)
    - Fix directly (/phx:work)
    - Handle myself
    

    Project health checks

    Run a comprehensive audit with 5 parallel specialist agents:

    /phx:audit                    # Full audit
    /phx:audit --quick            # 2-3 minute pulse check
    /phx:audit --focus=security   # Deep dive single area
    /phx:audit --since HEAD~10    # Audit recent changes only
    

    The audit scores your project across 5 categories (architecture, performance, security, tests, dependencies) and produces an actionable report.

    Full autonomous mode

    For hands-off development:

    /phx:full Add user profile avatars with S3 upload
    

    Runs the complete cycle: plan (with research), work, verify, review. After review fixes, re-verifies before cycling back. Captures learnings on completion.

    Workflow Tips

    Context management

    • /phx:plan creates a self-contained plan file with all implementation details
    • For 5+ task plans, start /phx:work in a fresh session to maximize context space
    • For small plans (2-4 tasks), continuing in the same session is fine

    Resuming work

    Plan checkboxes are the state. If a session ends mid-work:

    # Just run /phx:work on the same plan -- it finds the first [ ] and continues
    /phx:work .claude/plans/my-feature/plan.md
    

    Splitting large features

    When a feature has 10+ tasks across different domains, the plugin offers to split into multiple plan files:

    Created 3 plans (14 total tasks):
    1. .claude/plans/auth/plan.md (5 tasks -- login, register, reset)
    2. .claude/plans/profiles/plan.md (4 tasks -- avatar, bio, settings)
    3. .claude/plans/admin/plan.md (5 tasks -- dashboard, roles)
    
    Recommended order: 1 -> 2 -> 3
    

    Execute each plan separately with /phx:work.

    Learning from mistakes

    After fixing a bug or receiving a correction:

    /phx:learn-from-fix Fixed N+1 query -- always preload associations in context functions
    /phx:learn-from-fix --library ical --scope personal ICal.to_ics output needs CRLF line endings
    

    This stores verified general lessons in personal ~/.claude/CLAUDE.md, project instructions, or project-keyed memory. The library route creates or safely updates native background knowledge at ~/.claude/skills/hex-<package>/SKILL.md (personal) or .claude/skills/hex-<package>/SKILL.md (project). Claude selects it from its description; dependency presence alone does not guarantee activation. Cached plugin files are never modified.

    Iron Laws (Non-Negotiable Rules)

    The plugin enforces critical rules and stops with an explanation if code would violate them:

    LiveView: No database queries in disconnected mount. Use streams for lists >100 items. Check connected?/1 before PubSub subscribe.

    Ecto: Never use :float for money. Always pin values with ^ in queries. Separate queries for has_many, JOIN for belongs_to.

    Oban: Jobs must be idempotent. Args use string keys. Never store structs in args.

    Security: No String.to_atom with user input. Authorize in every LiveView handle_event. Treat forms, hooks, and phx-value-* as user-controlled. IDs rendered in HTML or event payloads are public identifiers, not proof of access. Never use raw/1 with untrusted content.

    Deployment: Keep core release secrets required, but gate credentials for optional services behind the feature that enables them. runtime.exs also runs when an eval-based migration boots the release, so unconditional S3 or Redis requirements can break unrelated migrations.

    OTP: No process without a runtime reason. Supervise all long-lived processes.

    Elixir: Declare @external_resource for compile-time files. Wrap third-party library APIs behind project-owned modules. Never use assign_new for values refreshed every mount.

    Code style: Comments aren't commit messages — a change's reasoning goes in the commit/PR, not the code. No issue-reference tags inline (# ENA-1234).

    Commands Reference

    Workflow

    CommandDescription
    /phx:full <feature>Full autonomous cycle (plan, work, verify, review, compound); --codex adds a cross-model review track
    /phx:brainstorm <topic>Adaptive requirements gathering before planning
    /phx:plan <input>Create implementation plan with specialist agents
    /phx:plan --existingEnhance existing plan with deeper research
    /phx:work <plan-file>Execute plan tasks with verification
    /phx:review [focus]Multi-agent code review (4 parallel agents)
    /phx:compoundCapture solved problem as reusable knowledge
    /phx:triageInteractive triage of review findings
    /phx:documentGenerate @moduledoc, @doc, README, ADRs
    /phx:learn-from-fix [--library <pkg> --scope personal|project] <lesson>Capture verified general or package lessons
    /phx:brief <plan>Interactive plan walkthrough
    /phx:perfPerformance analysis with specialist agents
    /phx:pr-reviewAddress PR review threads — fetch, fix, reply, resolve
    /phx:watch-pr <PR#>Background-watch a PR for reviews + CI; --codex adds a Codex cloud review loop
    /phx:codex-loopFix until Codex CLI review is clean (optional, needs codex)

    Utility

    CommandDescription
    /phx:introInteractive plugin tutorial (6 sections, ~5 min)
    /phx:initInitialize plugin in a project (auto-activation rules)
    /phx:helpInteractive command advisor — recommends the right command
    /phx:quick <task>Fast implementation, skip ceremony
    /phx:investigate <bug>Systematic bug debugging (4 parallel investigation tracks)
    /phx:research <topic>Research Elixir topics on the web
    /phx:verifyRun full verification (compile, format, credo, test — plus dialyzer when configured)
    /phx:permissionsScan sessions, recommend safe Bash permissions
    /phx:trace <function>Build call trees to trace function flow
    /phx:boundariesAnalyze Phoenix context boundaries with mix xref
    /phx:examplesPractical examples and pattern walkthroughs
    /phx:recall <question>Recall prior work — solution docs, git history, sessions
    /ecto:constraint-debugDebug Ecto constraint violations

    Analysis

    CommandDescription
    /ecto:n1-checkDetect N+1 query patterns
    /lv:assigns <file>Audit LiveView assigns for memory issues
    /phx:techdebtFind technical debt and refactoring opportunities
    /phx:auditFull project health audit with 5 parallel agents
    /phx:challengeRigorous review mode ("grill me")

    Security & dependencies

    CommandDescription
    /phx:deps-updateBump outdated Hex deps — changelogs, coupled groups, grouped PRs
    /phx:deps-audit [--base R]Hex supply-chain audit (8 rules + CVE + differential)
    /phx:deps-vet <pkg> <ver>Manage the hex_vet.exs audit ledger (cargo-vet style)

    Agents (26)

    AgentModelMemoryRole
    workflow-orchestratoropusprojectFull cycle coordination (plan, work, review)
    planning-orchestratoropusprojectParallel research agent coordination
    parallel-revieweropus--4-agent parallel code review
    deep-bug-investigatoropus--4-track parallel bug investigation
    call-tracersonnet--Parallel call tree tracing
    security-analyzeropus--OWASP vulnerability scanning
    context-supervisorsonnet--Multi-agent output compression
    verification-runnersonnet--mix compile, format, credo, test
    iron-law-judgesonnet--Pattern-based Iron Law detection
    xref-analyzersonnet--Module dependency analysis
    hex-library-researchersonnet--Hex.pm library evaluation
    liveview-architectsonnet--Component structure, streams, async patterns
    ecto-schema-designersonnet--Migrations, data models, query patterns
    phoenix-patterns-analystsonnetprojectCodebase pattern discovery
    elixir-reviewersonnet--Code idioms, patterns, conventions
    testing-reviewersonnet--ExUnit, Mox, LiveView test patterns
    oban-specialistsonnet--Worker idempotency, error handling
    otp-advisorsonnet--GenServer, Supervisor, process design
    deployment-validatorsonnet--Docker, Kubernetes, Fly.io config
    web-researchersonnet--ElixirForum, HexDocs, GitHub research
    ash-resource-designersonnet--Ash resource design (the "Ash Way")
    ash-policy-reviewersonnet--Ash policy authorization audit
    ash-query-optimizersonnet--Ash N+1 loads, aggregates vs load
    requirements-verifiersonnet--Implementation vs task-requirement check
    hex-deps-triagersonnet--Hex supply-chain audit finding triage
    codex-reviewersonnet--Codex CLI bridge — cross-model review (opt.)

    Agents with project memory build up knowledge across sessions in .claude/agent-memory/<agent-name>/. Orchestrators remember architectural decisions; pattern analysts skip redundant discovery.

    Reference Skills (Auto-Loaded)

    These load automatically based on file context -- no commands needed:

    SkillTriggers On
    elixir-idiomsOTP/BEAM code, GenServer, Supervisor, Task
    phoenix-contextsContext modules, router, plugs, controllers
    liveview-patterns*_live.ex, mount, handle_event, streams
    ecto-patternsSchemas, migrations, Repo calls, changesets
    testing*_test.exs, factories, test support
    obanOban workers, perform/1, queue config
    securityAuth, event trust, CSRF/CSP, input validation
    deployDockerfile, runtime config, releases
    tidewave-integrationRuntime debugging, live process inspection
    intent-detectionFirst message routing to /phx: commands
    compound-docsSolution documentation lookups

    Tidewave MCP Integration

    When your Phoenix app runs with Tidewave, the plugin detects the local server and prefers its runtime tools. Add Tidewave to the application:

    # Add to mix.exs
    {:tidewave, "~> 0.6", only: :dev}
    
    # Add to endpoint.ex (in dev block)
    plug Tidewave
    

    Then register the running endpoint with Claude Code, replacing $PORT with the Phoenix port:

    claude mcp add --transport http tidewave \
      http://localhost:$PORT/tidewave/mcp
    

    Use /mcp to verify the connection. The plugin does not silently register a fixed-port MCP endpoint. Once connected, Tidewave can execute Elixir code, run SQL queries, get documentation for exact dependency versions, introspect Ecto schemas, and read application logs.

    Requirements

    • Claude Code CLI
    • Elixir/Phoenix project

    Optional

    • Tidewave for runtime debugging
    • ccrider for session analysis (see Contributing)
    • Ralph Wiggum Loop for autonomous iteration across context resets
    • OpenAI Codex as an external reviewer: /phx:review --codex, /phx:full --codex, and /phx:codex-loop use the local codex CLI; /phx:watch-pr --codex uses the Codex GitHub connector. Install the shared Elixir review rubric into AGENTS.md via /phx:init. Users without codex are unaffected — all codex behavior is flag-gated

    Security

    This plugin runs skills, agents, and hooks inside Claude Code with your tool permissions, so it ships a verifiable security posture:

    • Independently scanned with NVIDIA SkillSpector (static analysis, zero covert-egress findings): 66 / 77 components SAFE, 7 CAUTION, 4 DO_NOT_INSTALL raw. The four DO_NOT_INSTALL components are documented false positives with reviewed baselines, so after baselines 0 remain and the scan gate passes (the 7 CAUTION-tier components stay documented). A static scanner flags the safety-enforcing and security-auditing skills precisely because they name dangerous patterns in order to forbid or detect them (e.g. the line literally reads NEVER bypass security checks for speed).
    • No telemetry or covert egress; workflows can make visible, user-authorized GitHub, Hex, web-search, or configured MCP calls through the host runtime. Review agents are read-only by default (source edits disallowed), and the Bash hooks are auditable in plugins/elixir-phoenix/hooks/ — every one of them is documented in HOOKS.md.

    Full report, line-by-line triage, and a reproduce-it-yourself command live in SECURITY.md. Re-run the scan anytime with make security.

    Contributing

    PRs welcome! See CLAUDE.md for full conventions.

    Quality Gate

    Every PR must pass the CI quality gate (lint + test + eval). Run locally before pushing:

    make help             # Show all available commands
    make eval             # Quick: lint + score changed skills/agents only
    make eval-all         # Full structural: all 51 skills + all 26 agents
    make eval-fix         # Auto-fix lint + show failures + suggest autoresearch
    make test             # Pytest suites for the eval framework and port tooling
    make generated-skills-sync # Regenerate and verify all four runtime targets
    make ci               # Full CI: lint + test + validate + eval + security (same as GitHub Actions)
    

    The eval framework scores skills across 8 dimensions and agents across 5 dimensions. Skills must score >= 0.95 to pass. Run make eval-all for details.

    Development Rules

    • Skills: ~100 lines SKILL.md + references/ for details. Must include Iron Laws, "Use when..." in description.
    • Agents: under 300 lines, disallowedTools: Write, Edit, NotebookEdit for reviewers, no permissionMode (plugin agents ignore it).
    • All markdown passes npm run lint
    • New skills/agents must pass npm run eval before merging
    • Autoresearch: Run npm run eval:fix to auto-detect and fix quality issues

    Autoresearch (Self-Improvement Loop)

    The plugin includes an internal eval framework (lab/eval/) that scores all skills and agents. When quality drops, the autoresearch loop can fix it:

    # Score everything, show failures, get auto-fix command
    npm run eval:fix
    
    # Or run the autoresearch loop directly (targets weakest skill, fixes one issue per iteration)
    claude -p 'Run autoresearch...' --allowedTools 'Edit,Read,Write,Bash,Glob,Grep'
    

    The eval framework uses 24 deterministic Python matchers plus a separate, fresh Haiku behavioral gate. make eval-full requires every skill to reach 75% trigger accuracy; ignored local result caches never affect structural CI. See lab/eval/ for details.

    Analyze your sessions to improve the plugin

    The plugin includes session analysis tools that help identify improvement opportunities. If you use this plugin (or work on Elixir/Phoenix projects with Claude Code), you can analyze your own sessions to find patterns that the plugin should handle better.

    Setup:

    1. Clone this repo: git clone https://github.com/oliver-kriska/claude-elixir-phoenix.git
    2. Install ccrider MCP: claude mcp add ccrider -- npx @neilberkman/ccrider

    Available tools (dev-only, not shipped with the plugin):

    # Tier 1: Discover sessions and compute deterministic metrics
    /session-scan
    /session-scan --project myapp
    
    # Tier 2: Qualitative analysis of high-signal sessions
    /session-deep-dive
    /session-deep-dive --date 2026-03-01
    
    # Trends: Windowed aggregates (7d/30d/all) from metrics ledger
    /session-trends
    /session-trends --compare baseline
    /session-trends --html out.html       # HTML report with ASCII bar charts
    
    # Pure context-window stats (max tokens, ctx %, compaction rate) across raw JSONL
    python3 .claude/skills/session-scan/references/compute-metrics.py \
      --scan-jsonl ~/.claude/projects/<project-id>/ \
      --since 2026-04-01 --html ctx-stats.html
    
    # Skill effectiveness monitoring (requires session-scan data)
    /skill-monitor                  # Dashboard: all skills
    /skill-monitor --improve        # Generate improvement recommendations
    

    What session analysis finds

    • Friction points -- where you got stuck, repeated commands, abandoned approaches
    • Workflow patterns -- how you work (planning vs diving in, tool usage)
    • Plugin improvement opportunities -- missing automation, skills, or Iron Laws

    Each analysis report includes a Plugin Improvement Opportunities section that identifies:

    • Manual workflows that could be automated by a new skill or hook
    • Code patterns that caused bugs but the plugin doesn't catch (Iron Law candidates)
    • Missing skills or agents for common tasks
    • Auto-loading gaps where skills should trigger but don't

    Share these findings in issues or PRs to help make the plugin better for everyone.

    Roadmap

    • elixir-inspector (in progress) -- Separate plugin for 6-layer codebase analysis. Generates Credo checks, skills, CI steps, and review prompts from your project patterns. See the open PR.
    • Tier 2/3 behavioral eval -- Instruction-following tests and full A/B skill comparison (with-skill vs without-skill outcome quality).
    • Runtime eval integration -- Connect session metrics to the eval framework for measuring real-world skill effectiveness.

    Sources and Inspiration

    This plugin was built with insights from these articles, repositories, and tools:

    Repositories and Tools

    Articles

    License

    MIT