ZUI 库优化

确定范围与模式

1. 定位同时包含 AGENTS.md、pnpm-workspace.yaml 和 lib/ 的仓库根目录。
2. 完整读取根目录 AGENTS.md、../zui-standards/references/workflow.md 和 references/audit.md。
3. 将用户范围解析为：
   • 单库：一个 lib/<name> 或 @zui/<name>；
   • 多库：明确名称列表；
   • 全库：当前 lib/*/package.json 实际发现的全部内置库。不要沿用硬编码数量；exts/ 仅在用户明确纳入时处理。
4. 检查 git status，记录用户已有改动和可用验证基线。明确“全库”默认在只读盘点中包含 WIP/notReady 内置库并单独标记；是否实施这些库的优化由批准范围决定。目标名称或是否包含扩展库仍不明确时，先提出最少必要问题。
5. 区分请求模式：
   • 只要求审计、检查或报告时保持只读，输出发现和修复建议；
   • 要求优化、完善或修复时，先只读审计，再进入统一计划确认门禁。
6. 确认前只运行不会写入仓库、生成目录或缓存的检查。不要运行 pnpm build、文档同步、开发服务器、lint --fix 或其他会刷新 build/、dist/、docs/_、cache 的命令；把它们列入批准后的验证。用户明确要求带构建验证的只读审计时，优先使用仓库外临时输出，否则先说明副作用并取得许可。

盘点与审计

1. 运行 ../zui-standards/scripts/inspect-zui-lib.mjs 盘点全部或指定目标。多库可逐库使用 --lib；脚本信号不能代替源码判断。
2. 对单库或当前待计划批次中的每个目标，读取 package.json、入口、公开类型、实现、样式、i18n、正式文档、README.md 和 dev.ts；选择两个与其包角色、实现架构或消费方式最相近的成熟库。
3. 大范围任务先依据全体 package 元数据、盘点信号、依赖和现有验证状态做浅层分组，再深读本批目标。浅层盘点不能宣称已确认源码缺陷；不要在尚未形成整体优先级时随机修改第一个库。
4. 按发现类型完整读取并遵循对应兄弟技能：
   • 规范与包角色：../zui-standards/SKILL.md
   • UI 组件实现：../zui-component/SKILL.md
   • helper/store/utils：../zui-helper/SKILL.md
   • 正式文档：../zui-doc/SKILL.md
   • 调试页：../zui-dev/SKILL.md
   • 国际化：../zui-i18n/SKILL.md
   • 单库跨领域或 package 契约：../zui-lib/SKILL.md
5. 按 audit reference 检查代码质量、缺陷、公开 API 文档、调试示例、i18n 和规范一致性。每项发现都记录证据、影响、置信状态、严重度、建议处理和负责技能。
6. 不把风格偏好包装成缺陷。无法从源码、复现或构建结果确认的问题标为风险并制定验证/修复计划，不进行猜测性修复。

统一确认门禁

任何文件修改或生成产物前，输出决策完整的优化计划，至少包含：

• 目标库清单、范围排除项、工作区基线和相似库；
• 按库列出的已确认缺陷、风险、文档/示例/i18n/规范缺口及优先级；
• 每项优化的目标、非目标、公开 API/兼容性影响和验收场景；
• 选用的兄弟技能、文件边界、依赖顺序和跨库影响；
• 源码 JSDoc、正式文档、调试页及 i18n 的纳入范围；
• 每库验证命令、基线失败、批次顺序和剩余假设；
• 明确标记的“已批准范围”，精确列出本次允许修改的库、问题和领域。

单库或少量库若能一次形成决策完整计划，只等待一次明确确认。全库或大范围默认先给出只读路线图，并提交第一个可独立验收批次的完整计划；每个后续批次在深审后再确认，除非用户已明确批准其中每项具体修改。不要让一次笼统的“优化全部”授权未知改动。

用户明确确认前停止。回答问题、调整优先级或选择批次不等于确认。用户只要求审计时不请求实施确认，也不修改文件。始终服从当前协作模式。

编排实施

1. 确认且当前模式允许编辑后，重新检查工作区，只实施已批准范围。
2. 对单库跨领域优化可调用 $zui-lib 作为该库执行器；窄领域直接调用相应技能。不要让 $zui-lib 与直接子技能重复处理同一项。
3. 将“由 zui-optimize 批准的精确范围”传给子技能；范围内跳过子技能的重复确认。目标、公开 API、兼容性、跨库影响或文件边界变化时，返回本技能重新规划。
4. 先处理共享基础和 helper，再处理依赖它们的组件，然后依次处理 i18n、正式文档和调试页。互不依赖的库按批次并行或顺序执行，但不得混淆各库验收结果。
5. 只修复证据充分且已批准的问题。实施中发现的新问题若不在范围内，记录到下一批；不要顺手扩张。
6. 保留已有库合理的局部目录与 API 风格，避免无关格式化、重命名、迁移和公共契约破坏。
7. 每完成一个库就运行针对性检查并更新进度账本；批次结束后再做组合构建、文档同步和必要的浏览器调试。

交付

• 按库汇报已修复缺陷、质量改进、API/JSDoc、正式文档、调试示例和 i18n 变化。
• 区分通过、被基线阻断、未验证和移入后续批次的事项。
• 对比优化前后的可验证行为，不用文件数量代替质量结果。
• 不编辑 docs/_，不遗留开发服务器，不自动提交、推送或发布。