Update to PlanetScale

{
  "name": "traffic-control-recommendations",
  "description": "Build a safe recommendation plan for PlanetScale Postgres Database Traffic Control budgets and rules without applying them.",
  "included_files": [],
  "skill_md_contents": "---\nname: traffic-control-recommendations\ndescription: Build a safe recommendation plan for PlanetScale Postgres Database Traffic Control budgets and rules without applying them.\n---\n\n# Database Traffic Control recommendations\n\n## Purpose\n\nFor PlanetScale Postgres, recommend Traffic Control budgets and rules that protect critical traffic from runaway queries, traffic spikes, batch jobs, agents, and third-party integrations. Do not create or change budgets without approval.\n\n## Preconditions\n\nRun this skill only for PlanetScale Postgres.\n\nBefore recommending rules, inspect:\n\n- Current budgets and rules.\n- Insights query patterns.\n- Current query tags.\n- Application routes and jobs.\n- Known critical paths.\n- Known expensive non-critical paths.\n- Active incidents or recent anomalies.\n\nIf query tags are missing, recommend tagging first unless a fingerprint-specific rule is clearly needed for an immediate known offender.\n\n## Candidate traffic slices\n\nLook for:\n\n- Exports.\n- Reports.\n- Search endpoints.\n- Admin dashboards.\n- Backfills.\n- Workers and queues.\n- Webhooks from third-party systems.\n- BI tools.\n- Agent-generated read queries.\n- High-frequency polling.\n- Known expensive query fingerprints.\n- Customer-triggered endpoints with high variance.\n\n## Budget modes\n\nRecommend in this order:\n\n1. `warn` mode first for normal rollout.\n2. Observe warnings and false positives.\n3. Tune tags, fingerprints, and thresholds.\n4. Move to `enforce` only with explicit approval and an emergency rollback path.\n\nDo not recommend starting directly in `enforce` unless there is an active incident and the operator explicitly asks for emergency mitigation.\n\n## Rule strategy\n\nPrefer tag-based rules when tags are stable and bounded:\n\n- `source=agent`\n- `source=bi`\n- `feature=export`\n- `feature=report`\n- `route=/admin/reports`\n- `job=DailyBackfill`\n- `service=analytics-worker`\n\nUse fingerprint rules when:\n\n- A specific known query pattern is dangerous.\n- Tagging is missing or unreliable.\n- The query source is hard to attribute.\n\nUse a separate budget for each materially different traffic class.\n\nDo not combine unrelated traffic in one budget because it hides who is consuming the budget.\n\n## Suggested default budgets\n\nUse these as recommendation patterns, not as values to apply blindly.\n\n### Agent budget\n\nTarget: queries tagged `source=agent` or `source=mcp`.\n\nIntent: prevent agents from starving application traffic.\n\nMode: start in `warn`.\n\nRecommendation: agents should prefer replicas and read-only scopes. Writes require human approval.\n\n### Export/reporting budget\n\nTarget: `feature=export`, `feature=report`, or specific report route/job.\n\nIntent: keep customer-triggered reporting from consuming all database resources.\n\nMode: start in `warn`; consider `enforce` after observation.\n\n### Background job budget\n\nTarget: worker service, queue, or job tags.\n\nIntent: prevent backfills and retries from starving interactive traffic.\n\nMode: `warn` first; enforce only after confirming queue backpressure behavior.\n\n### Third-party integration budget\n\nTarget: `source=integration`, partner-specific bounded tags, or route templates for inbound integration calls.\n\nIntent: isolate unpredictable partner behavior.\n\nMode: `warn` first.\n\n### Known fingerprint budget\n\nTarget: specific expensive query fingerprint.\n\nIntent: contain a known pathological query while code or schema fixes are developed.\n\nMode: `warn` first unless emergency.\n\n## “Each tag value” strategy\n\nWhen PlanetScale supports applying a budget separately for each unique value of a selected tag, recommend it for bounded tags such as:\n\n- `application`\n- `service`\n- `route` when normalized\n- `job`\n- `feature`\n- `source`\n\nDo not recommend it for unbounded tags such as user IDs, request IDs, raw tenant IDs, emails, UUIDs, or raw URLs.\n\n## Limits and caveats to include\n\nEvery recommendation must explain:\n\n- Traffic Control limits resource use; it does not replace query tuning.\n- It is not a web application firewall.\n- It does not replace application-level rate limits.\n- Limits are guardrails, not exact guarantees for every failure mode.\n- Bad tags create bad rules.\n- Enforce mode can reject queries and affect application behavior.\n\n## Output format\n\nFor each proposed budget:\n\n- Budget name.\n- Target branch.\n- Mode: off, warn, or enforce.\n- Matched traffic slice.\n- Rule type: tag, fingerprint, keyspace, query kind.\n- Proposed tags or fingerprint.\n- Limit rationale.\n- Queries seen in Insights that justify it.\n- Safety risk.\n- Test/observe plan.\n- Rollback plan.\n- Approval requirement.\n\nEnd with:\n\n“No Traffic Control budgets or rules have been created, updated, deleted, or enforced.”\n"
}