verify-db-changelisted

End-to-end verification of a database change (new tables, columns, indexes, writers/projectors) against real Postgres before review or merge. Replaces vibes-only "looks fine" sign-off with a structured proof block — schema applied per tenant, behavioural SQL exercised inside BEGIN…ROLLBACK on the live dev DB, app booted with the new wiring, and migration reversibility proved against a throwaway schema clone. Produces a PR-ready markdown excerpt with real captured output. Use this skill whenever the user asks to verify a migration, test a migration, prove a schema change works, verify a projector / writer / repository, "run any manual test needed to prove completion", or anything that means "show me the database actually works, not just the unit tests". Also use proactively when reviewing a PR that touches migrations or DB writers and the existing description has no real-Postgres proof. Designed for TypeORM + Nest + Postgres monorepos with multi-tenant DBs and Docker-Compose local infra, but the principles app
decebal/curated-claude-skills · ★ 0 · API & Backend · score 58

Install: claude install-skill decebal/curated-claude-skills

# Verify DB Change Prove a database change works end-to-end against real Postgres — not by asserting against mocks. The output is a markdown proof block, suitable for pasting into a PR description, that quotes actual captured output from each step. If a step did not run or did not pass, the proof block says so explicitly. No paraphrasing, no inferred outcomes. This skill is designed for the case where the change is a typical projection-plane drop: one or more migration files, a writer / projector class, an entity or schema update, and (optionally) DI wiring in an app module. It generalizes cleanly to any `INSERT … ON CONFLICT` / `UPDATE` pattern and to migrations that touch existing tables. ## Core principles (why this skill exists) 1. **Real DB beats mocks for SQL contracts.** Unit tests that stub `manager.query()` validate that the projector *calls* a query — they validate nothing about whether the query *does what you think* in Postgres. `ON CONFLICT DO NOTHING`, `GREATEST(...)`, returning-row semantics, FK cascade, generated columns, partial indexes — these are SQL contracts. They must be tested against a real Postgres at least once before merge. 2. **`BEGIN…ROLLBACK` is your friend for non-destructive happy / edge tests.** A wrapped transaction lets you exercise the writer's actual SQL against the live dev DB, observe the results, and roll them back so the DB is byte-identical afterwards. Cheaper than spinning up a fresh DB, more honest than mocks. The only thing it