Conciseness

Every section adds repo-specific knowledge Claude cannot already have — the blue/green cutover window, the `COMMIT;` breakpoint idiom, the marker format — with zero tutorial padding. The one recap (marker rules in Workflow step 1) is a one-line cross-reference ("see 'Tracking the contract'") that earns its place. Not 4: there is no over-explanation to trim; the 8-row playbook table is the most token-dense form the content could take.

Actionability

Fully executable throughout: `cd packages/db && bunx drizzle-kit generate`, `bun run check:migrations`, `grep -rn "contract-pending" packages/db apps/sim`, `CREATE INDEX CONCURRENTLY IF NOT EXISTS`, `ADD CONSTRAINT ... NOT VALID`, and two copy-paste-ready annotation examples with an exact format spec (`contract-pending(<precondition>): <what to drop> — <why>`). Not 4: no gaps — common cases (add, rename, drop, type change, FK, index, backfill) each get concrete SQL-level direction.

Workflow Clarity

The 4-step Workflow is clearly sequenced with the lint as an explicit validation checkpoint, tiered failure handling (hard errors → rewrite into expand/contract; annotate tier → only after confirming steps 1–3; warnings → confirm batching before merging), and local verification (`bun run db:migrate` against a dev DB). Validation and feedback loops are present, so the destructive/batch cap does not apply. Not 4: checkpoints are explicit and error recovery is spelled out per lint tier.

Progressive Disclosure

Sections are well-organized and navigation is easy, but there is no overview/detail split — the full per-operation playbook table, the marker spec, and the lint-tier reference detail are all inline in an 89-line body, and the skill is over the ~50-line range where a self-contained single file earns a 5. Not 5: anchor 5 expects content "appropriately split"; the playbook and annotation-format reference material could live one level deep in a reference file with a lean overview left in SKILL.md. Not 3: structure is genuinely good — headers are clear, no buried or nested references, and nothing is misplaced.

Specificity

"Author or review a Drizzle DB migration for zero-downtime safety", "expand/contract phasing", "backward-compatibility with the deployed app version", and "writing the `-- migration-safe` acknowledgment the check:migrations lint requires" name multiple concrete, repo-specific actions that comprehensively cover the skill's scope. Not 4: there are no coverage gaps — the description spans authoring, reviewing, the phasing discipline, and the lint's annotation mechanism.

Completeness

Both what ("Author or review a Drizzle DB migration for zero-downtime safety...") and when ("Use when adding/editing files under `packages/db/migrations/` or changing `packages/db/schema.ts`") are explicit, with concrete trigger phrases. Not 4: the when-clause names specific file paths rather than leaving the trigger generic.

Trigger Term Quality

Natural terms a user would say ("Drizzle DB migration", "zero-downtime", "schema") plus concrete file-path triggers ("packages/db/migrations/", "packages/db/schema.ts", "check:migrations") give comprehensive coverage including path-level equivalents of file extensions. Not 4: no natural synonym or trigger variation is missing for this domain.

Distinctiveness Conflict Risk

Scoping to Drizzle plus this repo's specific migration paths and the named `check:migrations` lint gives it a clear niche with essentially no overlap risk against generic SQL, ORM, or deploy skills. Not 4: it is not merely "mostly distinct" — the triggers (repo paths, a named lint) cannot plausibly fire for another skill.