메뉴
Ecto best practices covering preloading, schema types, changeset validation, field access, security, and migration conventions. Use when working with Ecto schemas, changesets, queries, or migrations.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | ecto-guidelines |
| description | Ecto best practices covering preloading, schema types, changeset validation, field access, security, and migration conventions. Use when working with Ecto schemas, changesets, queries, or migrations. |
# If the template needs message.user.email
messages = Repo.all(from m in Message, preload: [:user])
import Ecto.Query and other supporting modules when you write seeds.exsEcto.Schema fields always use the :string type, even for :text columns:field :name, :string
field :description, :string # Even if the DB column is :text
Ecto.Changeset.validate_number/2 DOES NOT SUPPORT the :allow_nil option. By default, Ecto validations only run if a change for the given field exists and the change value is not nil, so such an option is never neededEcto.Changeset.get_field(changeset, :field) to access changeset fieldschangeset[:field]) on changesetsuser_id, must not be listed in cast calls or similar for security purposes. Instead they must be explicitly set when creating the struct:# GOOD: Set user_id explicitly, not through cast
%Message{}
|> Message.changeset(params) # cast only includes :content, :subject, etc.
|> Ecto.Changeset.put_assoc(:user, user)
mix ecto.gen.migration migration_name_using_underscores when generating migration files, so the correct timestamp and conventions are appliedCore Elixir language guidelines covering common pitfalls like list access, immutability, module organization, struct access, date/time handling, and OTP patterns. Use when writing or reviewing Elixir code.
Best practices for testing Elixir applications with Ecto.SQL.Sandbox, including background process handling, Oban testing, and test output quality. Use when writing or reviewing Elixir tests.
Phoenix HEEx template rules covering interpolation syntax, form building, class lists, conditional rendering, comments, and common anti-patterns. Use when writing or reviewing HEEx templates.
Phoenix LiveView patterns covering streams, JavaScript interop (hooks, colocated scripts, push events), testing, and form handling. Use when building or reviewing LiveView features.
Phoenix 1.8 framework conventions covering layouts, routing, components, icons, forms, HTTP clients, and design file handling. Use when building or reviewing Phoenix web applications.
Tailwind CSS v4 configuration and usage guidelines for Phoenix projects, plus UI/UX design principles. Use when styling Phoenix applications or building user interfaces.