home / skills / 404kidwiz / claude-supercode-skills / elixir-expert-skill

elixir-expert-skill skill

/elixir-expert-skill

This skill helps you build fault-tolerant Elixir and Phoenix applications with GenServer, Supervisors, LiveView, and BEAM patterns.

npx playbooks add skill 404kidwiz/claude-supercode-skills --skill elixir-expert-skill

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.2 KB
---
name: elixir-expert
description: Expert in Elixir, Phoenix Framework, and OTP. Specializes in building concurrent, fault-tolerant, and real-time applications using the BEAM. Use when building Elixir applications, working with Phoenix, implementing GenServers, or designing distributed systems on the BEAM.
---

# Elixir Expert

## Purpose
Provides expertise in Elixir development, Phoenix Framework, and OTP patterns. Covers concurrent programming, real-time features with LiveView, and building fault-tolerant distributed systems on the BEAM VM.

## When to Use
- Building Elixir applications
- Developing Phoenix web applications
- Implementing real-time features with LiveView
- Using OTP patterns (GenServer, Supervisor)
- Building distributed systems on BEAM
- Designing fault-tolerant architectures
- Working with Ecto for database access

## Quick Start
**Invoke this skill when:**
- Building Elixir applications
- Developing Phoenix web applications
- Implementing real-time features with LiveView
- Using OTP patterns
- Designing fault-tolerant systems

**Do NOT invoke when:**
- Building Ruby on Rails apps (use rails-expert)
- Building Node.js backends (use javascript-pro)
- Building Python backends (use python-pro)
- Infrastructure automation (use terraform-engineer)

## Decision Framework
```
Concurrency Pattern:
├── Stateful process → GenServer
├── Async work → Task
├── Background job → Oban or Task.Supervisor
├── Event streaming → GenStage / Broadway
├── Real-time UI → Phoenix LiveView
└── External service → Retry with exponential backoff

Supervision Strategy:
├── Process can crash independently → one_for_one
├── Processes depend on each other → one_for_all
├── Ordered restart needed → rest_for_one
└── Dynamic children → DynamicSupervisor
```

## Core Workflows

### 1. Phoenix Application Setup
1. Generate Phoenix project
2. Configure database with Ecto
3. Define schemas and migrations
4. Create contexts for business logic
5. Build controllers or LiveViews
6. Add authentication
7. Deploy with releases

### 2. OTP Application Design
1. Identify stateful components
2. Design supervision tree
3. Implement GenServers for state
4. Add proper error handling
5. Implement graceful shutdown
6. Test supervision strategies

### 3. Real-Time with LiveView
1. Generate LiveView module
2. Define assigns and state
3. Implement handle_event callbacks
4. Use pubsub for broadcasts
5. Optimize with temporary_assigns
6. Add JS hooks if needed

## Best Practices
- Let it crash - design for failure recovery
- Use supervision trees for fault tolerance
- Keep GenServer state minimal
- Use contexts to organize business logic
- Prefer immutable data transformations
- Test concurrent code with async: true

## Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|--------------|---------|------------------|
| Large GenServer state | Memory and serialization | External storage, ETS |
| Defensive coding | Hides bugs | Let it crash, supervise |
| Blocking GenServer | Process bottleneck | Async tasks for I/O |
| No supervision | Unrecoverable crashes | Proper supervision tree |
| Mutable mindset | Bugs and race conditions | Embrace immutability |

Overview

This skill is an Elixir, Phoenix, and OTP expert focused on building concurrent, fault-tolerant, and real-time applications on the BEAM. It helps design supervision trees, implement GenServers, and add LiveView-based real-time UI. Use it to align architecture and code with BEAM best practices for reliability and scalability.

How this skill works

I inspect your application requirements and recommend concrete Elixir/OTP patterns: which processes should be stateful, where to place GenServers, how to structure supervisors, and when to offload work to Tasks or background job systems. I provide step-by-step guidance for Phoenix setup, LiveView integration, Ecto schemas/migrations, and release/deployment patterns. I also surface anti-patterns and offer corrective refactors to improve concurrency, fault tolerance, and performance.

When to use it

  • Building a new Elixir or Phoenix application
  • Designing OTP supervision trees and GenServer-based state
  • Implementing real-time UI with Phoenix LiveView
  • Adding fault tolerance and crash recovery strategies
  • Architecting distributed systems on the BEAM
  • Integrating Ecto, background jobs, or event streaming (GenStage/Broadway)

Best practices

  • Design for failure: let processes crash and recover under supervisors
  • Keep GenServer state minimal; persist large or shared data to ETS or external stores
  • Use contexts to organize business logic and keep controllers thin
  • Offload blocking or I/O work to Task, Task.Supervisor, or background job systems
  • Choose supervision strategies (one_for_one, one_for_all, rest_for_one, DynamicSupervisor) based on failure domains

Example use cases

  • Create a Phoenix app with LiveView dashboards for real-time metrics
  • Design a supervision tree for a chat system using PubSub and GenServers
  • Migrate a blocking worker into async Tasks or Oban jobs to avoid GenServer bottlenecks
  • Build a distributed event pipeline with GenStage or Broadway
  • Implement graceful shutdown and restart strategies for stateful services

FAQ

When should I use a GenServer vs Task?

Use GenServer for long-lived stateful processes that maintain state and handle recurring messages. Use Task for short-lived, stateless asynchronous work or fire-and-forget jobs.

How do I choose a supervisor strategy?

Pick one_for_one when children can fail independently. Use one_for_all when children are interdependent and must be restarted together. Use rest_for_one for ordered restarts and DynamicSupervisor for dynamic child lifecycles.