Update to PlanetScale

{
  "name": "vitess-safety-review",
  "description": "Review a PlanetScale Vitess database for safe migrations, deploy requests, schema recommendations, Insights, webhooks, and operational safety.",
  "included_files": [],
  "skill_md_contents": "---\nname: vitess-safety-review\ndescription: Review a PlanetScale Vitess database for safe migrations, deploy requests, schema recommendations, Insights, webhooks, and operational safety.\n---\n\n# Vitess safety review\n\n## Purpose\n\nRecommend best practices for a PlanetScale Vitess database. Focus on production safety, deployability, observability, and agent-safe automation. Do not apply any changes.\n\n## Primary safety features to evaluate\n\n### Safe migrations\n\nCheck whether safe migrations are enabled on production and staging branches.\n\nRecommend enabling safe migrations when:\n\n- The branch receives production traffic.\n- The team runs DDL outside deploy requests.\n- There is no protected branch workflow.\n- The application is expected to evolve schema frequently.\n\nExplain the tradeoff: safe migrations reject direct DDL on protected branches and force schema changes through deploy requests. That is a feature, but it can break teams relying on direct production DDL. Treat enablement as a behavior-changing change requiring approval.\n\n### Deploy requests\n\nCheck:\n\n- Whether deploy requests are used for schema changes.\n- Whether administrator approval is required.\n- Whether deploy requests are reviewed for data loss, conflicts, lint errors, foreign key problems, charset issues, and shard impact.\n- Whether teams use gated deployments for cutover control.\n- Whether “deploy instantly” is used and whether the team understands it removes the gated-deployment/revert shape.\n- Whether cutover is regularly delayed by long-running transactions.\n- Whether deploy request events are subscribed to via webhooks.\n\nRecommend:\n\n- Require deploy requests for production schema changes.\n- Enable administrator approval for production deploy requests when there is more than one administrator.\n- In a single-admin organization, administrator approval does not stop an agent that acts as that admin:\n  the admin who opens a deploy request can also approve it. If the goal is to keep agents from\n  self-approving, give the agent a separate user, or a service token without deploy request\n  approval permission.\n- Prefer normal safe deployments over instant deployments unless the migration is known to be instant-safe and the rollback story is acceptable.\n- Use gated deployment when cutover timing matters.\n- Treat “force cutover now” as an operator-controlled action for delayed\n  cutovers: it aggressively stops running transactions to complete schema\n  cutover. Recommend reviewing the blocking workload and incident context\n  before use, and only recommend the database-level aggressive cutover default\n  when frequent cutover blocking is understood and accepted.\n\n### Schema revert\n\nCheck whether the team knows the revert window and whether their incident runbook includes it.\n\nRecommend documenting:\n\n- How to identify a bad schema migration.\n- How to revert within the supported window.\n- Who is authorized to revert.\n- Which application deploy should be rolled back together with the schema revert.\n\n### Branch strategy\n\nRecommend a branch topology:\n\n- `main` or equivalent production branch with safe migrations enabled.\n- `staging` branch based from production with safe migrations enabled.\n- Short-lived development branches based from staging.\n- Deploy requests from development to staging, then staging to production when appropriate.\n\nDo not create branches without approval.\n\n### Query Insights\n\nReview Insights for:\n\n- Slow queries.\n- Queries reading too many rows.\n- Erroring queries.\n- Queries with poor index usage.\n- For sharded databases, whether query patterns use relevant vindexes and how\n  vindex usage changes after index or routing changes.\n- Unusual query volume.\n- Missing SQL comment tags.\n- Tag breakdowns when built-in metadata or SQLCommenter tags are present:\n  `tag:key:value` filtering in the dashboard, and the `insights/tags` and\n  `insights/tags/summaries` API endpoints for programmatic breakdowns.\n- Deploy correlation data.\n\nRecommend enabling or improving application query tagging so Insights can attribute queries to app, route, controller, action, job, deployment SHA, and feature.\n\n### Anomalies\n\nReview active and recent anomalies.\n\nRecommend:\n\n- Subscribe `branch.anomaly` webhooks to the team’s alerting or automation system.\n- Route anomaly payloads to a triage workflow that opens an issue or agent task.\n- Correlate anomalies with deploy requests, application deploys, and query tags.\n- Do not automatically apply schema or code changes from anomaly events; generate a proposal or PR only.\n\n### Schema recommendations\n\nReview open schema recommendations.\n\nFor each recommendation, capture:\n\n- Type: add index, remove redundant index, primary key exhaustion, unused table, legacy charset/collation, or other.\n- Affected table and keyspace.\n- Supporting query telemetry.\n- DDL.\n- Expected benefit.\n- Risk.\n- Test plan.\n\nRecommend implementation path:\n\n- Convert the recommendation into an application migration or PlanetScale branch schema change.\n- Open a deploy request.\n- Review generated DDL and shard impact.\n- Benchmark or validate on a branch.\n- Deploy with safe migrations.\n- Monitor Insights and anomaly state after deployment.\n\nDo not apply recommendations directly.\n\n### Backups and restore\n\nCheck backup posture and restore runbooks.\n\nRecommend:\n\n- Verify automated backups exist.\n- Run a non-production restore drill periodically.\n- Document restore target, RPO/RTO expectation, and application cutover plan.\n- For sharded databases, document shard-aware restore expectations.\n\n### Sharding and keyspace safety\n\nIf the database is sharded, review:\n\n- Keyspaces and shards.\n- Vschema.\n- Cross-shard query patterns.\n- Whether schema deploy requests show per-shard impact.\n- Whether queries use shard-friendly access paths.\n\nRecommend an agent-safe sharding review only as a proposal. Never reshard, change vschema, or alter routing automatically.\n\n## Webhook recommendations for Vitess\n\nEvaluate and recommend webhooks for:\n\n- `branch.anomaly`\n- `branch.primary_promoted`\n- `branch.ready`\n- `branch.sleeping`\n- `cluster.storage`\n- `keyspace.storage`\n- `deploy_request.opened`\n- `deploy_request.queued`\n- `deploy_request.in_progress`\n- `deploy_request.pending_cutover`\n- `deploy_request.schema_applied`\n- `deploy_request.errored`\n- `deploy_request.reverted`\n- `deploy_request.closed`\n- `branch.schema_recommendation` if available in the webhook API for the customer’s database\n\nRecommended destinations:\n\n- Alerting for anomaly, primary promotion, storage, and deploy errors.\n- Slack or internal notifications for deploy request lifecycle.\n- Agent intake queue for schema recommendations and anomalies, with PR-only output by default.\n\n## Output\n\nReturn:\n\n- Current Vitess safety posture.\n- Missing safety features.\n- Recommended workflow.\n- Recommended webhook subscriptions.\n- Schema recommendation triage table.\n- Deploy safety gaps.\n- Proposed changes requiring approval.\n\nEnd with:\n\n“No Vitess changes have been applied.”\n"
}