Communitygithub.com

wasely/ui-max

设计、改进、清理或实现精致的生产级界面,实现连贯的组件选择、无障碍性、响应式行为、可维护的设计令牌、克制动效以及完整的 UI 状态。适用于仪表盘、SaaS 产品、浏览器扩展、AI 工具、管理面板、设置、表单、表格、营销页面、组件库、UI 审计以及前端重构,在 Codex 中选择最精简的 UI 技术栈并提供可运行的代码。

ui-max 是什么?

UI Max 是一项专注于生产级界面开发的 AI 技能,旨在帮助开发者打造高质量、易用且可维护的用户界面。其核心理念是优先考虑产品的实用性,而非装饰性效果,并提倡选择最简单但连贯的 UI 系统来满足需求。该技能全面覆盖了从需求分析、技术栈选择、组件实现、状态覆盖到最终验证的完整工作流。它明确推荐在 React + TypeScript + Tailwind CSS 项目中默认使用 shadcn/ui 和 Radix UI,并针对 AI 产品、营销页面、数据密集型应用等不同场景提供了差异化的组件库选择建议。通过强调组件复用、设计令牌统一、语义化颜色、无障碍访问和响应式设计,UI Max 确保输出的代码不仅界面美观,更具备坚实的工程基础和高可维护性。

兼容平台~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/wasely/skills/tree/HEAD/ui-max

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

UI Max

优先考虑产品的可用性,而非装饰性效果。选择满足需求的最简连贯系统;不要无谓地累积组件库。

从产品出发

在修改代码之前:

  1. 检查框架、路由、CSS 系统、组件库、图标和动画库、表单技术栈、设计令牌、深色模式以及既定模式。
  2. 定义用户目标、主要工作流、信息层级、主要和次要操作、所需状态、响应式界面以及键盘行为。
  3. 按以下顺序复用:本地组件、现有设计系统原语、shadcn/ui、Radix UI、21st.dev、专用增强库、自定义实现。
  4. 保持现有的稳定 UI 系统。切勿为了一个吸引人的组件而引入一个竞争性的全套系统。

选择一个基础

对于新的 React 产品界面,默认为:

React + TypeScript + Tailwind CSS
shadcn/ui -> Radix UI 原语
Lucide 图标
仅在需要时使用 Motion for React
对于复杂表单使用 React Hook Form + Zod
仅针对高级表格行为使用 TanStack Table

不要将此技术栈强加给已有既定系统的项目或 Vue/Svelte 项目。在这些项目中使用生态系统原生的库。

在选择添加内容之前,先对界面进行分类:

  • 核心产品 UI:shadcn/ui + Radix UI + Tailwind CSS。
  • AI 产品 UI:仅针对真实的 AI 工作流模式添加 Cult UI;使用 Motion Primitives 实现克制的过渡效果。
  • 营销页面:使用 21st.dev 构建结构,选择性地使用 Magic UI,仅对真正高影响力的部分使用 Aceternity。
  • 数据密集型应用:当排序、过滤、分页、选择、可见性、虚拟化或复杂数据模型需要时,添加 TanStack Table。
  • 微交互:使用 Motion Primitives 或 Motion。仅在对无障碍性和可维护性进行审查后使用 UIverse。

在选择、安装或引入库/组件、比较替代方案或研究视觉模式时,请阅读 references/component-selection.md。

一致地实现

将所有复用或复制而来的组件规范化为项目的:

  • 语义化颜色令牌
  • 排版、间距、圆角和阴影比例
  • 图标族
  • 无障碍性约定
  • 响应式行为
  • 亮色和深色主题

使用语义化令牌,而不是分散的硬编码值。保持相关控件靠近;分隔不相关的部分;避免无根据的嵌套卡片;使用列表/表格进行比较,卡片用于单独可操作的异构项目。保持主要操作显而易见,并将破坏性操作远离常规操作。

除非品牌要求,仅使用一种界面字体和一种图标族。仅在使用动效来传达状态、层级结构、连续性、因果、进度或焦点时使用动效。尊重 prefers-reduced-motion。

在进行实质性的视觉实现、响应式工作、状态设计、表单、表格或无障碍工作之前,请阅读 references/design-standards.md。

覆盖真实状态

对于异步或数据驱动的 UI,请考虑:

  • 初始加载和后台刷新
  • 空结果和无搜索匹配
  • 成功、警告、错误和部分失败
  • 禁用和离线状态
  • 缺少权限或集成
  • 过期数据

当结构已知时,优先使用骨架屏。错误信息需说明:什么失败了,已知原因是什么,工作是否被保留,以及如何解决。切勿在成品中使用无意义的模拟数据、伪造的分析数据、虚构的代理活动或非功能性控件。

清理现有 UI

审查重复、间距、颜色、排版、变体、图标、嵌套布局、重复的工具类、响应性、无障碍性、未使用的代码/依赖项、动画过载以及缺失的状态。

整合重复的或承载行为的原语,例如按钮、输入框、状态徽章、对话框、菜单、标签页、页面头部、空/错误/加载状态、侧边栏项和项目行。不要在缺乏一致性、逻辑、复用或测试收益的情况下抽象一次性标记。

将重复值令牌化。移除不必要的包装器、嵌套卡片、装饰性分隔线、重复标签、冗余操作/状态、过多的说明以及不合理的动效。

验证渲染输出

验证:

  • 语义化 HTML、无障碍名称、标签、逻辑 tab 顺序、键盘操作、对话框焦点、可见焦点和对比度
  • 加载、空、禁用、错误、成功、长文本和破坏性确认状态
  • 窄布局和宽布局,无内容截断、表格不可读、布局偏移或水平溢出
  • reduced-motion 行为、浅色/深色主题和响应式导航
  • 格式化工具、lint、TypeScript、测试、生产构建和控制台输出

在涉及 320、375、768、1024、1280 和 1440 px 时进行测试。对于浏览器扩展,还需要测试约 320-420 px 的弹出窗口宽度和约 320-600 px 的侧面板。

在声称完成之前,务必检查窄宽度和宽宽度下实际渲染的 UI。使用截图循环或项目现有的视觉验证工作流;在真实目标上确认特定于平台的界面。

报告 UI 工作

当被要求设计或重建一个页面时,提供以下各部分:

  1. 产品解读:目标、主要工作流、关键信息、主要操作。
  2. 组件计划:结构、可复用组件、基础、专用补充、响应式行为、重要状态。
  3. 实现:在现有技术栈中的可运行代码。
  4. 验证:无障碍性、响应性、状态、键盘行为、设计令牌一致性以及渲染后的视觉检查。

除非用户询问选项,否则不要返回一份库目录。

相关技能