Phoenix Development
When to Use
- •Writing new Phoenix features (contexts, controllers, LiveView, components).
- •Adding or changing Ecto schemas, changesets, or context functions.
- •Adding routes, pipelines, or plugs.
- •Designing or evolving public APIs (context functions, assigns, options).
Principles
- •Context boundaries: Business logic in
lib/my_app/(contexts); web layer inlib/my_app_web/thin and delegating to contexts. Controllers and LiveViews call context functions and handle HTTP/LiveView concerns only. - •Idioms: Prefer pipe
|>, pattern matching, andwithfor multi-step flows. Return{:ok, result}/{:error, reason}from context functions; useraiseonly for exceptional cases. - •Style: Follow the project's Phoenix and Elixir rules (CLAUDE.md or
.cursor/rules/). Use snake_case for functions and variables; PascalCase for modules. Follow phoenix-style, ecto-style, and liveview-style as applicable. - •Ecto: Use schemas and changesets for data; keep queries in context or dedicated query modules. Do not edit migrations after they have been run in production.
- •LiveView: Keep state in assigns; delegate logic to context; use
send(self(), ...)andhandle_infofor async work.
Verification
- •
mix compileandmix test. - •
mix credowhen available (fix or allow with justification). - •
mix format(or rely on the format hook).