database-schema-reviewlisted

Runs a structured review of a project's database schema design and migration safety, then reports the results as one table (check, area, status, evidence, recommendation). Covers normalization and data modeling (under-normalized vs. unjustified over-normalization, schema matching actual business entities), data types and constraints (appropriate column types, NOT NULL usage, CHECK constraints/enums for fixed value sets), referential integrity (foreign keys declared at the DB level, ON DELETE/ON UPDATE cascade behavior, orphan-record risk), uniqueness and identity (unique constraints vs. check-then-insert races, primary key/surrogate-key/UUID choice), migration safety (backward-compatible rolling deploys, expand/contract pattern, reversibility, DDL transactions, lock/downtime impact of large-table migrations), schema-vs-application drift, auditability/soft-delete conventions, and multi-tenancy data isolation at the schema level. This is a schema-design and migration-safety review, not a query-performance-tunin
finnley07/AI-SKILLHUB · ★ 0 · API & Backend · score 72

Install: claude install-skill finnley07/AI-SKILLHUB

# Database Schema & Migration Safety Review A structured, evidence-based review of a project's database schema design and migration history — not a query-performance tuning pass and not an application-security review. It investigates the actual migration files/schema definitions and reports one table the user can act on. Out of scope, by design: - **Query performance tuning.** Deciding whether a specific slow query needs an index, and detecting N+1 query patterns, is `performance-audit`'s job (see its `references/backend-performance.md`, checks B3–B4). This skill only cares about indexing that exists *for data-integrity reasons* — e.g. a unique constraint that happens to be backed by an index — not indexing chosen purely to speed up a particular read. - **Application security.** SQL/NoSQL injection and other application-security concerns are `cybersecurity-check`'s job (see its `references/security.md`, check S1). This skill only checks whether integrity rules (uniqueness, required fields, valid value sets, relationships) are enforced at the database level — not whether the application safely constructs queries. A finding belongs here only if its primary concern is schema design correctness or migration safety, not raw query speed or injection risk. ## Ground rules - **Evidence or it didn't happen.** Every row needs a concrete pointer — a specific migration file and its actual `CREATE TABLE`/`ALTER TABLE` statement, an ORM model's actual column/attribute