# Ef Core Safety

> Design, implement, or review Entity Framework Core queries, writes, migrations, and DbContext usage. Use only when a .NET task changes EF Core persistence behavior or investigates database performance/correctness.

- Skill: `dprakash2101/ef-core-safety` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dprakash2101/ef-core-safety`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dprakash2101/ef-core-safety/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: dprakash2101 (https://skillmd.com/u/dprakash2101)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/dprakash2101/ef-core-safety

---


# EF Core safety

Understand the entity model, mappings, query shape, indexes, tracking needs, transaction boundary, concurrency behavior, and migration history before editing.

- Keep `DbContext` scoped to a unit of work and never use one instance concurrently. Await each operation before starting the next.
- Project only needed data; avoid accidental N+1 queries, client evaluation assumptions, unbounded result sets, premature materialization, and unnecessary tracking (`AsNoTracking` for read-only work when consistent with the repository).
- Propagate cancellation to async database calls. Use async methods for request-path I/O.
- Make transaction boundaries explicit when multiple writes must be atomic. Account for execution-strategy retries and external side effects; do not assume a database transaction covers remote calls.
- Handle optimistic concurrency deliberately when lost updates matter. Design retry/merge behavior rather than blindly overwriting.
- Treat migrations as production contracts: inspect generated operations, data loss, locks, defaults/backfills, deployment ordering, mixed-version compatibility, and rollback/roll-forward strategy.

Do not introduce a custom retry loop merely because a database failure might be transient. Add retry behavior only when explicitly requested or already required/configured by the architecture, prefer the provider's EF Core execution strategy, and verify idempotency, transaction boundaries, duplicate-write safety, timeout budget, bounded attempts, cancellation, and permanent-error classification.

Validate query behavior and SQL/performance when risk warrants it. Test provider-specific behavior with the appropriate provider; do not assume an in-memory provider reproduces relational semantics.