Use this skill when working on frontend views, page interaction, component selection, mobile UX improvements, or productizing rough/demo-like UI. Prefer mature Ant Design / Ant Design Mobile components where appropriate. When the task touches UI, proactively review the current interaction, optimize it if needed, and use screenshots or Playwright screenshots for UI review when available. If visual judgment is subjective, reference mature open-source projects or mainstream mobile app patterns instead of inventing unusual interactions.
当任务涉及前端视图、页面布局、组件结构、交互流程、样式表现时使用：
如果任务已经明确是移动端 H5 页面产品化，先联动 badminton-h5-product-ui；本 skill 负责在那个基础上进一步做交互体检、组件选型校正、截图 review 和自评闭环。
这个仓库的前端不是通用 Web 后台，而是移动端 H5 训练产品：
React 19 + Vite + react-router-domfrontend/src/app/ 与 frontend/src/features/*.module.scss，共享 token 在 frontend/src/styles/tokens.scss，全局基础样式在 frontend/src/styles/globals.scssMobileAppShell、PageLayout.module.scssBottomCTA、Notice、、、EmptyStateStatusPillStepProgressantd-mobile 已经被选择性接入，当前用于 Selector、Popup 这类移动端交互原件；品牌视觉、Hero、报告卡片和训练叙事仍然以仓库自研组件为主当前前端的典型风险不是“完全没 UI”，而是：
开始改 UI 前，优先读真实真源而不是凭印象设计：
frontend/README.mddocs/design/INTERACTION-DESIGN.mddocs/design/WIREFRAMES.mddocs/design/UI-DESIGN-SYSTEM.mdfrontend/src/features/*Page.tsxfrontend/src/components/ui/如果任务带截图、Playwright 截图、视觉快照，也把它们当成一等输入，不要只读代码。
只要任务涉及视图、页面、组件、交互、样式，不要只按用户点名的那一小块机械修改。
先判断当前交互是否存在以下明显问题：
如果发现当前交互明显不合理，应把必要的顺手优化一起做掉，而不是只改用户提到的单点。
在涉及前端视图时，优先考虑 Ant Design 或 Ant Design Mobile 的成熟交互原件，以及仓库里已有的稳定 UI 组件。
优先考虑这些成熟组件是否更合适：
ButtonCardListTabsModalPopupDialogFormPickerProgressResultEmptySkeletonToastTagStepsCollapseUploader同时优先复用仓库自带模式：
BottomCTANoticeEmptyStateStatusPillStepProgress不要为了“特别”而手搓复杂但体验差的控件。组件选型必须解释“为什么它更贴合当前任务心智”，而不是盲目堆组件。
这个仓库是移动端 H5，不是桌面后台。
默认遵循：
每个页面都必须让用户知道：
因此要明确：
避免：
先判断用户任务，再选组件，不要先有组件后找场景。
常见判断方式：
Uploader、清晰的就绪检查卡、底部 CTA，而不是自造复杂上传控件Result 风格总结，而不是把全部字段平铺不要使用少见、奇怪、需要学习成本的交互模式。
每个关键页面和组件都要检查：
emptyloadingsuccesserror失败态必须给下一步动作，不能只有报错文字。默认不允许只实现 happy path。
文案要简洁、清晰、可操作。
要求：
如果任务可以获取页面截图、Playwright 截图、视觉快照，则优先结合截图进行 review，而不是只看代码逻辑。
review 时不要只检查“功能通不通”，还要逐项看：
如果从截图中发现明显问题，应继续修正 UI，而不是直接结束任务。
重点额外检查这些高频问题：
默认闭环：
当任务明确涉及截图验证或页面 review 时，联动 badminton-playwright-mobile-qa 获取稳定的页面验证与截图承接。
当页面是否“好看”或“合理”带有主观性时，不要凭空臆想，也不要发明少见交互。
优先参考：
重点学习：
不要求抄视觉风格，但要借鉴成熟交互范式。
如果采用了参考模式，最终总结时要说明：
每次涉及 UI / 视图 / 样式 / 交互的改动后，不能直接结束，必须做一轮“UI 交互自评”。
自评必须使用结构化 rubric，而不是一句“看起来不错”：
loading / empty / error / success 是否完整输出前至少明确：
如果 rubric 发现明显问题，先修正一轮，再输出结果。
position: sticky + 长文档流的假固定导航；先验证滚动到底发生在 window 还是内容容器。前端交互改动默认遵循：
Ant Design / Ant Design Mobile 组件，要注意封装边界和整体风格统一遇到这个仓库里的大页面，尤其要警惕继续向单文件堆 JSX、状态推导和文案分支；优先抽 section component、helper、adapter 或 flow-specific 子组件。
badminton-h5-product-ui：负责移动端 H5 页面产品化、页面目标、主 CTA、版式和已有页面模式；本 skill 在其基础上补充交互诊断、截图 review、自评闭环和组件选型质量badminton-analysis-flow：当任务涉及前端异步流程状态机、上传粗扫、片段确认、处理中状态流转时联动badminton-playwright-mobile-qa：当任务涉及 Playwright 页面验证、视觉快照、截图复核或需要稳定 UI 验证时联动docs-spec-sync：当页面结构、交互规则、状态口径变化需要同步 docs/ 或 spec/ 时联动本 skill 重点解决的是：
根据任务类型按需读取：
examples/page-structure-refactor.md：页面像 demo、结构拥挤、CTA 不清晰时examples/ant-component-selection.md：需要判断是否引入 Ant / Ant Mobile 组件，以及怎么选时examples/screenshot-review-and-polish.md：拿得到截图、需要做 review 闭环时examples/mobile-interaction-self-review.md：实现完页面后要做结构化自评时examples/open-source-ui-reference.md：交互判断主观性较强、需要参考成熟模式时最终交付说明至少要写清：