用途：当用户要求检查性能、审计速度或分析 Web Vitals 时，按 Core Web Vitals（LCP、INP、CLS）、打包体积与 API 延迟生成性能预算审计，定义阈值、找出违规项并给出图片优化、代码分割、懒加载、缓存改进等建议。
主要能力：先扫描 .chalk/docs/engineering/ 下的架构文档、既有性能预算与基础设施配置，并检查代码库的构建配置（webpack、vite、next.config）与现有性能工具；从 $ARGUMENTS 解析审计目标（页面、功能或端点），未指定时审计最关键的用户页面（通常是落地页或主仪表板）；读取已有文件名最大编号，新建编号为最大+1。
阈值标准：LCP 良好 <2.5s、需改进 2.5-4.0s、差 >4.0s；INP 良好 <200ms、需改进 200-500ms、差 >500ms；CLS 良好 <0.1、需改进 0.1-0.25、差 >0.25；JS 打包体积良好 <200KB gzipped、需改进 200-350KB、差 >350KB；API 延迟 p95 良好 <300ms、需改进 300-1000ms、差 >1000ms。若文档已有预算则沿用。
分析范围：打包（大依赖、tree-shaking 缺口、缺少代码分割）、图片（格式未优化、缺少懒加载、无响应式尺寸）、渲染（动态内容导致布局偏移、阻塞渲染资源）、数据请求（瀑布式请求、缺缓存、过度获取）、API（慢查询、缺索引、N+1 问题）。每项超限或存在风险需记录当前值、阈值、根因与修复建议，并按影响与工作量排序，优先快速见效项。
输出与限制：结果保存为 .chalk/docs/engineering/<n>_performance_audit.md，纯 Markdown，含预算表、违规清单与优先级建议，首行为 # Performance Audit: <Target>；完成后分享路径并突出影响最大的三项修复。应避免无预算审计、只看实验室数据（需注明并建议现场监控）、无优先级建议、忽略打包构成和 API 延迟。资料未提供具体安装命令、收费信息与运行环境要求。