database-reset-production

Production database reset drops all schemas (public, cms, hangfire) and rebuilds them via migrations. This Skill provides extreme caution through triple confirmations, backup verification, and post-reset health checks to ensure safety during critical maintenance.

A full production database reset is necessary when database corruption occurs, critical schema changes cannot be migrated incrementally, or explicit stakeholder approval exists for complete schema reconstruction. This approach rebuilds the entire schema from scratch rather than applying incremental migrations.

This reset process enforces double and triple confirmation prompts, verifies backups exist, retrieves credentials securely, handles service disruption, executes migrations, restarts containers, and validates health endpoints post-completion to catch failures immediately.

Yes, the SKIP_CONFIRMATION environment variable bypasses confirmation prompts, but this should only be used in automated pipelines with prior approval. Standard practice requires manual confirmation for all production database resets to prevent accidental data loss.

This reset drops the public, cms, and hangfire schemas entirely from the production database. After schemas are dropped, migrations rebuild them automatically, restoring full functionality through schema recreation and health verification.

Yes, this reset requires both SSH access to the production environment and psql for database operations. Credentials are retrieved securely during execution, and bash handles orchestration across service disruption, schema drops, migrations, and health checks.