efcore-migrations
Automates the EF Core migration workflow while ensuring best practices.
Install
mkdir -p .claude/skills/efcore-migrations && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15867" && unzip -o skill.zip -d .claude/skills/efcore-migrations && rm skill.zipInstalls to .claude/skills/efcore-migrations
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
**WORKFLOW SKILL** — EF Core migrations workflow for backend model changes: generate, review, and apply EF Core migrations using the repository's README guidance. Agents MUST NOT hand-edit migration code — migrations must be generated with the `dotnet ef migrations add` tool.Key capabilities
- →Generate EF Core migrations
- →Apply EF Core migrations to a database
- →Review generated migration files
- →Build backend projects
- →Run unit tests
How it works
The skill uses `dotnet ef` commands to generate and apply migrations based on model changes, enforcing that migration code is tool-generated.
Inputs & outputs
When to use efcore-migrations
- →Generate new database migration
- →Apply migrations to database
- →Fix model schema drift
About this skill
EF Core Migrations Skill
Overview
A compact, reproducible workflow for creating and applying EF Core migrations after entity/model changes. This skill codifies repo-specific dotnet ef commands (from the repo README) and enforces the rule: do not hand-generate migration code — always use the EF tooling to produce migration files.
When to use
- After model/entity (domain) changes in
backend/Modelsor other persisted types. - When adding, renaming, or removing columns or relationships that require schema changes.
- When preparing data migrations or seed updates tied to a schema change.
Prerequisites
- Project builds: run
dotnet build backendand fix compile errors first. dotnet-eftooling available (global or local). If not available, prompt the user before attempting to install or run it.- Local dev DB or test DB available when you plan to run
dotnet ef database update.
Repository reference Follow the repository README's "Migrations" section for the canonical commands and locations: README.md. Example commands from the README:
# create migration
dotnet ef migrations add <Name> --project backend/DailyChallenges.csproj --startup-project backend/DailyChallenges.csproj
# apply migration
dotnet ef database update --project backend/DailyChallenges.csproj --startup-project backend/DailyChallenges.csproj
Always review generated migration files under backend/Migrations before committing or applying them.
Step-by-step Workflow (agent)
- Confirm intent
- Detect model/entity changes, or confirm the user-declared changes.
- Ask: migration name, target environment (dev/test/staging), and whether to run the DB update now.
- Build & tests
- Run
dotnet build backendanddotnet test(or ask permission before running tests).
- Run
- Generate migration (tooling-only)
- Run the
dotnet ef migrations add <DescriptiveName>command using the repository flags from the README (project/startup-project). - Do NOT hand-author migration files. If tooling cannot run, stop and ask the user for permission to install/run
dotnet-efor for instructions to proceed locally.
- Run the
- Review generated migration files
- Inspect
backend/Migrations/<timestamp>_<Name>.csand.Designer.csfor expected schema changes and any surprising operations (drops, data-loss operations). - If the migration includes risky operations (column drops, data-moving SQL), ask for a migration plan and confirm backups/test-run strategy.
- Inspect
- Apply to local/test DB (optional)
- If requested and safe, run
dotnet ef database updateagainst the dev/test DB and verify runtime behavior.
- If requested and safe, run
- Commit & document
- Add generated migration files to VCS, include a short commit message describing the model change and migration name.
- Update any seed data or documentation if needed.
- CI/Release considerations
- Ensure CI builds and tests run migrations as part of schema/setup steps or document required manual steps for deploy.
Decision Points
- Rolling schema changes vs. destructive changes: if data-loss operations are detected, require an explicit manual approval and a rollback plan.
- Feature-flagged data migrations: prefer background/controlled data migrations when converting large datasets.
- Tooling missing: do not generate placeholder migration files; ask the user to run the tooling locally or permit the agent to install/run
dotnet-ef.
Quality Criteria / Completion Checks
dotnet build backendsucceeds.- Migration files are created under
backend/Migrationsand reviewed. dotnet ef database update(when run) applies without unexpected errors in the dev/test DB.- Unit and integration tests that depend on the schema pass locally/CI.
- Commit contains only the generated migration files and related code (no handcrafted migration content).
Quick commands (repo-specific)
-
Create migration:
dotnet ef migrations add <Name> --project backend/DailyChallenges.csproj --startup-project backend/DailyChallenges.csproj
-
Apply migration:
dotnet ef database update --project backend/DailyChallenges.csproj --startup-project backend/DailyChallenges.csproj
-
Build:
dotnet build backend -
Test:
dotnet test backend
Example prompts (use with this skill)
- "I've added
IsFeaturedtoGame. Create an EF Core migration namedAddIsFeaturedToGamesusing the README commands, run it against my dev DB, and commit the generated migration files." - "Model updated: renamed
Score->PointsonSubmission. Generate the migration but do NOT apply it—I'll review before apply." - "I can't run dotnet-ef here; show exact commands and steps I should run locally to create and apply the migration."
Clarifying Questions (ask before acting)
- May I run
dotnet efin this workspace? (requires SDK and dotnet-ef) - Which environment should I target when running
database update? (dev/tests/staging/none) - Is this change allowed to be destructive (drops/renames that may lose data)? If so, provide the rollback plan.
What this skill produces
- A validated migration workflow and the generated migration files created by
dotnet ef migrations add(never hand-crafted migration code). - Clear review guidance and VCS commit instructions.
Suggested next customizations
- Add a prompt template
create-migration.prompt.mdthat runs thedotnet efcommand when the user grants permission. - Add an agent persona note (e.g., in
senior-csharp-backend.agent.md) to prefer this skill for DB/schema tasks.
When you want me to create migrations automatically, confirm I may run dotnet ef in the workspace and whether to apply the migration to the dev/test DB immediately. If dotnet-ef is unavailable, I will stop and provide exact commands for you to run locally.
When not to use it
- →When hand-editing migration code
- →When project does not build
- →When `dotnet-ef` tooling is unavailable without user permission
Prerequisites
Limitations
- →Migrations must be generated with the `dotnet ef migrations add` tool
- →Requires review of generated migration files
- →Requires explicit confirmation for destructive operations
How it compares
This skill enforces a specific repository workflow for EF Core migrations, requiring tool-generated code and review, unlike manual migration creation.
Compared to similar skills
efcore-migrations side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| efcore-migrations (this skill) | 0 | 4mo | No flags | Intermediate |
| azure-resource-manager-postgresql-dotnet | 1 | 3mo | Review | Intermediate |
| azure-resource-manager-sql-dotnet | 1 | 3mo | Review | Intermediate |
| appsettings | 0 | 4mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
azure-resource-manager-postgresql-dotnet
microsoft
Azure PostgreSQL Flexible Server SDK for .NET. Database management for PostgreSQL Flexible Server deployments. Use for creating servers, databases, firewall rules, configurations, backups, and high availability. Triggers: "PostgreSQL", "PostgreSqlFlexibleServer", "PostgreSQL Flexible Server", "Azure Database for PostgreSQL", "PostgreSQL database management", "PostgreSQL firewall", "PostgreSQL backup", "Postgres".
azure-resource-manager-sql-dotnet
microsoft
Azure Resource Manager SDK for Azure SQL in .NET. Use for MANAGEMENT PLANE operations: creating/managing SQL servers, databases, elastic pools, firewall rules, and failover groups via Azure Resource Manager. NOT for data plane operations (executing queries) - use Microsoft.Data.SqlClient for that. Triggers: "SQL server", "create SQL database", "manage SQL resources", "ARM SQL", "SqlServerResource", "provision Azure SQL", "elastic pool", "firewall rule".
appsettings
punk-link
Rules for modifying ASP.NET Core configuration files (appsettings*.json) in the Warp project. Use when: adding, removing, or changing any configuration key in appsettings files; creating new Options classes that bind to configuration; the user mentions 'appsettings', 'configuration', 'options', 'con
dotnet-backend-patterns
wshobson
Master C#/.NET backend development patterns for building robust APIs, MCP servers, and enterprise applications. Covers async/await, dependency injection, Entity Framework Core, Dapper, configuration, caching, and testing with xUnit. Use when developing .NET backends, reviewing C# code, or designing API architectures.
dotnet-backend-patterns
brunolimaff-jpg
Master C#/.NET backend development patterns for building robust APIs, MCP servers, and enterprise applications. Covers async/await, dependency injection, Entity Framework Core, Dapper, configuratio...
efcore-patterns
pdldynamicsltd
Entity Framework Core patterns for ASP.NET Zero (DbContext, repositories, migrations)