Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

db-migration

Étoiles3

Forks0

Mis à jour28 juin 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Highfivery

Highfivery/Pointsy

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Architectes de bases de donnéesProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.