/db-migrate

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select db-migrate from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv db-migrate, /just-vibe db-migrate and /jv:db-migrate in Claude. See shortcut setup and context examples.

What the agent does

1. Inspect engine/version, migration runner transaction behavior, data shape and old/new application contracts. Record which versions read and write each field during rollout.
2. Separate expansion, restartable backfill, validation and contraction. Define lock/downtime bounds, batch identity/checkpoint and interruption handling; estimate impact from evidence rather than row count alone.
3. Exercise migration and restart on isolated representative data, including duplicates, nulls and old writers. Verify indexes/constraints are actually valid and semantically match the intended definition; name existence alone is insufficient.
4. Define recovery per phase: code rollback, forward repair, and restoration of lost information are different operations. Delay destructive contraction until old readers/writers are retired and the agreed evidence establishes compatibility.
5. Use the matching bundled evidence collector when available; read its result and limitations rather than treating exit zero as readiness. Revalidate identity before a dependent action.

Inputs

• schema/data change, engine/version, deployment sequence, data volume, and recovery requirements.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Migration design/files when requested; live execution needs the exact environment/action authorization.

Writes

Inspect/plan: inspect or propose; save requested artifacts only. Apply: make the requested changes or execute the requested operation within its resolved target and limits. Local preparation does not authorize live, remote, destructive or paid actions; existing explicit session authorization still applies.

Mode

Plan a migration when planning is requested; apply for requested migration files and isolated compatibility checks. Applying to a live database requires its exact environment, rollout and recovery constraints.

Prerequisites

Actual engine/version, schema/migrations, query workload, and explicitly identified environment. Prefer supplied plans, metadata, and isolated fixtures. Even a SELECT can lock, call mutating functions, or overload a database; inspect semantics before execution. Executing an analyzed query is distinct from reading its plan.

Expected output

• Migration plan or files as a phase table (SQL or runner step, lock risk, check, recovery), with compatibility evidence, execution conditions and rollback/forward-recovery limits.

How the work is checked

• Older app versions survive the intended overlap; interruption can resume without duplicated conversion.

When to stop or clarify

• Never promise rollback for irreversible data loss. Missing backup/recovery evidence blocks destructive execution.

Handling missing context

Infer

Read engine/version, ORM/runner, schema and migration history from project artifacts before choosing SQL.

Assume

Prepare local SQL and isolated fixtures without assuming production size, locks or recovery guarantees.

Ask

Ask for environment, downtime or recovery constraints before live/destructive execution when missing; unavailable production access does not block migration files.

Technical guidance

Evidence

Read generated SQL, migration ledger, engine/version, data volume, locks and active application versions.

Method

Plan expansion/backfill/switch/contraction where needed; define idempotent resume and recovery at each irreversible step.

Pitfall

ORM migration generation does not establish safe production locking; a down migration cannot recreate discarded values.

Check

Apply to a representative isolated schema/data copy, interrupt a batch, resume and check compatibility with both application versions.

Situational decisions

When a PostgreSQL concurrent index is required: Use the runner's supported nontransactional path, check invalid indexes after interruption, and never treat name existence alone as proof of a valid matching index.

When the request is for local preparation or implementation: Write the requested migration and compatibility checks using observed engine/runner conventions; identify missing deployment or recovery evidence before applying to a live database.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring