#What it does

The /rollback skill executes safe rollback procedures when a deployment goes wrong. It identifies the last known good state, checks for database migration conflicts, and reverts with zero data loss.

#How to use

/rollback
/rollback to v2.3.1
/rollback --dry-run

#Workflow

1. Assess -- Identifies the current broken deployment and the last healthy version
2. Check migrations -- Determines if database migrations are reversible without data loss
3. Plan -- Creates a rollback plan with exact steps and risk assessment
4. Execute -- Reverts the deployment to the target version
5. Verify -- Runs health checks and confirms the system is stable
6. Report -- Documents what happened for the post-mortem

#Safety checks before rollback

• Migration compatibility -- Are there destructive migrations (dropped columns, renamed tables) that prevent rollback?
• API contracts -- Will rolling back break mobile apps or third-party integrations on the new contract?
• Feature flags -- Can the broken feature be disabled without a full rollback?
• Data integrity -- Were new data formats written that the old version cannot read?

#Example

> /rollback
 
# Current state:
Deployment v2.4.0 deployed 12 minutes ago
Error rate: 8.3% (threshold: 1%)
Affected: /api/checkout endpoint returning 500
 
# Last healthy version: v2.3.2 (deployed 3 days ago)
 
# Migration check:
v2.4.0 added column `orders.discount_code` (nullable) -- safe to rollback
No destructive migrations detected.
 
# Rollback plan:
1. Revert Vercel deployment to v2.3.2
2. No migration rollback needed (additive only)
3. Clear CDN cache for affected routes
4. Monitor error rate for 5 minutes
 
# Executing...
  Reverted to v2.3.2
  Error rate: 0.02% (nominal)
  Health check: all passing
 
# Rollback complete. Create post-mortem? (y/n)