| name | miniapp-performance-ux-guard |
| id | miniapp-performance-ux-guard |
| description | Reviews and improves Tuya 小程序/miniapp/Ray quality in one package: build guardrails, launch/first-screen performance, release review gates, and design-to-code/component architecture. Use when implementing or modifying pages/components/forms/lists/dialogs/async flows; fixing bugs, UI, interaction, loading/error/empty states, or i18n copy; optimizing 启动性能、首屏、白屏、FMP、包体积、分包、预加载、骨架屏、数据预取、缓存、CDN、Smart UI 按需加载、Ray 通信、react-dom、内存缓存; doing review、上线前检查、准入、release gate、quality grade、召回、体验度量、埋点闭环、告警阈值; or working from MasterGo、设计稿、UI还原、组件拆分、Smart UI、Dialog、Overlay、ActionSheet、弹窗、抽屉、底部面板. |
Miniapp Performance UX Guard
概述 {#description}
本技能服务于涂鸦 Ray/miniapp 项目代码下限、项目性能、体验与发布质量治理，覆盖日常功能开发护栏、启动/首屏优化、上线前评审门禁、以及 MasterGo 设计稿还原与组件架构设计四类高频任务。它的价值不只是“多一份规则”，而是把 AI 锁回项目真实约束里：优先沿现有项目模式改代码，先补下限，再做性能、评审和设计落地，避免 AI 在上下文不足时凭空发明组件、状态流、接口能力或不适配小程序/Ray 的泛化方案。
快速上手 {#quick-start}
- 接手 AI 写的代码：可以直接说“别重构大架构，先按我项目现有模式补齐 loading、失败反馈、防重复提交和 i18n”。
- 需求描述模糊：可以直接说“先帮我收敛方向，哪些复用现有组件，哪些地方真的需要新写，不要先脑补一套实现”。
- 设计稿落地：可以直接说“按设计稿还原，但优先复用 Smart UI 和项目已有组件，不要新造一套组件体系”。
- 首页变慢或体验差：可以直接说“先告诉我最值得动的 3-5 个点，按收益排序，不要给一堆泛泛建议”。
- 准备上线：可以直接说“先把阻断发布的问题挑出来，再告诉我能不能发版”。
- 上下文不完整：可以直接说“如果证据不够，先列假设和缺口，不要编造接口、埋点或性能数据”。
适用场景 {#scene}
- 守住代码下限：接手 AI 或新同学写的页面 / 组件 / 表单 / 列表 / 弹窗 / 异步链路时，优先补齐 loading / error / empty / disabled、防重复提交、i18n、埋点和验证证据，避免只修 happy path。
- 减少 AI 幻觉：当需求只有一句话、只有截图、或者上下文缺失时，要求 AI 先对齐项目现有组件、请求封装、状态流和埋点口径，再动手实现；确认不了的地方显式写假设与缺口，不编造 API、组件能力或性能结论。
- 明确 AI 方向：当你不希望 AI 一上来就大改架构、乱拆目录、乱造 hooks/store/工具层时，用本技能把它收回到“沿现有模式增量修改、优先复用、最小可验证落地”的轨道上。
- 启动与首屏优化：排查白屏、首屏慢、主包超限、分包、预加载、数据预取、缓存、CDN、Smart UI 按需加载、Ray 通信、同步 API 阻塞、误引
react-dom 等问题时，优先给出最有收益、最适合 Tuya miniapp / Ray 约束的优化顺序，而不是泛化建议。
- 评审与发布门禁：做代码 review、上线前检查、准入 / 召回、体验度量、告警阈值、埋点闭环、Release Gate、Quality Grade 时，先给阻断问题，再给结论与验证缺口，避免“看起来很全但没有放行判断”的空泛评审。
- 设计还原与组件架构：根据 MasterGo / 设计稿还原页面，做 Smart UI 映射、组件拆分、弹窗 / 抽屉 / 底部面板方案，优先复用现有组件、样式变量和页面结构，不轻易新造一层 UI 体系。
- 组合任务：既有设计还原又要落代码，再兼顾首屏或发布质量时，按设计、开发、性能、评审的顺序逐步收口，避免 AI 并行乱跳或一步到位大重构。
搭配使用 {#usage}
- 目录结构：本 Skill 位于
skills/miniapp-performance-ux-guard/，目录内直接包含 4 个内部 workflow：build-guard.md、launch-performance.md、review-gate.md、design-component.md，以及共用的 rules/、templates/、references/、anti-patterns.md、rubric.md、examples.md。
- 安装与调用：安装
miniapp-performance-ux-guard 一个 Skill 即可，不要求再安装拆分版独立 Skill；触发后先做场景路由，再进入对应 workflow，不要在总控层直接展开完整审查。
- 前置依赖：目标最好是可读取源码的 Tuya miniapp / Ray 项目；若当前上下文缺少仓库代码、设计稿、构建脚本、性能数据或截图证据，只输出可验证假设与缺口，不伪造结论。
- 资料读取策略：
anti-patterns.md 永远优先；其余资料按任务读取。日常开发优先 templates/ + 对应规则，启动优化优先 references/wiki-optimizations.md，设计还原优先 references/smart-ui-mapping.md / references/component-architecture.md / references/app-css-variables.md，发布评审优先 rubric.md / templates/pre-release-checklist.md / 对应 rules/<rule-id>.md。
- 验证方式：优先运行项目已有的最小范围 lint / build / test；UI 自证默认走
references/miniapp-devtools-feedback.md 的 Manual 路径，当前环境存在 DevTools MCP 时再追加自动化截图、快照和日志采集。
注意事项 {#tip}
- 这个 Skill 最适合在能看到源码的 Tuya miniapp / Ray 项目里使用；如果你还能提供报错、截图、录屏、设计稿、日志或性能数据，建议会更准。
- 如果你只想做最小修改，可以直接说“不要大重构”“不要改目录结构”“优先复用现有组件 / 工具 / 样式变量”，Skill 会按这个边界收口。
- 如果你是接手 AI 生成的代码，也可以直接说明“先按项目现有模式收口”，Skill 会优先补代码下限，而不是先发明新架构、新 hooks 或新状态流。
- 如果上下文还不完整，Skill 会先列出假设、缺口和下一步最需要补的证据；这时继续补代码片段、交互路径或性能数据，比让 AI 硬猜更有效。
- 这个 Skill 默认按 Tuya 小程序 / Ray 的约束给建议；如果你的问题其实是后端、固件、IoT 平台配置或非小程序项目，请直接说明，避免方向跑偏。
- 示例和代码默认优先使用 Ray 小程序写法；如果你更希望看到原生小程序、TSX 或项目里已有的特定写法，可以直接点明。
路由原则
先判断用户意图，再读取最窄的内部 workflow。不要在总控里执行完整评审或读取全部规则。
Routing Matrix
| Intent | Read | First action |
|---|
| 写功能、修 bug、补交互、改页面/组件 | build-guard.md | 输出 Build Guardrails |
| 启动慢、首屏慢、白屏、FMP、包体、分包、预加载、缓存 | launch-performance.md | 对照 Wiki 19 项基线 |
| review、上线前检查、准入、召回、体验度量、发布门禁 | review-gate.md | 先查 anti-patterns 和 Gate |
| MasterGo、设计稿还原、Smart UI、组件拆分、弹窗/抽屉/底部面板 | design-component.md | 先做组件映射/拆分方案 |
| 多个意图同时出现 | 对应多个 workflow | 按 Design → Build → Launch → Review 顺序执行 |
默认策略：
- 普通开发优先
build-guard.md，不要直接进入 Deep Review。
- 明确提到启动/首屏/包体时追加
launch-performance.md。
- 明确提到 review/上线/准入时使用
review-gate.md。
- 明确提到设计稿/组件架构时先使用
design-component.md。
- 这些 workflow 都随
miniapp-performance-ux-guard 一起发布和安装，不依赖同级独立 Skill。
Internal Workflows
build-guard.md：日常开发、修 bug、交互反馈、异步状态、i18n、验证护栏launch-performance.md：启动、首屏、包体、预加载、缓存、骨架屏、Ray 通信优化review-gate.md：代码 review、上线前检查、Release Gate、Quality Grade、验证缺口design-component.md：设计稿还原、Smart UI 复用、组件拆分、弹窗/抽屉/底部面板
Shared References
内部 workflow 按需读取，避免一次性全部加载：
anti-patterns.md：最高优先级反模式清单rules/：62 条离散规则templates/：异步状态机、请求包装器、埋点、反馈归因、发布检查清单references/miniapp-best-practices.md：小程序开发最佳实践和体验评分基础检查references/developer-quality-contract.md：开发者高质量代码契约references/wiki-optimizations.md：Tuya Wiki 启动性能 19 项基线和公共资源缓存补充references/smart-ui-mapping.md：Smart UI 映射references/component-architecture.md：组件拆分策略references/app-css-variables.md：框架内置 --app-* 设计 Token 反查表（颜色/字号/间距/圆角，UI 还原时反查 rgba/字面量）references/miniapp-devtools-feedback.md：UI 自检反馈流程（默认 Manual：用户截图贴回；可选 Automated：环境有 DevTools MCP 时自动化）rubric.md：Release Gate + Quality Gradeexamples.md：评审与输出样例
Shared Quality Rules
- 先匹配场景，再读取对应规则；避免全量读规则造成噪音。
anti-patterns.md 优先级最高，命中即标记。- Build 阶段关注“下限保障”，Review/Release 阶段关注“风险阻断”。
- 开发型任务默认遵循
references/developer-quality-contract.md。
- 建议必须可执行、可定位、可验证。
- 不为了追求“看起来快”破坏正确性。
- 不引入与需求无关的大型重构。
- Bad/Good 示例默认优先使用 Ray 小程序写法；确需展示原生模板语法时补充 Ray/TSX 等价示例。
- 安装者只需要安装本 Skill；不要要求用户额外安装
miniapp-build-guard、miniapp-launch-performance、miniapp-review-gate 或 miniapp-design-component。
Output
只负责路由时输出：
## Skill Routing
- Build guardrails: `build-guard.md`
- Launch performance: `launch-performance.md`
- Review gate: skipped
- Design/component: skipped
随后按选中的内部 workflow 执行。
