Use when writing or reviewing MSSQL/T-SQL, creating stored procedures, designing table schemas, writing views, building migrations, defining custom types, or architecting a SQL Server application database. Also use when writing RAISERROR patterns, CHECK constraints with scalar functions, base/subtype table hierarchies, composite key designs, role-scoped views with row-level security, or idempotent DDL scripts. If you are touching MSSQL for an application database, use this skill. Not for PostgreSQL, MySQL, Oracle, or SQLite — patterns are SQL Server-specific.
95
94%
Does it follow best practices?
Impact
98%
1.81xAverage score across 5 eval scenarios
Passed
No known issues
An e-commerce company's SQL Server database has been running in production for two years and needs several schema changes as part of a new feature release. The engineering team deploys schema migrations by running SQL scripts directly against production — and occasionally against staging environments that may have already received an earlier version of the same migration. A script that crashes on re-run (because the column already exists, or the constraint is already there) causes downtime incidents.
The team needs a migration script that can be safely run multiple times: if the changes are already applied, running the script again must be a no-op. If they're not applied, the script applies them correctly. The deployment pipeline cannot guarantee a script runs exactly once.
The required schema changes are:
IsVerified boolean column to the Customer table (default false)DiscountPct decimal column to the Product table (allow NULL — some products have no discount)OrderTag child table that links tags to orders — composite key of CustomerNo + OrderNo + TagNo, with a foreign key to the Order tableCustomer.EmailOrder.CreatedAtTagLabel (VARCHAR-based) if it doesn't already existThe existing schema uses a custom type system (custom types like _Bool, _Money, CustomerNo, OrderNo, TagNo already exist). You can assume the meta-infrastructure functions may or may not exist yet and should be created as part of this migration if needed.
Produce two files:
meta_functions.sql — helper functions for checking whether database objects already exist, so the migration script can use themmigration.sql — the migration script itself that applies each of the 6 changes safely regardless of whether they have already been appliedBoth files should be self-contained SQL. The migration.sql should include at the top: -- Run this script on any environment, any number of times. It is idempotent.