Run any Skill in Manus with one click

db-migration

Stars3

Forks0

UpdatedJune 28, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Highfivery

Highfivery/Pointsy

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Database ArchitectsComputer and Mathematical Occupations·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.

More from this repository

same repository

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.