agentsclimarketplace

Db

Skill rifatshampod/vibeops/skills/db

Ship your app without learning DevOps. A Claude Code plugin that deploys, hosts, and gates every risky step — in plain English.

Install
npx -y skills add rifatshampod/vibeops --skill db

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run database migrations and schema changes safely, with automatic backups and protection against destructive changes in production. Use whenever the user mentions migrations, database changes, schema, adding or removing tables or columns, or 'I need to update the database'. Also triggers on: "new table", "alter table", "drop column", "run migrations".

SKILL.md

4.6 KB, as published. Nobody here has run it

Vibeops — Database Migrations

You are running a database migration for the user's project. This skill has real side effects on data — it can be destructive if mishandled, so every step is wrapped in scripts/safe_migrate.sh, never run by hand.

Required references:

  • references/safety-rules.md — Rules 1 (Destructive Blocklist) and 2 (Production Lock)
  • references/railway.md — load when host: railway in config

Step 1 — Read .infra/config.yml

If the file does not exist:

"I need your project configured before I can run migrations. Run vibeops-configure first." Stop.

If there's no database: block in the config:

"Your app isn't set up with a database yet — there's nothing to migrate." Stop.

Step 2 — Identify the migration

Ask the user what changed, or check for pending migrations using the framework's own status command if one exists (e.g. php artisan migrate:status, npx prisma migrate status).

Explain in plain language what's about to happen before running anything:

"This will add a new email_verified column to your users table."

If you can't tell what the migration does from the files, say so plainly and ask the user to describe it before continuing.

Step 3 — Dry-run plan (Rule 5)

Print the plan before running anything:

Here's what I'm going to do:

1. Check your migration files for anything that deletes data or tables
2. Run the migration on your dev environment first
3. [If prod configured] Remind you to confirm a backup exists, then ask before touching production

Type 'yes' to continue, or tell me what you'd like to change.

Wait for explicit confirmation before proceeding.

Step 4 — Run on dev

bash "${CLAUDE_PLUGIN_ROOT}/scripts/safe_migrate.sh" dev .infra/config.yml

Translate the script's output to plain language as it runs. The script prints its own confirmation prompt ("Type 'yes' to run this") — relay it verbatim, do not pre-confirm on the user's behalf.

If dev migration fails: stop here. Report the error plainly. Do not touch production.

"The migration didn't complete on dev. Here's what went wrong: [error]. Want me to run a full diagnosis? Say 'doctor'."

Step 5 — Production (if configured)

If environments in config includes prod, offer to continue:

"Dev migration looks good. Want me to run this on production too?"

If yes:

bash "${CLAUDE_PLUGIN_ROOT}/scripts/safe_migrate.sh" prod .infra/config.yml

The script will, in order:

  1. Remind the user to verify a recent backup exists (Railway's automatic backups, or a manual one) — relay this verbatim
  2. If it found destructive statements (DROP/TRUNCATE/column-drop) in the migration files, show them and require the user to type I UNDERSTAND THE RISK before continuing — relay this prompt exactly, do not summarize it away
  3. Require the standard production confirmation — type DEPLOY — relay this exactly too

Never pre-confirm any of these prompts on the user's behalf. Both gates exist independently — a destructive migration to prod must pass both.

Step 6 — Report outcome

Success:

"Migration complete on [dev/production]. Your database schema is up to date."

Blocked by destructive-statement gate (user declined):

"Cancelled — no changes were made to production. The migration included statements that could delete data, so I held off until you confirm. Let me know if you want to review what would have changed."

Failed:

"The migration failed on [dev/production]. Error: [error from script output]. Your database wasn't left half-migrated by this script — that depends on your migration tool's own failure handling. Say 'doctor' if you want a full diagnosis."

What you must never do

  • Never run a migration command directly via raw CLI — always go through scripts/safe_migrate.sh
  • Never run a production migration without the Rule 2 confirmation (typed DEPLOY)
  • Never suppress, skip, or auto-answer the destructive-statement gate (typed I UNDERSTAND THE RISK)
  • Never claim a backup was taken if safe_migrate.sh only reminded the user to check Railway's automatic backups — it does not run pg_dump itself (it has no access to database credentials)
  • Never proceed to production if the dev migration failed

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.