用途：当用户希望审查、优化或验证已有 WordPress 站点，而非主要开发新功能时使用。该技能负责基于 Studio MCP 工具的性能审计、颜色与对比度及动效可读性的无障碍审查、用户要求质检或打磨时的可见前端质量审查，以及修复前后的对比审计。
使用原则：从能回答用户请求的最小审计范围开始。若关注速度、Core Web Vitals 或性能，优先性能流程；若关注无障碍、对比度、可读性或颜色，优先无障碍流程；若要求通用审查，则合并相关部分并保持报告实用。不得编造工具不提供的自动检查，若结论来自目视检查或代码阅读须说明。
流程：1) 用 studio 解析目标站点，确认站点运行并确认要审查的页面或 URL 路径，未指定页面则默认为 /。2) 选择审计范围：性能审计、无障碍审查、视觉质检；范围不明显时告知用户所用范围。开始实际审计后调用 record_workflow_event，workflow 为 "auditing"，stage 为 "started"。3) 性能审计：对指定路径使用 need_for_speed，至少解读 TTFB、FCP、LCP、CLS、页面总重量、请求数、DOM 大小及 JS、CSS、图片、字体构成。基线阈值：TTFB 良好 <800ms、需改进 800-1800ms、差 >1800ms；FCP <1800ms、1800-3000ms、>3000ms；LCP <2500ms、2500-4000ms、>4000ms；CLS <0.1、0.1-0.25、>0.25。页面构成警示：DOM 元素超过 1500、页面总重超过 3MB、请求数超过 80、脚本超过 20 个或总计 500KB、样式表超过 10 个或 200KB。尽可能转化为 WordPress 具体措施，如减少或替换重型插件、延迟或移除非关键 JS、压缩过大图片、精简未用主题 CSS、检查重复字体加载、简化包裹层过多的区块布局。4) 无障碍审查：使用 take_screenshot 并结合主题或插件代码检查，聚焦对比度低、CTA 对比弱或按钮状态含糊、缺少或不清的悬停与焦点状态、应尊重 prefers-reduced-motion 的动效、字号行高或密集布局导致的可读性问题、颜色令重要信息难以区分。视觉问题时优先用截图佐证；渲染 DOM 或计算样式能更快定位根因时用 inspect_design；结构问题时先检查相关主题或插件文件再建议修复。5) 视觉质检：用 take_screenshot 检查间距与对齐、响应式布局、视觉层次、组件样式一致性、裁剪或媒体平衡，聚焦实质影响站点的可见问题。6) 报告：总结审计内容、最重要发现、可能原因和最高价值后续修复，优先简短分级报告而非冗长清单。7) 变更后重测：若同一任务中完成修复，重跑相关审计并对比前后，说明哪些改善、哪些未改善及遗留取舍。完成时调用 record_workflow_event，workflow 为 "auditing"，stage 为 "completed"。
限制：need_for_speed 结果来自本地 Studio 环境的合成测量，主要用于诊断和前后对比，不代表生产真相；无障碍观察常基于视觉审查与代码检查，而非专用自动无障碍扫描器；当性能、无障碍与设计问题冲突时，应说明取舍，而非静默过度优化某一维度。