本篇是《前端 AI Coding 落地指南》的续作，专门讲 Skills 的实践：什么是 Skills、如何找开源 skills、何时封装、从 Rules 拆出来的与流程类技能、第三方与自封装清单、技能下 rules 的拆分演进，以及每个自封装 skill 的 SKILL 与 rules 示例片段。首篇中已给出 Skills 的简要历程与清单，这里展开为可落地的细节。
Skills 是什么、解决什么问题
Skills 是以 Markdown 写的「技能文件」，用来教会 Agent 完成某一类具体任务。通常一个技能一个目录，里面必有一份 SKILL.md（YAML 头 + 步骤说明 + 示例），还可以带子规则、脚本等。用途很广：按团队标准做 PR 审查、按约定写 commit、按规范查库表，以及我们这里的「创建提案、分析设计稿、加路由/组件/接口/状态、UI 验收」等，只要能把流程步骤化、示例化，就可以做成 Skill。
作用：规定「怎么做」——在 Rules 划好边界的前提下，Skills 给出具体步骤、检查点、产出路径与模板、示例代码，让 Agent 按步骤执行、有例可循；按场景加载、渐进披露——只在执行该任务时读对应 SKILL（和技能内 rules），不一次性灌入整本「规范+步骤+示例」。能解决的 AI Coding 问题：步骤缺失或顺序错乱；产出格式不统一；领域流程不会做（把创建提案、设计稿分析、UI 验收写成独立技能）；Rules 过长难以执行（落地细节放 Skills，需要时再读）；多步骤串联断裂（技能间显式引用，形成提案→分析→开发→验收链路）。
如何找开源优质 Skills
很多平台已经支持 Skills 的发现与安装。例如可以在 skills.sh 这类站点上按语言、场景筛选，看有哪些社区或官方维护的技能可以直接用。安装后通常放在工作区根下（如 .agents/skills/ 或各 Agent 约定的目录），多项目共享。我自己的做法是：通用「写代码」的实践用工作区级第三方 Skills，项目专属流程用自己封装的 Skills。
何时封装 Skills、从 Rules 拆出来的 vs 流程类
什么时候封装：当某一类任务有固定步骤、有检查点、有产出格式或模板、且会反复做时，就值得封装成 Skill。例如「加一个路由」「加一个接口」「加一个全局 Store」「用主题变量写样式」——这些在 Rules 里只有「必须怎样」的约束，但「先建哪几个文件、每步检查什么、示例长什么样」若写在 Rules 里会让文件过长；拆成独立 Skill 后，Agent 只在「加路由/加接口/加 Store/写主题」时加载，更符合渐进披露。
从 Rules 拆出来的 Skills（和项目级 01～11 规则一一对应、负责「怎么做」的那一层）：create-route（加路由的步骤与示例）、create-component（创建/拆分组件的步骤与示例）、create-api（接口目录、命名、错误处理）、create-store（全局状态）、theme-variables（主题/变量用法）。分别在加页面/路由、创建组件、联调、动状态、写样式时用，补上「有约束无步骤」的缺口。
流程类自封装 Skills（不直接对应某一条 Rule，而是对应「需求→提案→设计稿分析→开发→验收」链路上的关键节点）：create-proposal（按是否有设计稿/接口、交付形态产出 SDD 的 proposal、tasks、spec 增量，并串联设计稿分析与 UI 验收）；design-analysis（布局 Map→区域与元素提取→样式汇总→输出 UI 分析清单，依赖设计稿 MCP）；ui-verification（Browser MCP 打开实现页，与设计稿或分析清单比对，按 P0/P1/P2 产出问题清单，可反哺 design-analysis）。这三者把「提案→分析→验收」串成可重复的流水线。
第三方 Skills 清单与简介
| 技能 | 简介 | 使用环节 |
|---|---|---|
| vercel-react-best-practices | React 渲染、异步、打包、服务端等细粒度规则 | 页面/业务开发时按需引用 |
| vercel-composition-patterns | 复合组件、状态提升、避免 boolean props 等 | 设计组件 API、组合与状态时 |
| web-design-guidelines | 通用 UI/UX 设计指南 | UI 分析、实现时参考 |
| find-skills | 查找并选用可用技能 | 需要发现技能时 |
| skill-creator | 创建新技能的结构与规范 | 扩展能力、新增 Skills 时 |
上述技能不绑定单一项目，在流程里主要在「写代码、做架构决策」的环节起作用；代码片段不在此贴出，读者可在 skills.sh 或对应仓库查看。
自封装 Skills 清单与目录结构
.agents/skills/
├── create-proposal/ # 创建提案（SDD proposal、tasks、spec 增量）
│ └── SKILL.md
├── design-analysis/ # 设计稿分析 → UI 分析清单
│ ├── SKILL.md
│ └── rules/
│ ├── analysis-order.md
│ ├── analysis-priorities.md
│ ├── checklist-common-misses.md
│ ├── implementation-common-errors.md
│ ├── implementation-guidelines.md
│ ├── output-analysis-checklist.md
│ ├── tools-design-guidelines.md
│ ├── workflow-element-extraction.md
│ ├── workflow-layout-map.md
│ ├── workflow-output-checklist.md
│ └── workflow-style-summary.md
├── ui-verification/ # UI 验收 → 问题清单
│ ├── SKILL.md
│ └── rules/
│ ├── comparison-content-image.md
│ ├── comparison-content-text.md
│ ├── comparison-hierarchy.md
│ ├── comparison-layout.md
│ ├── errors-alignment.md
│ ├── errors-button-dimensions.md
│ ├── errors-button-position.md
│ ├── errors-css-priority.md
│ ├── errors-flex-column-width.md
│ ├── errors-flex-layout.md
│ ├── errors-grid-container-width.md
│ ├── errors-page-container-width.md
│ ├── tools-browser-navigation.md
│ ├── tools-design-guidelines.md
│ ├── workflow-checklist.md
│ ├── workflow-problem-list.md
│ ├── workflow-reflection.md
│ ├── writing-alignment.md
│ ├── writing-element-completeness.md
│ ├── writing-list-layout.md
│ └── writing-page-container-width.md
├── create-route/ # 新增路由、Page、Loader
├── create-api/ # 新增接口、类型、请求封装
├── create-store/ # 新增 Zustand store
├── create-component/ # 新增/拆分组件
└── theme-variables/ # 主题 CSS 变量使用
技能下 rules 的拆分：为何拆、演进、如何拆、SKILL 留什么
像 design-analysis、ui-verification 这类流程长、检查项多的技能，若把所有内容都塞进一个 SKILL.md，会重新遇到「单文件过长、上下文压力大、模型容易丢重点」的问题。因此做了第二次拆分：在技能目录下增加 rules/，把「分析顺序、比对维度、工作流步骤、输出模板、常见错误、工具用法」等拆成多个小 rule 文件，SKILL.md 里只保留何时用、目标产出、流程概览、以及「详见 rules/xxx」的引用，具体细节按需由 Agent 在执行时加载对应 rule。
演进历程：一开始是「一个技能一个巨大的 SKILL.md」，步骤、检查清单、模板、示例全在一起；后来发现长文档下模型会漏步骤、漏检查项。于是改成：SKILL.md 只写「入口」——使用时机、核心原则、流程几步、每步对应哪份 rule、产出物路径；把「分析顺序与重点」「每步工作流」「输出模板与检查」「实现建议」「工具使用」等拆成 rules 下独立文件，并在 SKILL 里用「详见 rules/xxx」指向。这样 Agent 先读 SKILL 建立整体，再按当前步骤按需读某一条或几条 rule，更好地利用渐进式披露。
根据什么决定是否拆、怎么拆：
- 拆成独立 rule 的：一类信息会被多次引用、或单独读就够用、或篇幅较长容易冲淡主流程的，就拆出去。例如「分析顺序（从上到下、从左到右、从外到里）」「文字/图片/布局/层级四类重点」「布局比对/层级比对/文字比对/图片比对」「常见错误模式（Grid/Flex/对齐/按钮等）」「Browser 使用方式」「设计稿 MCP 使用方式」——各自成文件，SKILL 里只写「第几步见 rules/xxx」「比对时见 rules/xxx」。
- 留在 SKILL.md 的：使用时机、目标产出、流程总览（第 1 步是什么、第 2 步是什么）、与其它技能的关系（如 create-proposal 何时调用 design-analysis、ui-verification）、快速参考（rules 目录索引）。这样 SKILL 成为「总控」，rules 成为「分镜」，既保证流程不丢，又避免单次上下文过大。
自封装 Skill 与 rules 示例片段
create-proposal（SKILL 片段）
---
name: create-proposal
description: 根据需求是否有设计稿/接口、交付形态，决定设计稿分析、数据层、实现后 UI 验收等步骤。创建 OpenSpec 提案时使用。
---
# 创建提案
## 使用时机
当需要为需求创建提案（proposal、tasks、spec）时使用。需求可能是：新增/改版页面、功能组件，有/无设计稿，有/无接口。
## 步骤 1：明确需求类型与条件
| 条件 | 影响 |
|------|------|
| 是否有设计稿或 UI 描述 | 有 → 可选用 design-analysis 产出 UI 分析清单；实现后可有 UI 验收 |
| 是否有接口 | 有→正常对接；无→可不做数据层；未就绪→mock |
| 交付形态 | 新页面/功能组件/其它 → 决定目录与 tasks 模板 |
## 步骤 2：若有设计稿 —— 设计稿分析（推荐）
使用 design-analysis 技能产出 UI 分析清单；在 tasks 中写明页面开发须依据该清单实现，实现后用 ui-verification 验收。
## 步骤 3～5
定义组件与代码结构；接口与数据层（有接口或 mock）；书写 proposal、tasks、spec 增量并校验。
design-analysis（SKILL 片段 + rules 示例）
SKILL.md 片段：
---
name: design-analysis
description: 分析设计稿、产出 UI 分析清单，供开发与验收参照。需按从上到下、从左到右、从外到里，并记录文字、图片、布局、层级四类重点。
---
# 设计稿分析
## 使用时机
需要分析设计稿（.pen、Figma 等）或产出 UI 分析清单时使用。可在写提案前、中或单独做。
## 核心原则
必须按「从上到下、从左到右、从外到里」分析，并逐条准确记录文字、图片、布局、层级四类重中之重。（详见 rules 内分析顺序与重点）
## 目标产出
UI 分析清单文档，开发按此还原、验收按此对照。
## 工作流程（4 步）
1. 建立布局 Map — 获取设计稿结构、整体尺寸、区域划分（详见 rules 第一步）
2. 区域与元素提取 — 每区按从外到里提取，四类重点记全（详见 rules 第二步）
3. 样式规范汇总 — 颜色、字体、圆角、间距、阴影（详见 rules 第三步）
4. 输出 UI 分析清单 — 按模板输出（详见 rules 输出与模板）
design-analysis / rules 示例：analysis-order.md
---
title: 分析顺序（必守）
impact: CRITICAL
impactDescription: 必须严格按从上到下、从左到右、从外到里
tags: analysis, order, workflow, critical
---
# 分析顺序（必守）
## 重要性
必须按以下顺序阅读与记录设计稿，否则容易产生疏漏。不按顺序是遗漏与还原错误的主要来源之一。
## 分析顺序
### 1. 从上到下
先按垂直方向，从页面最上方扫到最下方，确定所有横向「带」与区块的先后顺序。与前端布局一致，避免漏掉顶部/首屏大字号文案。
### 2. 从左到右
同一行或同一层级内，按从左到右依次记录，不跳过、不凭印象合并。避免只记左侧漏右侧，确保同层元素顺序正确。
### 3. 从外到里
每个区块内按「外层容器 → 内层容器 → 叶子元素」逐层进入，先轮廓后细节。确保层级嵌套正确，不丢层或顺序颠倒。
design-analysis / rules 示例：workflow-layout-map.md
---
title: 第一步：建立布局 Map
impact: CRITICAL
impactDescription: 获取整体结构、区域划分与区域间关系
tags: workflow, layout-map, analysis, critical
---
# 第一步：建立布局 Map
## 概述
获取设计稿的整体结构：页面状态、整体尺寸、区域划分、区域间关系。
## 必须记录的内容
| 项目 | 说明 |
|------|------|
| 页面/界面状态 | 多 frame 时分别标注 id 与用途 |
| 整体尺寸 | 宽、高 |
| 区域列表 | 按从上到下（y）排序：区域名、x/y/w/h、主要子元素（含文字、图片） |
| 区域间间距 | 上区底部 → 下区顶部的垂直间距 |
| 文字/图片/布局/层级（每区） | 四类重点，不可遗漏、错位、丢层 |
ui-verification（SKILL 片段 + rules 示例）
SKILL.md 片段：
---
name: ui-verification
description: 验收以「实际页面效果 vs 设计稿」为准，必须用浏览器工具查看目标页，截图或元素比对，产出问题清单与可选反思。
---
# UI 验收
## 核心原则
最终验收标准：实际运行页面与 UI 稿（.pen 或 Figma）比对，而非仅凭代码或分析清单推断。
工具选择：在 Cursor 中优先使用 @Browser；仅当不可用时使用 Playwright MCP。
验收顺序：从上到下 → 从左到右 → 从外到里；先 P0（布局、层级、文字、图片），再 P1/P2。
## 使用时机
实现完成后对照设计稿检查还原度；需产出可追踪的 UI 问题清单；可选做分析不足反思反哺 design-analysis。
## 目标产出
UI 问题清单；可选反思（反哺 design-analysis）。
## 工作流程（5 步）
1. 用 Browser 打开目标页，获取截图/快照
2. 实际页面与设计稿比对，按 P0/P1/P2 逐项比对
3. 产出 UI 问题清单
4. 修复后再次用 Browser 验证
5. 可选：反思分析不足并反哺 design-analysis
ui-verification / rules 示例：comparison-layout.md
---
title: 布局比对规则（P0）
impact: CRITICAL
impactDescription: 布局错位/缺失/比例错均为 P0，验收时不得遗漏
tags: comparison, layout, p0, critical
---
## 布局比对规则（P0）
比对内容：区域位置、尺寸、排列方向、间距（gap/padding）、多图拼接方式；是否错位、缺失、比例失调。
验收顺序：从上到下 → 从左到右 → 从外到里。
布局检查特别关注：页面容器宽度、横向列表是否铺满、Grid 容器宽度、Flex 铺满、元素完整性、对齐方式、CSS 优先级、按钮尺寸与定位（须用浏览器实际查看）。
ui-verification / rules 示例：workflow-checklist.md
---
title: 快速检查清单
impact: HIGH
impactDescription: 验收流程检查清单
tags: workflow, checklist, verification
---
## 快速检查清单
### 验收前
- [ ] 目标页面 URL 已确认
- [ ] 设计稿可打开、可截图或取元素
- [ ] 已有 UI 分析清单更佳
### 验收中（必须落地）
- [ ] 已用 Browser 打开目标页并获取截图/快照
- [ ] 已获取设计稿对应区域截图或元素信息
- [ ] 按从上到下、从左到右、从外到里排查，P0 四项无遗漏
- [ ] 已完成实际页面 vs 设计稿的比对，差异写入 UI 问题清单
create-route（SKILL 片段）
---
name: create-route
description: 按团队规范创建和维护路由，包括目录结构、Page 与 Loader 职责划分及懒加载用法。新增或重构页面路由时使用。
---
# 创建与维护路由
按团队规范创建路由：目录结构 src/routes/<route-name>/（Page.tsx、Loader.tsx、index.module.scss），样式文件必须使用 .module.scss 后缀，路由目录名使用 kebab-case，在全局唯一路由入口注册。步骤：创建 Page 组件 → 创建 Loader 组件（懒加载包装） → 在全局路由中注册。
create-api（SKILL 片段）
---
name: create-api
description: 按团队规范创建和维护 HTTP 接口，包括类型定义、请求封装、命名约定与错误处理。新增或调整 API 时使用。
---
# 创建与维护 API
按团队规范创建 API：确定接口归属模块（请求封装 src/http/<module>.ts、类型定义 src/interfaces/<module>/api.ts、业务模型 src/interfaces/<module>/model.ts） → 在 interfaces 中定义类型 → 在 http 中创建请求函数（命名 getXxxList / getXxxDetail / createXxx / updateXxx / deleteXxx，禁止 fetch 前缀）。错误由拦截器统一处理，业务代码只处理成功逻辑。
create-store（SKILL 片段）
---
name: create-store
description: 使用 Zustand 创建和维护全局状态 store，包括目录结构、命名与持久化策略。新增或重构状态管理时使用。
---
# 创建与维护 Zustand Store
使用 Zustand 创建 store：所有 store 文件放在 src/stores，每个业务模块一个文件 src/stores/<module>.ts，暴露 hook useXxxStore。步骤：创建基本 Store（定义 State 接口、使用 create 创建） → 如需持久化则使用 persist 中间件。
create-component（SKILL 片段）
---
name: create-component
description: 按团队规范创建和拆分 React 组件，包括目录结构、文件命名、样式与主题变量使用。新增或重构组件时使用。
---
# 创建与拆分组件
按团队规范创建组件：通用组件放在 src/components/<component-name>/，页面级组件放在 src/routes/<route>/components/。标准目录结构：index.tsx、index.module.scss。步骤：创建组件骨架 → 样式使用主题变量（var(--ant-color-xxx) 或项目自定义变量），禁止硬编码颜色。单文件建议不超过 400 行，超过时考虑拆分。
theme-variables（SKILL 片段）
---
name: theme-variables
description: 正确使用 Ant Design 与自定义主题 CSS 变量，避免硬编码颜色并保证暗色/浅色主题切换一致性。编写或修改样式时使用。
---
# 主题 CSS 变量与样式规范
所有自定义样式必须使用 CSS 变量表达主题相关的颜色与尺寸，禁止硬编码主色、文本色、背景色等。常用 Ant Design 变量：var(--ant-color-primary)、var(--ant-color-text)、var(--ant-color-bg-container)、var(--ant-color-border)。项目自定义变量：var(--shentu-card-bg)、var(--shentu-border-radius) 等。
以上 5 个技能（create-route、create-api、create-store、create-component、theme-variables）通常单 SKILL 即可，无需拆分子 rules；只有 design-analysis、ui-verification 这类流程长、检查项多的技能才需要拆出 rules 文件夹。
以上是 Skills 篇的完整内容。项目级 Rules 的逐条示例在《前端 AI Coding 落地指南（二）Rules 篇》；架构篇、Rules 篇、Skills 篇一起构成从架构到 Rules/Skills 落地的完整指南。
