What problem does it solve? Making database schema changes in a CoreEx project involves choosing the right DbEx migration script type, writing provider-correct SQL, registering tables in dbex.yaml, and regenerating EF persistence models — a multi-step process where mistakes (editing applied scripts, hand-editing generated files, wrong column types) break the migration pipeline. ## Core Features & Use Cases - Guided script selection: Branches across five paths — new transactional table, new reference-data table, alter existing table, non-entity schema change, or no-op — gated by a mandatory dotnet run -- inspect baseline check. - Polyglot SQL templates: Provides canonical column templates and .NET-to-SQL type mappings for both SQL Server (PascalCase, .sql) and PostgreSQL (snake_case, .pgsql), including JSON columns, audit columns, and logical delete. - End-to-end regeneration: Applies migrations via dotnet run -- All and validates the regenerated *.g.cs persistence models and DbContext, with strict guardrails against editing generated files or applied scripts. - Use Case: A developer adding a new Product table with a JSON Tags column runs the skill to scaffold the create script, configure the columns: entry in dbex.yaml, apply the migration, and confirm the typed property and JSON converter appear in the generated code. ## Quick Start Ask the AI to add a new database table or alter an existing one for your CoreEx domain, specifying the entity name, schema, and whether you use SQL Server or PostgreSQL.