# DB Schema Review

> Database schema and migration review rubric covering ORM conventions, migration safety, indexes, relations, and exported types.

- Skill: `garyld1962/db-schema-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add garyld1962/db-schema-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/garyld1962/db-schema-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: garyld1962 (https://skillmd.com/u/garyld1962)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/garyld1962/db-schema-review

---


# Database Schema Review

Use this skill for migrations, ORM schemas, SQL files, and database model
definitions.

## Review focus

- detect the ORM or schema style first
- match the project's naming, ID, and timestamp conventions
- flag unsafe migrations such as destructive changes or not-null additions that
  ignore existing rows
- check foreign key indexes and multi-table transaction safety
- verify explicit relation behavior and type export boundaries
- avoid reserved words or ad-hoc naming that breaks project conventions

## High-signal checks

- raw SQL should be parameterized
- foreign keys should usually be indexed
- new tables should follow the project's timestamp convention
- irreversible drops deserve explicit attention

## Examples

- **Migration safety review:** A migration adds a non-null column to an existing
  table. Check whether it backfills or supplies a safe default before flagging
  it as migration-risky.
- **Schema convention review:** A new table uses ad-hoc timestamp or ID fields.
  Compare it to the repo's existing schema conventions before deciding whether
  the shape is actually inconsistent.

## Guardrails

- Read existing schema files before reviewing.
- Match the repo's ORM conventions, not a generic favorite ORM.

## Do Nots

- Do not recommend ORM patterns from a different stack than the one the repo
  uses.
- Do not call a destructive migration safe just because it passes syntax
  validation.
- Do not ignore existing-row impact when reviewing new required columns or data
  transformations.

## Closed Decisions

- Existing ORM, schema, naming, ID, and timestamp conventions are authoritative.
- Migration safety matters more than stylistic database preferences.
- Raw SQL must be parameterized.
- Irreversible or destructive changes require explicit scrutiny.

