← Skills

Neexo Production Database Sync Skill

Guides careful production database sync and inspection workflows with explicit safety checks, environment boundaries, and rollback awareness.

AuthorNeexoCore
Sourcegithub.com/NeexoCore/awesome-neexo
Updated
databaseproductionsafety

Overview

Use this skill only for approved database maintenance workflows. It is designed to make environment boundaries and destructive risk visible.

This skill is for inspection, controlled sync, and recovery-aware database work. It should slow the agent down around production data, force explicit source/target naming, and make backup and rollback expectations visible before any write operation.

Safety Checks

  • Confirm source and target environments
  • Never print secrets or connection strings
  • Prefer read-only inspection before writes
  • Call out destructive operations before execution
  • Record validation and rollback considerations

Required Flow

  1. Identify environments — name the source and target clearly, including provider/project names when visible.
  2. Verify credentials safely — confirm which env vars or secret names are being used without printing secret values.
  3. Inspect first — run read-only schema/table checks before any write, migration, import, or export.
  4. Back up target — require a backup, snapshot, or export path before modifying production-like data.
  5. Plan rollback — state exactly how to restore or undo the operation if validation fails.
  6. Execute narrowly — prefer scoped tables, filtered records, dry-runs, and transaction boundaries.
  7. Validate — compare row counts, checksums, schema versions, and application smoke checks after the sync.

Environment Detection

  • Treat names containing prod, production, live, or customer identifiers as production-risk environments.
  • Treat main, master, and Vercel production deployments as production-risk unless the repo proves otherwise.
  • Do not infer safety from local shell names alone; inspect explicit env vars, config files, or deployment metadata.
  • If NODE_ENV=production, VERCEL_ENV=production, or a production database URL is active, stop before writes and ask for confirmation.

Drizzle and Migration Rules

  • Keep schema changes, generated migration SQL, and dependent code in the same commit.
  • Prefer drizzle-kit check or equivalent validation before applying migrations.
  • Never edit an already-applied production migration in place; add a forward migration instead.
  • For destructive changes, write the data preservation or backfill step explicitly.

Rollback Checklist

  • Backup location and timestamp
  • Restore command or provider snapshot link
  • Tables or tenants affected
  • Post-restore validation query
  • Owner who approved the operation

Raw content

Copy this into your project — e.g. .instructions.md, .agent.md, or SKILL.md

## Overview

Use this skill only for approved database maintenance workflows. It is designed to make environment boundaries and destructive risk visible.

This skill is for inspection, controlled sync, and recovery-aware database work. It should slow the agent down around production data, force explicit source/target naming, and make backup and rollback expectations visible before any write operation.

## Safety Checks

- Confirm source and target environments
- Never print secrets or connection strings
- Prefer read-only inspection before writes
- Call out destructive operations before execution
- Record validation and rollback considerations

## Required Flow

1. **Identify environments** — name the source and target clearly, including provider/project names when visible.
2. **Verify credentials safely** — confirm which env vars or secret names are being used without printing secret values.
3. **Inspect first** — run read-only schema/table checks before any write, migration, import, or export.
4. **Back up target** — require a backup, snapshot, or export path before modifying production-like data.
5. **Plan rollback** — state exactly how to restore or undo the operation if validation fails.
6. **Execute narrowly** — prefer scoped tables, filtered records, dry-runs, and transaction boundaries.
7. **Validate** — compare row counts, checksums, schema versions, and application smoke checks after the sync.

## Environment Detection

- Treat names containing `prod`, `production`, `live`, or customer identifiers as production-risk environments.
- Treat `main`, `master`, and Vercel production deployments as production-risk unless the repo proves otherwise.
- Do not infer safety from local shell names alone; inspect explicit env vars, config files, or deployment metadata.
- If `NODE_ENV=production`, `VERCEL_ENV=production`, or a production database URL is active, stop before writes and ask for confirmation.

## Drizzle and Migration Rules

- Keep schema changes, generated migration SQL, and dependent code in the same commit.
- Prefer `drizzle-kit check` or equivalent validation before applying migrations.
- Never edit an already-applied production migration in place; add a forward migration instead.
- For destructive changes, write the data preservation or backfill step explicitly.

## Rollback Checklist

- Backup location and timestamp
- Restore command or provider snapshot link
- Tables or tenants affected
- Post-restore validation query
- Owner who approved the operation