vellum-migration-checklist
The vellum-migration-checklist skill provides structured guidance for validating database migrations, workspace migrations, and release-note migrations in the Vellum Assistant codebase. Use this skill when creating, editing, reviewing, or testing any migration that modifies persisted data, database schemas, workspace file formats, or release documentation to ensure idempotency, proper registration, and comprehensive test coverage.
git clone --depth 1 https://github.com/vellum-ai/vellum-assistant /tmp/vellum-migration-checklist && cp -r /tmp/vellum-migration-checklist/.cursor/skills/vellum-migration-checklist ~/.claude/skills/vellum-migration-checklistSKILL.md
# Vellum Migration Checklist ## When A Migration Is Required Use a migration for shipped interfaces and persisted data: - DB schema changes, indexes, backfills, or persisted row shape changes. - Workspace file renames, moves, format changes, or namespace changes. - Stored config or data that existing installs must keep reading. Do not delete migration files. Migrations are append-only, even when their logic becomes obsolete. ## DB Migrations For DB migrations: 1. Add a new file under `assistant/src/memory/migrations/`. 2. Make it idempotent and safe to retry after interruption. 3. Register it in the migration index or registry used by DB init. 4. Update schema modules if the runtime schema changed. 5. Add or update a focused `db-*migration*.test.ts` test. Check for ordering drift and never reorder existing migrations. ## Workspace Migrations For workspace migrations: 1. Add a new numbered file under `assistant/src/workspace/migrations/`. 2. Append it to `WORKSPACE_MIGRATIONS` in `assistant/src/workspace/migrations/registry.ts`. 3. Make the migration idempotent. 4. Add or update a focused `workspace-migration-*.test.ts` test. Never reuse or reorder existing migration IDs. ## Release Notes Migrations There is currently no release-note surfacing mechanism. The update-bulletin feature (workspace migrations appending to a workspace bulletin file, processed by a background conversation at daemon startup) was removed. Do not add new `0XX-release-notes-*` workspace migrations — the historical set is frozen by `workspace-release-notes-feature-flag-guard.test.ts`. If a release needs user-facing notes, design an explicit on-demand surfacing mechanism first. ## Verification Run the focused migration test first. Add package typecheck when migration exports, schema types, or registry wiring changed: ```bash cd assistant && bun test src/__tests__/workspace-migration-example.test.ts cd assistant && bun test src/__tests__/db-example-migrations.test.ts cd assistant && bunx tsc --noEmit ``` Replace example paths with the actual test files related to the change.
>
>
>
>
Check Vellum Assistant architecture and package boundaries. Use when editing imports, moving code, adding endpoints, touching assistant/gateway/client/skill boundaries, or reviewing architecture-sensitive changes.
Review Vellum Assistant code changes for correctness, repo-specific quality rules, security risks, and missing validation. Use when reviewing diffs, preparing a PR, finishing implementation work, or when the user asks for a code review, quality pass, or pre-merge check in this repository.
Guide Vellum Assistant feature flag changes and rollout hygiene. Use when adding, editing, reviewing, or documenting assistant feature flags, rollout-gated behavior, or platform flag follow-up work.
Prepare Vellum Assistant branches for review by checking git hygiene, PR scope, tests, docs, migrations, Linear linking, and companion repo needs. Use before creating a pull request, splitting work into PRs, or asking whether a branch is ready.