db-migrations

Generate, test, and apply Kysely migrations for Birdhouse SQLite databases.

36|5|Updated Feb 27, 2026
One-click install
npx skills add https://github.com/Birdhouse-Labs/birdhouse --skill db-migrations-birdhouse-labs
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: db-migrations
Source: https://github.com/Birdhouse-Labs/birdhouse/tree/main/.agents/skills/internal/birdhouse-development/db-migrations
Command: npx skills add https://github.com/Birdhouse-Labs/birdhouse --skill db-migrations-birdhouse-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Birdhouse maintains two separate SQLite databases (data.db and agents.db), each with its own Kysely migration system, and writing migrations incorrectly can corrupt real user databases. This Skill gives agents a safe, test-driven workflow for creating and verifying migrations without ever touching production data. ## Core Features & Use Cases - Migration Generation: Scaffold timestamped migration files with automatic runner registration using agent-migration:new and data-migration:new scripts. - Test-Based Verification: Validate every migration against fresh databases and real fixture snapshots via the bun test suite, including fixture count updates. - Controlled Application & Rollback: Apply or roll back migrations on specific databases only when a human explicitly requests it, using the db:migrate-* scripts. - Use Case: When adding a notes column to the agents table, generate the migration, implement up/down with raw SQL (including safe SQLite table-recreation patterns), run the test suite, and update TypeScript types — all without touching a real database. ## Quick Start Ask the agent to add a new database migration for the agents table and verify it with the test suite.

Frequently Asked Questions about db-migrations

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a new database migration in Birdhouse?▼

Run `bun run agent-migration:new <name>` for agents.db or `bun run data-migration:new <name>` for data.db from the server directory. The generator creates a timestamped file and registers the static import in the runner automatically.

How do I verify a SQLite migration without touching real databases?▼

Run `bun test` in the server directory. The test suite applies every migration to a fresh empty database and to committed real-world fixture snapshots, proving both new installs and existing customer databases survive.

Why does SQLite column removal require table recreation?▼

SQLite cannot drop columns directly in older schemas, so the down migration renames the old table, creates a replacement with the final table name, copies rows explicitly, and recreates all indexes. Self-referential foreign keys must target the final table name to avoid SQLite preserving the temporary name.

Can I apply a migration to a specific production database?▼

Only when a human explicitly asks. Use `bun run db:migrate-data <path>` or `bun run db:migrate-agents-db <workspace-id-or-path>` from the server directory, and confirm the database path with the human before running.

When should I never rename a migration file?▼

Never rename a migration after it has run on any database, because Kysely uses the filename as its tracking key. Renaming breaks the migration history and can cause re-application or rollback failures.