Menu
Safely create, apply, and revert TypeORM migrations in packages/api. Use for any database schema change, entity field change, or when a migration fails locally or in deploy.
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.
Based on SOC occupation classification
Write a vault watcher `parse(email)` JS script from a sample bank/alert email, for the Gmail-to-transaction pipeline. Use when the user gives a sample email (or describes one) and wants a parseScript for a Vault Gmail Watcher.
Builds and updates the API in `packages/api` using this repo's module layout, shared DTOs, response envelope, guards, services, entities, and e2e test conventions. Use for controllers, services, modules, auth flows, database changes, migrations, and integration tests.
Use when building React applications in .tsx files. Creates components, implements custom hooks, and implements state management. Invoke for Server Components, Suspense boundaries, useActionState forms, performance optimization, or React 19 features.
Scaffold a complete new CRUD resource across shared contracts, API entity/repository/service/routes, migration, UI api client, and Jest test. Use when adding a new domain resource (e.g. budgets, goals) to the expense tracker.
Write Jest unit tests for API services following this repo's mock/factory/AppError conventions. Use when adding or extending tests in packages/api/src/tests.
| name | migration |
| description | Safely create, apply, and revert TypeORM migrations in packages/api. Use for any database schema change, entity field change, or when a migration fails locally or in deploy. |
SQLite via TypeORM (better-sqlite3). Migrations live in packages/api/src/migrations/ and are discovered by glob: src/migrations/*.ts under ts-node (dev), dist/migrations/*.js in production.
All from the repo root:
npm run migration:generate # diffs entities vs DB → src/migrations/<timestamp>-Migration.ts
npm run migration:run # apply immediately — ALWAYS run right after generating
Rules:
migration:generate from entity changes.entities: [...] array of src/data-source.ts before generating, or the diff misses them.<timestamp>-AddDebts.ts / class AddDebts<timestamp>), matching existing named migrations.Z-seed-data.ts must always sort last. It is a hand-authored idempotent seed with fixed UUIDs. Never name a migration so it sorts after Z- (alphabetical ordering decides run order for equal-format names; keep timestamp prefixes).CREATE TABLE temporary_... + copy). That is normal — review that no column data is dropped, then commit as-is.npm run migration:revert # undoes the most recent applied migration
data-source.ts, or the local DB is already ahead; check migrations table in packages/api/pocket_pixel.sqlite (the pocket-pixel-sqlite MCP server can read it).packages/api/pocket_pixel.sqlite and npm run migration:run to rebuild from scratch (seed migration repopulates demo data). Local dev DB only; never do this in prod.