Update to SQL Copilot

{
  "description": "Diagnose SQL runtime and resource cost using plans, profiles and actual workload data.",
  "included_files": [],
  "name": "sql-performance-review",
  "skill_md_contents": "---\nname: sql-performance-review\ndescription: Diagnose SQL runtime and resource cost using plans, profiles and actual workload data.\n---\n\n# Sql Performance Review\n\n**Trigger:** Diagnose SQL runtime and resource cost using plans, profiles and actual workload data.\n\n## Workflow\n1. First confirm correctness and a stable baseline: dataset size, parameters, row counts, query duration, bytes/scans, workload concurrency.\n2. Ask for or inspect plan/profile when available. Separate I/O, join fanout/shuffle, spill, sorting, skew, blocking and concurrent contention.\n3. Rank changes by likely benefit and risk: projection, early filtering when semantics allow, prune-friendly predicates, staged aggregation and access-path improvements.\n4. Avoid generic index, cluster, VACUUM, OPTIMIZE, hint, CTE or warehouse-size prescriptions without platform evidence.\n5. Compare correctness and performance after each isolated change; report observations versus hypothesized improvements.\n\n## Critical standard\nA faster query is not a win if it changes results, ignores cold/warm cache, or increases total cost.\n\n## Evidence and execution\nOnly say \"executed\", \"passed\", \"observed\", \"optimized\" or \"deployed\" when a connected tool returned evidence for that claim. An SQL draft, a textual review, or local fixture proof alone is not production validation. Never ask the user to paste passwords or raw confidential records.\n\n## Supporting references\n- Read `../../references/performance-diagnosis.md` when relevant.\n- Read `../../references/official-docs.md` when relevant.\n- Read `../../references/original/sql_performance_patterns.md` when relevant.\n\n## Return\nEvidence summary, prioritized interventions, before/after measurement plan.\n"
}