Phoenix

What Changed

Released v1.4.0 of my Elixir Phoenix Guide plugin. Two new skills, three new hooks, and a fix for something that’s been bugging me: subagents ignoring the rules.

The Problem with v1.3.x

The plugin had five skills covering Elixir core, LiveView, Ecto, uploads, and testing. That’s solid for web layer code. But two big gaps remained.

No OTP guidance. GenServer, Supervisor, Task, Agent, ETS. These are core to any real Elixir application, and the plugin had nothing to say about them. Claude Code would write GenServers with blocking handle_call callbacks, skip supervision trees, or reach for Agent when a simple GenServer would do.

What Changed

Released v1.3.0 of my Elixir Phoenix Guide plugin. This one is all about testing.

v1.2.0 built out four skills that cover Elixir patterns, LiveView, Ecto, and file uploads. What I didn’t have was anything for tests. You could open a _test.exs file and the plugin had nothing to say. That felt like a hole worth fixing.

The Problem with v1.2.0

The four skills worked well for production code but testing was just not covered. Claude Code would write a context module following strict patterns, then write the tests with no real guidance. The result was inconsistent test setup, missing edge cases, and assertion styles that made failures hard to read.

What Changed

Released v1.2.0 of my Elixir Phoenix Guide plugin. This is a major restructuring: eight separate skills consolidated into four essential modules, each with enforced rules and real-time validation.

This isn’t a minor update. It’s a complete rethinking of how Claude Code should guide Elixir/Phoenix development.

The Problem with v1.1.x

In v1.1.x, I had eight skills covering different aspects of Elixir and Phoenix development. The structure worked, but created problems:

The Experiment

I’ve been using Claude Code for Elixir development and wondered: Does customizing the AI with skills, hooks, and agent documentation actually make a difference?

To find out, I built the same Phoenix LiveView image gallery application twice:

• Build 1 (Baseline): Minimal configuration - just project guidelines and specs
• Build 2 (Plugin): Custom skills, hooks, agent docs, and comprehensive project documentation

Both builds used identical project specifications and the same base agent guidelines. The only difference was the additional plugin configuration in Build 2.

The Stack

Here’s what I’m actually using day-to-day for Elixir/Phoenix LiveView development. Not what I tried once and forgot about.

Code Editing: Windsurf

What I use it for:

• Primary IDE for Elixir/Phoenix development
• In-editor AI assistance without context switching
• Refactoring suggestions that understand Phoenix patterns

Why it stuck: Feels native. The AI suggestions understand Elixir idioms and Phoenix conventions. When I’m working on a LiveView component, it actually suggests LiveView-appropriate patterns, not React patterns.

What is Tidewave?

Tidewave is an AI coding assisstant meant for full stack web development. It is built on top of Elixir and Phoenix by José Valim. What I found different about Tidewave is that it runs insdie of your browser. It is deeply integrated with your web frameworkand easily allows you to see what the coding agent is doing in real time.

Getting Started with Tidewave

Prerequisites

Before we begin, make sure you have: