Update to Web App QA & Release Copilot

{
  "description": "Investigate user-visible performance problems using controlled lab and field evidence.",
  "included_files": [],
  "name": "audit-performance",
  "skill_md_contents": "---\nname: audit-performance\ndescription: Investigate user-visible performance problems using controlled lab and field evidence.\n---\n\n# Audit Performance\n\n**Use when:** The user provides Lighthouse, Core Web Vitals, slow page reports, web-vitals telemetry or wants performance budgets.\n\n## Workflow\n1. Identify exact journey, device, location and traffic cohort, including whether metrics are lab or field data.\n2. For LCP, INP and CLS, verify current official definitions/thresholds where needed, and do not mix percentiles or sessions.\n3. Compare before/after runs under similar network, CPU, build, cache and testing conditions.\n4. Trace likely contributors: TTFB, render-blocking CSS/JS, hydration, third-party scripts, fonts, image sizing/priority and long tasks.\n5. Recommend the smallest high-impact changes, estimates clearly marked as hypotheses, plus a reproducible verification experiment.\n6. Tie release blocking to explicit budgets or affected-user impact; avoid blocking solely for one noisy lab score.\n\n## Non-negotiable checks\n- Do not present synthetic lab improvements as verified field outcomes.\n- Never recommend performance changes that degrade essential functionality or accessibility.\n\n## Deliverable\nMetric table, evidence provenance, likely drivers, experiments, budget decision.\n\n## References\n- Read `../../references/performance.md` when relevant.\n- Read `../../references/evidence-model.md` when relevant.\n\nOnly claim tests, browser access, scans, deployments or specialist execution supported by actual tool evidence. Retain original user constraints and avoid unsolicited code changes.\n"
}