Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

db-migration

Estrellas3

Forks0

Actualizado28 de junio de 2026 a las 21:58

Safely change the Pointsy Drizzle schema and generate a migration. Use whenever a feature needs a new/changed table, column, enum, or index.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

Highfivery

Highfivery/Pointsy

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Arquitectos de bases de datosOcupaciones informáticas y matemáticas·SOC 15-1243

SKILL.md

readonly

name	db-migration
description	Safely change the Pointsy Drizzle schema and generate a migration. Use whenever a feature needs a new/changed table, column, enum, or index.

Database migration

Steps

Edit lib/db/schema.ts. Keep every domain table carrying familyId with references(() => families.id, { onDelete: "cascade" }). Add an index on familyId for new tables. Export $inferSelect/$inferInsert types.
Prefer additive changes. Add nullable columns or new tables rather than renaming/dropping. For a rename, do expand → backfill → contract across separate migrations.
Generate: npm run db:generate -- --name <short_snake_case>.
Review the SQL in drizzle/ — confirm no unintended drops, FKs and onDelete are correct, and enums are altered (not recreated) where possible.
Verify against real SQL: the PGlite integration tests run all migrations; npm test must pass. Add a tenant-isolation test for any new table.
Apply the migration to the DB the app actually uses — run npm run db:migrate yourself (reads .env.local → the Neon DB). The owner wants this run as a matter of course, not handed back as a command to copy; only pause if the harness permission layer blocks the write (then ask once to allow it). The deploy also applies it automatically (scripts/vercel-migrate.mjs runs before build on production).
Run the app against that migrated DB and exercise the changed read/write paths (e.g. the kid /me screen for a chores change). Screenshots/dev runs against a throwaway Docker DB do not count — that DB isn't the one the user runs.

Guardrails

Green tests do NOT mean the real DB is migrated. Vitest/PGlite and Playwright each migrate a throwaway DB, so a new column always exists in tests even when the real DB is behind. Never say "done" for a migration change until step 6 has run against the real DB and step 7 confirms the live app works. (Shipping a category_id query ahead of its migration broke kid login in 0.31.x.)
Never edit an already-committed migration file — add a new one.
Ledger stays append-only; don't add update/delete paths for it.
Money/points columns are integer and may be negative.

Más de este repositorio

mismo repositorio

a11y-audit

Highfivery/Pointsy

Audit changed Pointsy screens against the WCAG 2.1 AAA checklist (automated axe + manual review) and fix issues. Use whenever UI is added or changed.

2026-06-243

review-pr

Highfivery/Pointsy

Structured review of a Pointsy change before merge across correctness, security/tenant-isolation, accessibility, performance, and tests. Use before requesting review or merging.

2026-06-243

implement-feature

Highfivery/Pointsy

Implement a Pointsy feature end-to-end against an agreed spec, following the house rules. Use after spec-feature, or when the user asks to build/implement a feature.

2026-06-233

spec-feature

Highfivery/Pointsy

Turn a feature request into a concrete mini-spec for Pointsy before any code is written. Use when starting any non-trivial feature, when requirements are fuzzy, or when the user asks to "spec" or "plan" something.

2026-06-223

Database migration

Steps

Edit lib/db/schema.ts. Keep every domain table carrying familyId with references(() => families.id, { onDelete: "cascade" }). Add an index on familyId for new tables. Export $inferSelect/$inferInsert types.

Prefer additive changes. Add nullable columns or new tables rather than renaming/dropping. For a rename, do expand → backfill → contract across separate migrations.

Generate: npm run db:generate -- --name <short_snake_case>.

Review the SQL in drizzle/ — confirm no unintended drops, FKs and onDelete are correct, and enums are altered (not recreated) where possible.

Verify against real SQL: the PGlite integration tests run all migrations; npm test must pass. Add a tenant-isolation test for any new table.

Apply the migration to the DB the app actually uses — run npm run db:migrate yourself (reads .env.local → the Neon DB). The owner wants this run as a matter of course, not handed back as a command to copy; only pause if the harness permission layer blocks the write (then ask once to allow it). The deploy also applies it automatically (scripts/vercel-migrate.mjs runs before build on production).

Run the app against that migrated DB and exercise the changed read/write paths (e.g. the kid /me screen for a chores change). Screenshots/dev runs against a throwaway Docker DB do not count — that DB isn't the one the user runs.

Guardrails

Green tests do NOT mean the real DB is migrated. Vitest/PGlite and Playwright each migrate a throwaway DB, so a new column always exists in tests even when the real DB is behind. Never say "done" for a migration change until step 6 has run against the real DB and step 7 confirms the live app works. (Shipping a category_id query ahead of its migration broke kid login in 0.31.x.)

Never edit an already-committed migration file — add a new one.

Ledger stays append-only; don't add update/delete paths for it.

Money/points columns are integer and may be negative.