用途：在编写或审查 Tailwind CSS 代码时，应用一组检查规则，让 utility-first 代码库随规模增长仍保持可读与可维护。
前置条件：需先确认两点——存在带令牌的设计系统（颜色、间距、字体层级统一定义并复用），以及采用组件化方式（重复类名可抽取为组件）。若确认缺失，应指出并停止；若上下文不足（如只看单个文件），先查找配置或主题文件，不要因此阻塞任务，可继续并标注假设。
主要能力与用法：
- 精简冗余类名，如 pt-4 pb-4 改为 py-4，flex flex-row 改为 flex，border-opacity-50 改为 border-black/50。仅在编写新类或被要求清理时应用，不顺手重写无关代码。
- 按类别分组设计令牌并按语义命名（如 error 而非 bright-red），标记未使用令牌，但需先排查动态用法（如 bg-${color}-500、cva 或 tailwind-variants 配置）再判断。
- 保持类名顺序一致：优先匹配已有 Prettier Tailwind 插件配置，否则用插件默认顺序（base、components、utilities 层依次排序），并建议团队安装该插件。
- 避免用 @apply 抽取重复样式，改用真实组件；已有大量 @apply 的代码库标记为债务，下次改动时转换，不做大规模重写。
- 设计系统组件（按钮、徽章、输入框等）不应通过 props 接受任意类名，改用固定 variant 映射；若团队不接受，tailwind-merge 可作为运行时冲突解决的备选，但会增加包体积，不建议默认使用。一次性组件允许开放 className。
反模式：存在令牌系统时仍用魔法值（如 p-[123px]）；临时添加一次性令牌（15px、16px、17px），应标记并询问是否转为令牌，而非直接拒绝；以“更整洁”为由推广 @apply 密集样式表；跳过生产 CSS 压缩——v4 自动压缩（基于 Lightning CSS），v3 需确认构建是否启用压缩（CLI 的 --minify 或 PostCSS 的 cssnano），若无法看到版本则不要提及。
限制：资料未提供安装命令、价格、平台支持等具体信息。