用途：对代码库进行全面的手动性能审计，产出按优先级排序、有证据支撑的结论（带文件与行号引用），而非泛泛建议。除非用户明确要求修复，否则使用评审模式，默认输出审计报告而不是代码改动。
规则：必须手动审计，不创建或运行声称可自动检测性能问题的自定义扫描脚本；可用 rg、rg --files、git、包元数据、现有测试、现有性能分析工具与普通文件读取收集上下文。搜索结果只视为线索，需先读周边代码再下结论；以证据优先，关注调用路径、数据量、频率、阻塞行为、渲染范围、查询形态、缓存行为或缺失限制。未实测就不要说实测结论，应表述为“风险”或“可能”，并说明静态证据。审计期间保留用户改动，除非被要求否则不编辑代码。广泛审计或分配子智能体前，先读 references/manual-flags.md 获取完整标记清单。
工作流：1) 梳理系统——检查仓库结构、清单文件、构建配置、运行入口、路由、API 边界、数据访问层、数据库迁移/模式、队列、Worker、缓存与可观测性；识别关键路径（首次加载、常用导航、热点列表/详情、写入、搜索过滤、后台任务、实时同步、看板图表页、导入导出、高流量端点），并说明跳过了哪些无关领域。2) 并行探索——使用 multi_tool_use.parallel 执行独立的读取与搜索；若有需要，可把机械性探索交给快速子智能体、把系统性推理交给更强子智能体，并要求返回文件、行号、片段与“值得人工复核的原因”，不得做最终断言；所有子智能体结论须自行核实后再报告。3) 按领域人工审查——从用户操作或任务触发追踪到昂贵工作，评估运行频率、可触及数据量、是否阻塞用户路径、是否随租户/用户/列表规模增长、是否触发下游工作；宁可少而高置信，不要多而未经证实。4) 优先级：P0 可能拖垮生产、造成失控成本或在真实规模下阻塞核心流程；P1 核心路径上用户可见的缓慢或严重扩展风险；P2 常见路径上明显低效、卡顿、内存增长或可避免工作；P3 局部优化或护栏，有用但不紧急。5) 先报告发现——按严重度排序，每条包含严重度、标题、文件/行、证据、影响、修复方向与验证方法；其后列出未决问题或假设，再提及已审计但无重大问题区域；若无严重问题，需明确说明并列出残余风险或未测量路径。
适用场景与限制：适合大型、多语言或包含多个独立性能面的仓库，用于前端渲染、数据库与 API 访问、构建与首屏加载等审计；依赖人工阅读与既有工具，不能自动保证发现全部问题，未实测项只能标为风险。手动搜索起点可关注依赖与构建面（package.json、锁文件、打包配置、路由清单、服务端入口）、前端渲染面（useEffect、useMemo、useCallback、memo、observer、Context.Provider、选择器、列表渲染、表格/网格组件）、网络面（fetch、axios、graphql、trpc、useQuery、mutate、轮询间隔、订阅、WebSocket 客户端）、后端面、数据库面、主线程与内存面、UI 卡顿面。示例委派：使用 $performance-audit 检查前端渲染与状态更新路径并返回候选风险，不编辑文件。其他平台、收费与版本等信息暂未提供。