bifrost: Skill for Claude Code

Release Checklist

A pre-release safety audit. Given a set of changes destined for release, run every check in the Checks Registry below and produce one consolidated report. This skill is read-only: it diagnoses, recommends a concrete fix for every finding, and never edits files. Applying a fix is a separate, explicitly-approved step.

The registry currently holds two migration-safety checks. It is designed to grow - see Adding a New Check.

Scope: what "the release" means

Determine the change set to audit, in this order:

1. If the user passed a git ref or range (e.g. /release-checklist v1.4.0..HEAD or /release-checklist origin/dev), use it.
2. Otherwise default to everything not yet on the main branch: diff origin/dev...HEAD (three-dot) and also include uncommitted working-tree changes.
3. If that range is empty, tell the user and ask for an explicit range.

Gather the raw material once, up front:

git fetch origin --quiet
git diff --stat origin/dev...HEAD
git diff origin/dev...HEAD -- '**/migrations.go' '**/matviews.go'
git status --porcelain

Migrations here are Go-defined, not .sql files. They live in:

• framework/configstore/migrations.go - config DB (providers, keys, virtual keys, budgets)
• framework/logstore/migrations.go - log DB (request logs; the high-volume table)
• framework/logstore/matviews.go - materialized views over the log DB

A release with no diff in these files has no migration risk - record both migration checks as PASS (no migrations changed) and move on.

Migration system facts (needed by both checks)

• All migrations run synchronously at boot. triggerMigrations() executes the full ordered migration list during store init, before the process serves traffic.
• Supported databases: PostgreSQL and SQLite only. No MySQL. Lock behavior differs sharply between the two - judge both.
• Migrations are cluster-serialized behind Postgres advisory lock 1000001 with a 5-minute acquisition timeout. A slow migration on one pod stalls every other pod's boot.
• Each migration func runs in a transaction by default (Options.UseTransaction = true). A transaction holds every lock until the func returns - migration duration is lock duration.
• Established escape hatch for heavy work: index builds and materialized views run in post-startup background goroutines under separate advisory locks (1000002 for indexes, 1000005/1000006 for matviews) - see framework/logstore/postgres.go, ensurePerformanceIndexes(), ensureMatViews(). migrationAddProviderHistogramIndex is intentionally a near-no-op that defers the real CREATE INDEX CONCURRENTLY there. This deferral pattern is the correct fix for anything heavy.