just-vibeGeneral · plan by default
/migrate
Plan and apply a version, schema, or implementation migration
Use for coordinated version or platform transitions; db-migrate handles database-specific mechanics; a bundler switch to Vite uses vite-setup.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select migrate from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv migrate, /just-vibe migrate and /jv:migrate in Claude. See shortcut setup and context examples.
/just-vibe:migrate Plan upgrading the job library while old workers remain active./just-vibe:migrate Apply the job-format migration while v1 workers still read stored jobs; define a restart point./just-vibe:migrate Plan a migration with missing legacy fixtures; identify the compatibility evidence still needed.What the agent does
- Inventory old and new consumers, dependents and persisted formats, and read the version-specific changes.
- Design transitional compatibility, prepare the edits and checks, and define recovery and the last reversible point before execution.
- Validate coexistence before removing compatibility code.
Inputs
- source/target version or implementation, compatibility needs, and rollout environment.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Ordered migration across affected code/config/data contracts; no unrelated upgrades.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Plan the migration when asked; apply for requested source/configuration changes and bounded compatibility checks. Executing a live migration needs its target and rollout/recovery constraints.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Ordered transitions or the authorized patch, a compatibility matrix, the recovery point and its limits, and verified versus unverified stages.
How the work is checked
- Old/new overlap behaves as specified; interrupted execution has a documented restart or recovery path.
When to stop or clarify
- Irreversible data loss, unsupported targets, or ambiguous production scope must be resolved before dependent mutations.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Inventory old/new versions, consumers, persisted state, generated artifacts and compatibility requirements.
- Method
- Read the relevant migration documentation and stage transition with explicit fallback before irreversible cleanup.
- Pitfall
- Updating a version string does not migrate runtime semantics; code rollback may not read new persisted data.
- Check
- Test old/new compatibility where required, migrated data invariants and interruption/recovery in isolation.
Situational decisions
When the target rejects an old persisted format: Add an explicit conversion and recovery path before changing readers.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.