From ops-suite
Run database migrations on remote environments. Identifies pending migrations, connects to the target database, runs the migration command, and verifies the result.
npx claudepluginhub weorbitant/workbench-dev --plugin ops-suiteThis skill is limited to using the following tools:
Check if `/tmp/ops-suite-session/config.json` exists:
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Check if /tmp/ops-suite-session/config.json exists:
config.yaml, parse it, and write to /tmp/ops-suite-session/config.json for other skills to reuse.
If neither exists, tell the user to copy config.example.yaml to config.yaml and fill in their values. Stop here.Extract:
deploy.migration_tool — determines which adapter to loaddeploy.migration_command — the command to run migrationsdeploy.local_ports — local ports for port-forwarding to databasesorchestrator — for port-forward commandsenvironments — connection details for each environmentAlso read the reference at references/commands.md (in this skill's directory).
Read the adapter file at adapters/{deploy.migration_tool}.md (in this skill's directory).
If the adapter does not exist, tell the user that the migration tool {deploy.migration_tool} is not yet supported and stop.
If $ARGUMENTS contains an environment name, use it. Otherwise ask the user.
IMPORTANT: Always recommend running migrations on dev first before prod.
Use the adapter's "list pending" command to check what migrations need to run. If there are no pending migrations, inform the user and stop.
Show the user:
The migration tool needs a database connection. This typically requires:
Port-forward to the database using the orchestrator:
kubectl --context={env.context} port-forward svc/{env.services.database.name} {deploy.local_ports.{env_name}}:{env.services.database.port} -n {env.services.database.namespace || env.namespaces.infra} &
Note: Use env.services.database.namespace if defined — the database/pgbouncer may live in a
different namespace than env.namespaces.infra.
Credentials: First check if env.services.database.credentials_from is defined in config:
pod_env:<VAR_NAME>: retrieve from a running app pod:
kubectl --context={env.context} exec {any_app_pod} -n {env.namespaces.apps} -- printenv <VAR_NAME>
Set environment variables as required by the migration tool (from adapter).
Determine database name: If service_databases is defined in config, use it to resolve
the correct database name for the target service and environment. Otherwise fall back to
env.services.database.default_db.
ALWAYS ask for explicit confirmation before running migrations.
Display:
Ready to migrate:
Environment: {env_name}
Database: {env.services.database.default_db}
Pending: {count} migration(s)
Files: {migration_file_list}
This will modify the database schema. Proceed? (yes/no)
Execute the migration command from deploy.migration_command or the adapter's default command.
Capture both stdout and stderr.
After migration completes:
Migration Summary:
Environment: {env_name}
Database: {database}
Migrations: {count} applied
Status: {success/failed}
Applied:
- {migration_name_1}
- {migration_name_2}
Cleanup:
- Port-forward killed (PID {pid})