/ecto-thinking
This skill should be used when the user asks to "add a database table", "create a new context", "query the database", "add a field to a schema", "validate form input", "fix N+1 queries", "preload this association", "separate these concerns", or mentions Repo, changesets,
$ npx -y skills add georgeguimaraes/claude-code-elixir --skill ecto-thinking --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ecto-thinking
Context preview
The summary Claude sees to decide when to auto-load this skill.
This skill should be used when the user asks to "add a database table", "create a new context", "query the database", "add a field to a schema", "validate form input", "fix N+1 queries", "preload this association", "separate these concerns", or mentions Repo, changesets,
SKILL.md
ecto-thinking.SKILL.mdname: ecto-thinking
description: This skill should be used when the user asks to "add a database table", "create a new context", "query the database", "add a field to a schema", "validate form input", "fix N+1 queries", "preload this association", "separate these concerns", or mentions Repo, changesets, migrations, Ecto.Multi, has_many, belongs_to, transactions, query composition, or how contexts should talk to each other.
Ecto Thinking
Mental shifts for Ecto and data layer design. These insights challenge typical ORM patterns.
Context = Setting That Changes Meaning
Context isn't just a namespace—it changes what words mean. "Product" means different things in Checkout (SKU, name), Billing (SKU, cost), and Fulfillment (SKU, warehouse). Each bounded context may have its OWN Product schema/table.
**Think top-down:** Subdomain → Context → Entity. Not "What context does Product belong to?" but "What is a Product in this business domain?"
Cross-Context References: IDs, Not Associations
schema "cart_items" do
field :product_id, :integer # Reference by ID
# NOT: belongs_to :product, Catalog.Product
end
Query through the context, not across associations. Keeps contexts independent and testable.
DDD Patterns as Pipelines
def create_product(params) do
params
|> Products.build() # Factory: unstructured → domain
|> Products.validate() # Aggregate: enforce invariants
|> Products.insert() # Repository: persist
end
Use events (as data structs) to compose bounded contexts with minimal coupling.
Schema ≠ Database Table
| Use Case | Approach | |----------|----------| | Database table | Standard `schema/2` | | Form validation only | `embedded_schema/1` | | API request/response | Embedded schema or schemaless |
Multiple Changesets per Schema
def registration_changeset(user, attrs) # Full validation + password
def profile_changeset(user, attrs) # Name, bio only
def admin_changeset(user, attrs) # Role, verified_at
Different operations = different changesets.
Multi-Tenancy: Composite Foreign Keys
add :post_id, references(:posts, with: [org_id: :org_id], match: :full)
Use `prepare_query/3` for automatic scoping. Raise if `org_id` missing.
Preload vs Join Trade-offs
| Approach | Best For | |----------|----------| | Separate preloads | Has-many with many records (less memory) | | Join preloads | Belongs-to, has-one (single query) |
Join preloads can use 10x more memory for has-many.
CRUD Contexts Are Fine
> "If you have a CRUD bounded context, go for it. No need to add complexity."
Use generators for simple cases. Add DDD patterns only when business logic demands it.
Gotchas from Core Team
CTE Queries Don't Inherit Schema Prefix
In multi-tenant apps, CTEs don't get the parent query's prefix.
**Fix:** Explicitly set prefix: `%{recursive_query | prefix: "tenant"}`
Parameterized Queries ≠ Prepared Statements
- **Parameterized queries:** `WHERE id = $1` — always used by Ecto
- **Prepared statements:** Query plan cached by name — can be disabled
**pgbouncer:** Use `prepare: :unnamed` (disables prepared statements, keeps parameterized queries).
pool_count vs pool_size
More pools with fewer connections = better for benchmarks. **But** with mixed fast/slow queries, a single larger pool gives better latency.
**Rule:** `pool_count` for uniform workloads, larger `pool_size` for real apps.
Sandbox Mode Doesn't Work With External Processes
Cachex, separate GenServers, or anything outside the test process won't share the sandbox transaction.
**Fix:** Make the external service use the test process, or accept it's not in the same transaction.
Null Bytes Crash Postgres
PostgreSQL rejects null bytes even though they're valid UTF-8.
**Fix:** Sanitize at boundaries: `String.replace(string, "\x00", "")`
preload_order for Association Sorting
has_many :comments, Comment, preload_order: [desc: :inserted_at]
Note: Doesn't work for `through` associations.
Runtime Migrations Use List API
Ecto.Migrator.run(Repo, [{0, Migration1}, {1, Migration2}], :up, opts)Idioms
- Prefer `Repo.insert/1` over `Repo.insert!/1`—handle `{:ok, _}` / `{:error, _}` explicitly
- Use `Repo.transact/1` (Ecto 3.12+) for simple transactions instead of `Ecto.Multi`
Red Flags - STOP and Reconsider
- belongs_to pointing to another context's schema
- Single changeset for all operations
- Preloading has-many with join
- CTEs in multi-tenant apps without explicit prefix
- Using pgbouncer without `prepare: :unnamed`
- Testing with Cachex/GenServers assuming sandbox shares transactions
- Accepting user input without null byte sanitization
**Any of these? Re-read the Gotchas section.**
Read more
name: ecto-thinking description: This skill should be used when the user asks to "add a database table", "create a new context", "query the database", "add a field to a schema", "validate form input", "fix N+1 queries", "preload this association", "separate these concerns", or mentions Repo, changesets, migrations, Ecto.Multi, has_many, belongs_to, transactions, query composition, or how contexts should talk to each other.
Ecto Thinking
Mental shifts for Ecto and data layer design. These insights challenge typical ORM patterns.
Context = Setting That Changes Meaning
Context isn't just a namespace—it changes what words mean. "Product" means different things in Checkout (SKU, name), Billing (SKU, cost), and Fulfillment (SKU, warehouse). Each bounded context may have its OWN Product schema/table.
**Think top-down:** Subdomain → Context → Entity. Not "What context does Product belong to?" but "What is a Product in this business domain?"
Cross-Context References: IDs, Not Associations
schema "cart_items" do field :product_id, :integer # Reference by ID # NOT: belongs_to :product, Catalog.Product end
Query through the context, not across associations. Keeps contexts independent and testable.
DDD Patterns as Pipelines
def create_product(params) do params |> Products.build() # Factory: unstructured → domain |> Products.validate() # Aggregate: enforce invariants |> Products.insert() # Repository: persist end
Use events (as data structs) to compose bounded contexts with minimal coupling.
Schema ≠ Database Table
| Use Case | Approach | |----------|----------| | Database table | Standard `schema/2` | | Form validation only | `embedded_schema/1` | | API request/response | Embedded schema or schemaless |
Multiple Changesets per Schema
def registration_changeset(user, attrs) # Full validation + password def profile_changeset(user, attrs) # Name, bio only def admin_changeset(user, attrs) # Role, verified_at
Different operations = different changesets.
Multi-Tenancy: Composite Foreign Keys
add :post_id, references(:posts, with: [org_id: :org_id], match: :full)
Use `prepare_query/3` for automatic scoping. Raise if `org_id` missing.
Preload vs Join Trade-offs
| Approach | Best For | |----------|----------| | Separate preloads | Has-many with many records (less memory) | | Join preloads | Belongs-to, has-one (single query) |
Join preloads can use 10x more memory for has-many.
CRUD Contexts Are Fine
> "If you have a CRUD bounded context, go for it. No need to add complexity."
Use generators for simple cases. Add DDD patterns only when business logic demands it.
Gotchas from Core Team
CTE Queries Don't Inherit Schema Prefix
In multi-tenant apps, CTEs don't get the parent query's prefix.
**Fix:** Explicitly set prefix: `%{recursive_query | prefix: "tenant"}`
Parameterized Queries ≠ Prepared Statements
- **Parameterized queries:** `WHERE id = $1` — always used by Ecto
- **Prepared statements:** Query plan cached by name — can be disabled
**pgbouncer:** Use `prepare: :unnamed` (disables prepared statements, keeps parameterized queries).
pool_count vs pool_size
More pools with fewer connections = better for benchmarks. **But** with mixed fast/slow queries, a single larger pool gives better latency.
**Rule:** `pool_count` for uniform workloads, larger `pool_size` for real apps.
Sandbox Mode Doesn't Work With External Processes
Cachex, separate GenServers, or anything outside the test process won't share the sandbox transaction.
**Fix:** Make the external service use the test process, or accept it's not in the same transaction.
Null Bytes Crash Postgres
PostgreSQL rejects null bytes even though they're valid UTF-8.
**Fix:** Sanitize at boundaries: `String.replace(string, "\x00", "")`
preload_order for Association Sorting
has_many :comments, Comment, preload_order: [desc: :inserted_at]
Note: Doesn't work for `through` associations.
Runtime Migrations Use List API
Ecto.Migrator.run(Repo, [{0, Migration1}, {1, Migration2}], :up, opts)Idioms
- Prefer `Repo.insert/1` over `Repo.insert!/1`—handle `{:ok, _}` / `{:error, _}` explicitly
- Use `Repo.transact/1` (Ecto 3.12+) for simple transactions instead of `Ecto.Multi`
Red Flags - STOP and Reconsider
- belongs_to pointing to another context's schema
- Single changeset for all operations
- Preloading has-many with join
- CTEs in multi-tenant apps without explicit prefix
- Using pgbouncer without `prepare: :unnamed`
- Testing with Cachex/GenServers assuming sandbox shares transactions
- Accepting user input without null byte sanitization
**Any of these? Re-read the Gotchas section.**
Other skills on claude-code-elixir.
- /elixir-thinking
This skill should be used when the user asks to "implement a feature in Elixir", "refactor this module", "should I use a GenServer here?", "how should I structure this?", "use the pipe operator", "add error handling", "make this concurrent", or mentions protocols, behaviours,
Open skill - /oban-thinking
This skill should be used when the user asks to "add a background job", "process async", "schedule a task", "retry failed jobs", "add email sending", "run this later", "add a cron job", "unique jobs", "batch process", or mentions Oban, Oban Pro, workflows, job queues, cascades,
Open skill - /otp-thinking
This skill should be used when the user asks to "add background processing", "cache this data", "run this async", "handle concurrent requests", "manage state across requests", "process jobs from a queue", "this GenServer is slow", or mentions GenServer, Supervisor, Agent, Task,
Open skill - /phoenix-thinking
This skill should be used when the user asks to "add a LiveView page", "create a form", "handle real-time updates", "broadcast changes to users", "add a new route", "create an API endpoint", "fix this LiveView bug", "why is mount called twice?", or mentions handle_event,
Open skill - /using-elixir-skills
This skill should be used when the user works on any .ex or .exs file, mentions Elixir/Phoenix/Ecto/OTP, the project has a mix.exs, or asks "which skill should I use", "new to Elixir", "help with Elixir". Routes to the correct thinking skill BEFORE exploring code. Triggers on
Open skill

