VerticalSlices: Skill for Claude Code

Add or update an Entity Framework Core schema change with a hand-written migration.

Always read the efcore.md rule first. It is the source of truth for project structure, base types, column helpers, and migration conventions.

Pre-flight — Understand the project split

Before writing anything, locate these three projects:

Project	What lives there
Database	Migrations only — WellKnownTables.cs + versioned migration files
Core	Entities and feature DbContexts (co-located with features)
Infrastructure	DbContext registration, migration runner, cross-cutting EF setup

Critical: Database must NEVER import from Core. Migrations reference only WellKnownTables constants and EF migration types.

Step 1 — Update or create the entity

Add, rename, or remove properties on the entity record in the Core project, co-located with its feature:

Missions/StartupPhase/
├── StartupPhase.cs            ← entity record
├── StartupPhaseDbContext.cs   ← feature DbContext
└── ...

Step 2 — Update or create the feature DbContext

Use the Cratis Arc base types — never inherit directly from DbContext:

• ReadOnlyDbContext — for all read model / projection contexts (the vast majority)
• BaseDbContext — only for writable contexts that own state

public class StartupPhaseDbContext(DbContextOptions<StartupPhaseDbContext> options)
    : ReadOnlyDbContext(options)
{
    public DbSet<StartupPhase> StartupPhases => Set<StartupPhase>();
}

Create one focused DbContext per feature — never a "god context" with unrelated entities.

Step 3 — Add the table name to WellKnownTables

If this is a new table, add the constant to Database/WellKnownTables.cs before writing the migration:

public static class WellKnownTables
{
    public const string StartupPhases = "StartupPhases";
}

Step 4 — Write the migration by hand

Migrations are hand-written, not generated by dotnet ef migrations add. Place the file in the Database project using versioned naming: