Update to PlanetScale

{
  "name": "change-gates-and-approval-contract",
  "description": "Enforce explicit approval gates for any PlanetScale, database, repository, credential, network, or automation mutation.",
  "included_files": [],
  "skill_md_contents": "---\nname: change-gates-and-approval-contract\ndescription: Enforce explicit approval gates for any PlanetScale, database, repository, credential, network, or automation mutation.\n---\n\n# Change gates and approval contract\n\n## Purpose\n\nPrevent accidental or autonomous changes that can affect availability, safety, security, data, or developer workflows.\n\n## Operation classes\n\n### Class A: read-only by default\n\nAllowed without approval:\n\n- List databases, branches, keyspaces, webhooks, backups, roles, traffic budgets, schema recommendations, deploy requests, and Insights data.\n- Inspect repository code.\n- Read schema metadata.\n- Read non-sensitive database metadata.\n- Produce reports and proposed change sets.\n\n### Class B: state-creating proposals\n\nAllowed by default; requires approval only when the operator has demanded strict no-mutation mode:\n\n- Creating a query-pattern report through an API POST, even if the result is read-only telemetry.\n- Triggering a webhook test event.\n- Creating temporary local branches or files.\n- Opening PRs or issues in external tools.\n- Creating database development branches.\n- Applying DDL or migrations to non-production development branches.\n- Opening deploy requests targeting a branch protected by a review workflow.\n\nThe last three are proposals inside an existing review system: nothing\nreaches production until a human merges or deploys. The gate belongs on\nthe merge/deploy action (Class C/D), not on proposal creation. An agent\nthat stops to ask permission to open a PR is misclassifying.\n\n### Class C: behavior-changing\n\nAlways requires explicit approval:\n\n- Enable safe migrations.\n- Disable safe migrations.\n- Change deploy request approval settings.\n- Create/update/delete Traffic Control budget or rule.\n- Move Traffic Control budget to enforce mode.\n- Create/update/delete webhook.\n- Enable raw query collection.\n- Enable/disable extensions or settings that require restart.\n- Create/update/delete role.\n- Reset passwords.\n- Change pg_strict settings.\n- Change connection pooling behavior.\n- Change IP restrictions, PrivateLink, PSC, or public access.\n- Change backup schedule or retention.\n- Create restore branch.\n- Create backup beyond automatic backups.\n- Change branch size or replica topology.\n- Edit repository files or dependencies.\n\n### Class D: production data/availability impacting\n\nRequires explicit approval, named target confirmation, rollback plan, and ideally a second human review:\n\n- Production DDL.\n- Production DML.\n- Applying schema recommendation to production.\n- Queueing or applying Vitess deploy request to production.\n- Promoting or restoring branches.\n- Deleting branches, databases, roles, webhooks, backups, or traffic rules.\n- Enforcing Traffic Control on production.\n- Changing production network access.\n- Rotating production credentials.\n- Emergency backup during high load.\n\n### Class E: never autonomous\n\nNever do without direct human operation or separately approved incident procedure:\n\n- Delete a production database.\n- Disable all production safety mechanisms.\n- Drop production tables or columns.\n- Remove IP restrictions or private-only posture.\n- Store or expose secrets in logs, issues, PRs, Slack, or reports.\n- Auto-merge code generated from database telemetry.\n- Auto-apply DDL generated by an LLM.\n\n## Approval requirements\n\nA valid approval must include:\n\n- Change ID.\n- Target organization/database/branch.\n- Whether production is affected.\n- Permission to execute the exact action.\n\nInvalid approvals:\n\n- “Do the best practices.”\n- “Fix everything.”\n- “Apply recommendations.”\n- “Go ahead” without named change IDs.\n\n## Autonomous execution exception\n\nThere is exactly one alternative to per-change approval: the risk-acknowledged\nautonomous mode defined in `../autonomous-execution-mode/SKILL.md`. When the\noperator explicitly acknowledges the risk, names a scope, and states whether\nproduction is included, that acknowledgment substitutes for per-change approval\nof Class B/C (and Class D when production is included) actions **within the\nnamed scope only**.\n\nEverything else in this skill still applies in autonomous mode:\n\n- Class E is never unlocked by any phrasing.\n- The pre-execution checklist must still be produced for every Class C/D step\n  (shown as the execution plan, not as a stop-and-wait).\n- The post-execution report is still required.\n- Out-of-scope work still requires new approval or new acknowledgment.\n\n## Required pre-execution checklist\n\nBefore any Class C or D action, produce:\n\n- Exact command, API endpoint, dashboard action, SQL, or repository diff.\n- Target confirmation.\n- Expected effect.\n- Availability impact.\n- Data risk.\n- Security risk.\n- Rollback plan.\n- Validation plan.\n- Monitoring plan.\n\nThen stop for approval.\n\n## Required post-execution report\n\nIf an approved change is later executed, report:\n\n- What changed.\n- When it changed.\n- Who approved.\n- Interface used.\n- Evidence of success.\n- Any warnings.\n- Rollback state.\n- Follow-up monitoring.\n\n## Required refusal behavior\n\nIf asked to apply broad or ambiguous production changes, refuse the broad action and produce a safer named change plan.\n\nUse this sentence:\n\n“I will not apply broad production changes from an ambiguous instruction. I can produce a named change set with risk and rollback details.”\n"
}