1. 什么是 Skill？为什么前端开发者尤其需要它

「Skill」是 AI 编程工具（Claude Code、Cursor、Codex 等）里的一种可复用能力包。一句话概括：它把某个领域的经验、脚本、资源和提示词打包成一个插件，装上之后，AI 在遇到对应任务时会自动“想起”怎么做，而不是每次靠你现场口述几十条规则。

对前端开发者来说，Skill 的价值尤其明显，因为前端的“隐性知识”太多了：

• 组件库的 API 千差万别（shadcn/ui、Ant Design、MUI 各有各的写法）；
• 样式规范和设计系统需要反复交代（Tailwind 主题变量、间距刻度、品牌色）；
• 工程化配置繁琐且容易出错（Vite/Next.js/TypeScript 的配置、路径别名、ESLint）；
• 浏览器调试往往要“看得见”才算数，而 AI 通常只能对着源码“盲猜”。

把这些问题各自封装成 Skill 后，你就不再是「每次开新会话都重新教一遍 AI」，而是「装上即用、随用随取」。体验上的差别，确实可以用“原地起飞”来形容。

2. 先搞清楚 Skill 的基本结构和安装位置

在正式开始清单前，先用 3 分钟把机制弄明白，后面安装时才不会一头雾水。

以 Claude Code 为例，Skill 本质上是一个目录，核心是一个 SKILL.md 文件，结构大致如下：

~/.claude/skills/tailwind-design/
├── SKILL.md
├── reference/
│   └── theme-tokens.md
└── scripts/
    └── tsconfig.alias.sh

SKILL.md 由两部分组成：

• YAML frontmatter：描述这个 Skill 的元信息，最重要的是 name 和 description。AI 靠 description 判断“什么时候该调用我”，所以描述一定要写清楚触发场景。
• 正文：给 AI 看的“操作手册”，包含流程、注意事项、可引用的资源文件路径等。

一个最小示例：

---
name: tailwind-design
description: 当用户要求使用公司设计系统编写或修改 Tailwind 样式时使用。包含品牌色、间距刻度与组件排版规范。
---

# Tailwind 设计系统 Skill

编写样式时，优先使用 `reference/theme-tokens.md` 中的设计令牌，
禁止使用任意颜色；涉及路径别名时，运行 `scripts/tsconfig.alias.sh` 生成配置。

安装方式也很直接：

# 克隆或下载社区 Skill 到本地 skills 目录
mkdir -p ~/.claude/skills
git clone <skill 仓库地址> ~/.claude/skills/tailwind-design

提示：不同工具的安装路径不同。Cursor 走 .cursor/skills 或 .cursorrules 生态，Codex 也在逐步对齐 Skills 规范。使用前先确认你所用 IDE/CLI 的官方文档，但核心心智是共通的：目录 + SKILL.md + 资源文件。

3. 前端开发必装 Skill 清单（按场景分类）

下面这份清单按“日常最高频的场景”分类。每个 Skill 我都标注了它解决的痛点，不追求“装得越多越好”，而是命中你的真实工作流。

3.1 组件与 UI 层

shadcn/ui 组件生成 Skill

• 痛点：shadcn/ui 的组件代码讲究“复制进项目后可自由改”，但 AI 经常生成与项目版本不匹配、或不经 npx shadcn add 直接乱写的代码。
• 能力：约束 AI 使用 shadcn CLI 添加组件，遵循项目现有的 components.json 配置，补全新组件时同步更新主题与依赖。
• 适合：以 shadcn/ui 为组件底座的项目。

设计系统 / 团队组件库 Skill

• 痛点：公司内部的 Button、Modal、Form 有严格的 props 约定，AI 却总爱用原生 <button> 或凭空造组件。
• 能力：把组件清单、props 说明、示例代码打包进去，AI 会优先复用已有组件而不是重复造轮子。
• 适合：有统一设计系统的团队，这可能是投入产出比最高的一个。

3.2 样式与设计规范

Tailwind CSS 主题规范 Skill

• 痛点：AI 写 Tailwind 时容易用 text-blue-500 这类任意色，破坏设计一致性；或者不遵守项目的间距刻度。
• 能力：内置品牌色、圆角、阴影、字号等设计令牌，强制从主题变量取值。
• 适合：所有重度使用 Tailwind 的项目。

CSS 变量 / 暗黑模式 Skill

• 痛点：暗黑模式要同时维护两套色值，漏改一处就出现“白天正常、夜里辣眼”的样式。
• 能力：约束 AI 只通过 CSS 变量写颜色，新增主题色时同步补全 light/dark 两套定义。

3.3 框架与工程化

Next.js 最佳实践 Skill

• 痛点：AI 容易把“客户端组件”和“服务端组件”写混，导致 useState 出现在 Server Component 里报错。
• 能力：包含 App Router 的渲染边界规则、数据获取约定、use client 的判定流程，避免低级错误。
• 适合：Next.js 项目。

TypeScript 严格模式 Skill

• 痛点：AI 写的类型要么太宽泛（到处 any），要么过度复杂（一堆不必要的泛型）。
• 能力：按项目的 tsconfig 严格度约束类型写法，统一 interface 与 type 的使用风格，补全可空值处理。

路径别名与模块解析 Skill

• 痛点：AI 有时用相对路径 ../../../../，有时用 @/，代码风格混乱，甚至引发解析失败。
• 能力：统一使用项目定义的路径别名，并在新建文件时同步更新 tsconfig.json 或 Vite 配置。

3.4 浏览器与调试

Playwright / 浏览器自动化 Skill（官方社区均有）

• 痛点：前端问题“跑起来才知道对不对”，纯靠源码推理很容易和真实渲染结果不一致。
• 能力：让 AI 主动启动浏览器、执行用户操作、截图或读取控制台错误，并据此修正代码，形成“写码 → 运行 → 观察 → 修复”的闭环。
• 适合：调试交互、表单、页面跳转、视觉还原等场景。

浏览器兼容性检查 Skill

• 痛点：AI 可能会用较新的 API（如 Array.prototype.at、structuredClone），在目标浏览器上却不被支持。
• 能力：结合项目声明的浏览器支持范围，提示或用同义方案替代不兼容的 API。

3.5 质量与可访问性

前端单测生成 Skill（Vitest / Jest + Testing Library）

• 痛点：AI 写的测试经常测了“实现细节”而不是“用户行为”，遇到重构就大面积失效。
• 能力：统一按 Testing Library 的最佳实践编写行为驱动测试，优先断言用户可见的结果。
• 适合：已经引入测试体系、希望 AI 写测试而非写 bug 的项目。

可访问性（a11y）Skill

• 痛点：AI 容易漏掉 aria-label、alt、键盘导航、焦点管理等细节。
• 能力：生成 UI 时自动检查焦点顺序、语义标签、对比度、ARIA 属性，把可访问性要求前置到开发阶段。
• 适合：对合规性有要求的产品。

3.6 数据与可视化

图表库 Skill（ECharts / Recharts / AntV 等）

• 痛点：图表配置冗长，AI 常编造不存在的 option 字段，导致渲染空白或报错。
• 能力：内置对应版本的核心 API 与常用示例，规范数据格式与配置层级，减少“幻觉式”配置。

整体组合建议：

• 中小型项目：优先装「组件库 + 样式规范 + 所属框架」3 个，覆盖 80% 的高频场景。
• 团队协作项目：再加「设计系统 + TypeScript + 单测 + a11y」，把规范固化进工具。
• 重交互调试：务必补上「浏览器自动化」，这是体验提升最明显的一块。

4. 手把手：安装并跑通一个 Skill

以「Tailwind 主题规范」为例，走一遍完整流程，你会知道这 5 分钟花在哪。

第 1 步：创建目录和 SKILL.md

mkdir -p ~/.claude/skills/tailwind-design/reference

然后写入 SKILL.md：

---
name: tailwind-design
description: 当用户要求编写或修改 Tailwind CSS 样式、讨论颜色或间距时使用。必须从 reference/theme-tokens.md 中的设计令牌取值。
---

# Tailwind 设计系统规范

## 规则

1. 颜色一律使用 `reference/theme-tokens.md` 中 `theme.extend.colors` 下定义的令牌。
2. 禁止出现任意的 `text-*-500`、`bg-*-400` 等未定义色值。
3. 间距优先使用 4 的倍数（即 `p-4`、`m-8` 等），遵循既有刻度。

## 使用方式

需要确认可用令牌时，先读取 `reference/theme-tokens.md`，再据此生成类名。