Update to PlanetScale

{
  "name": "readonly-inventory",
  "description": "Collect read-only evidence about PlanetScale org, database, branches, webhooks, backups, roles, Insights, recommendations, and traffic configuration.",
  "included_files": [],
  "skill_md_contents": "---\nname: readonly-inventory\ndescription: Collect read-only evidence about PlanetScale org, database, branches, webhooks, backups, roles, Insights, recommendations, and traffic configuration.\n---\n\n# Read-only inventory\n\n## Purpose\n\nBuild an evidence-backed inventory of a PlanetScale database without making changes.\n\n## Allowed actions\n\nAllowed by default:\n\n- List organizations, databases, branches, keyspaces, regions, and sizes.\n- Read branch metadata.\n- Read webhook configuration.\n- Read schema recommendations.\n- Read Query Insights, anomalies, and query patterns through MCP or API.\n- Read traffic budgets and rules.\n- Read Postgres roles and non-secret role metadata.\n- Read backup schedules and restore metadata.\n- Read branch schema.\n- Inspect live connection/session metadata with the Connections CLI view.\n- Inspect repository files for frameworks, ORMs, migrations, SQL tagging, and connection config.\n- Inspect Terraform or other infrastructure-as-code definitions for\n  PlanetScale roles, backups, backup policies, Postgres parameters, and\n  supported extensions.\n\nNot allowed without explicit approval:\n\n- Any create, update, delete, enable, disable, reset, deploy, restore, promote, enforce, or apply operation.\n- Any SQL mutation.\n- Any command that emits new credentials unless the operator explicitly asked for credential work.\n\n## Interfaces and documentation grounding\n\nGround every command and endpoint in the official documentation instead of\nguessing. PlanetScale publishes agent-readable docs:\n\n- Docs index: https://planetscale.com/docs/llms.txt\n- Any docs page as markdown: append `.md` to its URL\n- API reference: https://planetscale.com/docs/openapi.yaml (OpenAPI 3.0)\n\nVerify an endpoint path in the API reference before calling it. A 404 from\nan unverified path is a wrong path, not a finding; do not record it as\nplatform state and do not conclude \"not configured\" from it.\n\nVerified interface notes (recheck against the docs when a command fails):\n\n- `pscale database show <database> --org <org>` — the org is a flag, not a\n  positional argument.\n- `pscale api <path>` takes org-relative paths such as\n  `organizations/{org}/databases/{db}/branches/{branch}` — there is no\n  `get` subcommand and no `/v1/` prefix. Pass query parameters with\n  `-Q key=value` flags; embedding `?`/`&` in the path breaks under shell\n  globbing.\n- `pscale webhook list <database> --org <org>` — the database is a\n  positional argument. `pscale backup list <database> <branch>` requires\n  the branch.\n- `pscale branch connections top <database> <branch>` — live read-only\n  session inventory works for Postgres and Vitess over a reserved\n  administrative connection. Do not cancel queries or terminate connections\n  unless the operator explicitly approves that operational action.\n- Query Insights is public API. Live query telemetry:\n  `.../branches/{branch}/insights` (per-pattern statistics; supports\n  `from`/`to`/`period`, `q`, `sort`, `dir`, `tablet_type`, `type`,\n  `fields`, and pagination). Related endpoints under the same branch path:\n  `insights/errors`, `insights/anomalies`, `insights/tags`,\n  `insights/tags/summaries`, `insights/{fingerprint}` (individual\n  executions), `insights/{fingerprint}/summary`, and\n  `insights/{fingerprint}/traffic/budgets`. The `query-patterns` path\n  returns generated report metadata, not live patterns.\n- Traffic budgets: `.../branches/{branch}/traffic/budgets`. The CLI has no\n  `pscale traffic-control budget list`; use the API for inventory.\n- Postgres roles: list via `.../branches/{branch}/roles`; fetch a single\n  role by ID, not name (`pscale role get <db> <branch> <role-id>`).\n- IP restrictions: database-level\n  `organizations/{org}/databases/{db}/cidrs`. Branch-level IP-restriction\n  paths are not valid.\n- Schema recommendations: database-level\n  `.../databases/{db}/schema-recommendations` (the branch-level path is\n  not valid). Requesting `page=2` currently returns 404 even when the\n  response reports `next_page`; use the database object's\n  `open_schema_recommendations_count` as the authoritative total, treat\n  the returned page as a sample, and state in the report when the itemized\n  list covers only part of the total.\n- PITR state and branch-level backup policies have no verified read path;\n  record backup posture from `pscale backup list` and the database-level\n  backup policy, and mark PITR \"not assessed in this run\" rather than\n  probing paths.\n- List endpoints paginate; follow the pagination parameters until\n  exhausted before reporting counts (except the schema-recommendations\n  case above).\n\nRecord access failures (403s, missing token scopes, timeouts) in the\ninternal run log for the operator. They are not findings and do not enter\nthe customer report (see `../customer-report-template/SKILL.md`).\n\n## Inventory checklist\n\n### Database identity\n\nRecord:\n\n- Organization.\n- Database.\n- Branch.\n- Engine: Vitess or Postgres.\n- Region and cloud provider.\n- Production/development branch status.\n- Branch protection and safe workflow state.\n- Size and cluster shape.\n\n### Branches and schema workflow\n\nFor Vitess, record:\n\n- Production branch.\n- Whether safe migrations are enabled for production and staging branches.\n- Open deploy requests.\n- Deploy request approval setting.\n- Pending schema changes.\n- Whether branch strategy has a staging branch with safe migrations enabled.\n\nFor Postgres, record:\n\n- Branch list.\n- Whether branches were created from backup or empty.\n- Whether schema changes are managed manually, through migrations, or through an ORM.\n- Whether a separate branch is used for migration testing.\n- Whether the team expects Vitess-style deploy requests; if yes, flag that Postgres branches do not use deploy requests in the same way.\n\n### Observability\n\nRecord:\n\n- Insights availability.\n- Whether query tags are present.\n- Which tags appear.\n- Whether high-cardinality tags are present.\n- Whether complete/raw query collection is enabled.\n- Active anomalies.\n- Query patterns with high latency, high rows read, high error rate, or high execution count.\n- Postgres CPU-heavy query patterns and Vitess vindex-usage data when exposed\n  by the Insights interface in use.\n- Whether application deploy identifiers are visible in comments or tags.\n\n### Recommendations\n\nRecord:\n\n- Open schema recommendations.\n- Recommendation type.\n- Affected table/query.\n- Proposed DDL or action.\n- Whether a branch/deploy workflow exists to evaluate it safely.\n- Whether the recommendation can be implemented as application code, ORM migration, or database DDL.\n\n### Webhooks and automation\n\nRecord:\n\n- Configured webhooks.\n- Subscribed events.\n- Enabled state.\n- Last delivery success or failure.\n- Destination category: Slack, PagerDuty, internal automation, CI, agent queue, unknown.\n- Whether webhook signature verification is documented or implemented.\n- Whether webhook handling is idempotent and asynchronous.\n\n### Postgres Traffic Control\n\nFor Postgres only, record:\n\n- Existing budgets and rules.\n- Budget modes: off, warn, enforce.\n- Limits: rate, capacity, burst, concurrency, warning threshold.\n- Rules by fingerprint, keyspace, query kind, or tags.\n- Whether rules are tied to meaningful SQLCommenter tags.\n- Whether any production budget is in enforce mode.\n\n### Postgres safety\n\nFor Postgres only, record:\n\n- Application role usage.\n- Whether apps use the default role.\n- Whether app roles are least-privilege.\n- Whether pg_strict is enabled for application roles.\n- Whether PgBouncer is used for appropriate workloads.\n- Whether live connections show blockers, idle-in-transaction sessions, or\n  connection saturation during an active incident.\n- Whether private connectivity and IP restrictions are configured.\n- Whether backup retention and PITR meet the customer’s recovery expectations.\n\n### Vitess safety\n\nFor Vitess only, record:\n\n- Safe migrations state.\n- Deploy request workflow.\n- Admin approval requirement.\n- Gated deployment usage.\n- Schema revert availability.\n- Branch and keyspace topology.\n- Sharding/vschema status.\n- Whether sharded query patterns use relevant vindexes.\n- Backups and restore posture.\n\n## Evidence format\n\nFor every finding, include evidence:\n\n- Source: MCP, CLI, API, dashboard-observed, SQL read-only, repository file.\n- Path or command used.\n- Timestamp.\n- Raw value or concise excerpt.\n- Confidence: high, medium, low.\n\n## Output\n\nReturn:\n\n- Inventory table.\n- Missing evidence table.\n- Risk flags.\n- Recommended next skills to run.\n\nEnd with:\n\n“No changes have been applied.”\n"
}