给第一次写 Skill 的设计师

写一个属于你自己的 Design Skill

Design skill 是你写给 AI 的一张便签 —— 告诉它:看到什么信号要做哪几步留下什么东西。 看完这一页,你能复制模板写出自己的第一个 skill。全程不用写代码。

参考 A · Impeccable

教 AI 什么是"好设计"

跑一次 /teach,它会问你几个具体问题:"你产品讲话像什么口气?""你希望它看起来什么风格?"。把答案存到 .impeccable.md,之后每次让 AI 生成 UI,都会守着这套品味。

参考 B · TikTok Design System

把设计图翻成"AI 能懂的指令"

你给它一张截图或 Figma 链接,它告诉你:这是什么类型的 UI、用了哪些 token、交给 Web skill 还是 iOS skill 落地。 翻译 + 转发,不写一行代码。

跟着谁学

每一步都有"对方是怎么做的"可以随时切换对照。

动手之前

用什么写?产出什么?多快能写完?

先把这三件事说清楚,下面的步骤才不会越看越懵。

Q1 · 用什么写

任何能写纯文本的工具都行

  • 最快Mac 的 TextEdit、Windows 的记事本,已经装好,打开就用。 TextEdit 要先在菜单里"格式 → 转换为纯文本",不然会存成 .rtf。
  • 已经在用飞书文档、Notion、Apple Notes 也行,先在熟悉的地方组织思路。 飞书写完后:右上角 ⋯ → 导出 → Markdown,把文件改名成 SKILL.md。
  • 长期最舒服Cursor 或 VS Code,免费、5 分钟装好,以后多写不会出错。
不需要会写代码、装环境、跑命令。
Q2 · 最终交什么

一个 SKILL.md 文件

就一个文件,扩展名是 .md(Markdown)。里面全是文字 —— 名字、说明、规则、步骤、模板。

放在 ~/.claude/skills/<skill 名>/SKILL.md
Q3 · 写多久

第一次 10 分钟

  • 路径 A照模板自己填,约 10 分钟。
  • 路径 B让 Claude 帮你写,约 2 分钟。
下面两条路径都有具体步骤。

最终产出长这样 —— 一个完整、能跑的 skill:

文案检查 skill.md ~/.claude/skills/brand-voice-check/SKILL.md
---
name: brand-voice-check           # 文件夹名,必须用英文连字符
description: 检查界面文案是否符合品牌口气。Use when reviewing UI
             text, button labels, notifications, or onboarding copy.
             Do not use for marketing-only content.
                              👆 中文一句先说清干嘛,
                                 后面英文是给 AI 匹配的触发词
---

# 品牌口气检查

帮你检查界面文案是否符合我们的品牌口气。

## 我负责什么

做:
- 检查按钮、提示、标题、错误信息的语气
- 指出"过于客气"、"过于技术"、"机器味"的句子

不做:
- 不重写文案(那是 /rewrite 的事)
- 不检查 marketing 长文

## 规则

1. 必须用第二人称"你",不用"您"
2. 不能出现"请稍候"、"系统错误"这类机器词
3. 必须主动语态("保存了" 而不是 "已被保存")
4. 一句话不超过 14 个字

## 步骤

1. 列出所有 UI 文案 → 留下:一份清单
2. 逐条对照 4 条规则打分 → 留下:违反清单
3. 输出报告 → 留下:违反清单 + 修改建议

## 产出

输出一段 markdown:
### 总分(10 分制)
### 违反规则的句子
### 建议改写

## 自查

- [ ] 每条规则都引用了具体句子?
- [ ] 给出了具体改法,而不是"建议优化"?

就这样。整个 skill 就是这么一个文件。

两条路径
路径 A · 自己填 约 10 分钟

跟着下面 Step 0 → Step 7 走一遍。每步都有"现在换你写"面板,照着填。最后到 Step ★ 复制完整模板,把方括号换成你的内容,保存到 ~/.claude/skills/<名字>/SKILL.md

适合第一次写、想搞懂每一节为什么这么写。

路径 B · 让 Claude 写 约 2 分钟

用一两句中文说清你想要 AI 做什么,把下面那段 meta-prompt 复制到 Claude,它会给你一份完整的 SKILL.md,自己再扫一眼,保存。

适合已经知道想要什么、懒得手写。

路径 B 用的 meta-prompt —— 复制下面整段贴给 Claude,把方括号换成你的需求:

贴给 Claude 的提示词 复制 → 粘贴 → 替换 [...]
我想写一个 design skill,帮我生成一份完整的 SKILL.md。

我的需求:
- 我希望 AI 在 [什么场景] 时调用这个 skill
- 它需要做 [一句话说做什么]
- 最后产出 [一个文件 / 一段结构化清单 / 别的]

请按这个结构生成(为了 AI 能稳定触发,正文也尽量用英文写;中文只用在我能看懂的注释上):

1. 文件最顶部的设置块(用 --- 包起来的那段,包含 name 和 description)
   - name:英文连字符(比如 brand-voice-check)
   - description:全部用英文。结构:
     "[Verb-led 一句话说做什么]. Use when [场景].
      Triggers on [触发词 1], [触发词 2], [触发词 3].
      Do not use for [反向场景]."
   - 触发词必须是英文具体名词(screenshot, Figma, copy, button…),不要用中文

2. ## 我负责什么(做 / 不做 各列 2-3 条)

3. ## 规则(5-8 条,每条祈使句开头,可验证)

4. ## 步骤(3-5 步,每步是"动词 + 留下什么")

5. ## 产出(结构化字段 or markdown 模板)

6. ## 自查(5 条,每条能 yes/no 回答)

写完之后告诉我:
- 我应该把这个文件存到哪个路径
- 怎么测试它能不能用
7 步走完
Step 0

design skill 到底是什么?

想象你是店长,给新来的实习生贴一张便签:"客人说 X,你就做 Y,做完记到本子上。" Design skill 就是贴给 AI 看的这张便签。

动笔前,用大白话回答三个问题。答不上来 = 还没想清楚,别急着写。

1
什么情况下 AI 会想起你?
例:"用户发来一张 UI 截图"、"用户说'帮我搭个落地页'"、"项目刚新建好"。
越具体越好 —— 别写"设计相关的时候"。
2
AI 找到你后,要做哪几步?
例:"先问 3 个问题 → 再看代码 → 最后把答案写到 .md 文件"。
想不出 3 步 = skill 太小,可能不用写;想写 10 步 = skill 太杂,要拆。
3
做完后,留下什么给下一个人?
例:"一个 .impeccable.md 文件"、"一段结构化文字,让下一个 skill 接着做"。
没有产出 = 这个 skill 白跑了。必须留下点东西。
01先搭骨架
Step 1

一个 skill 只做一件事

常见的 design skill 大致分三种。先认出你想写的是哪种,后面每一步才有方向。

类型 1 · 问答型

帮项目定风格

问你几个具体问题(产品讲话该像谁、要什么视觉风格、喜欢什么色调…),把答案存成文件。之后 AI 生成 UI 都会看这个文件。

例:Impeccable 的 /teach —— 跑一次,之后所有项目都用这套品味。
类型 2 · 翻译型

把图翻成文字清单

看一张截图或 Figma,输出"这是什么 UI、用了什么 token、有哪些状态"。自己不写代码,交给下一个 skill。

例:TikTok Design System —— 看图 → 写清单 → 转给平台 skill。
类型 3 · 落地型

按清单写代码

拿到上游的清单,变成真实的 React / iOS 代码。只管实现,不管"好不好看"。

例:ask-tux(Web)、tux-ios(iOS)。

看看两个参考分别落在哪里:

Impeccable 类型 1 · 问答型

它不生成 UI、不写代码,只负责"问问题 + 记答案"。后面真正生成 UI 时,另一批 /polish/typeset 小命令再照着这份答案做事。

问答归问答,生成归生成 —— 拆开。

TT Design System 类型 2 · 翻译型

它不写代码、不定品味,只负责"看图 → 列清单 → 转给谁"。Web 项目转给 ask-tux;iOS 项目转给 tux-ios

翻译归翻译,落地归落地 —— 拆开。

现在换你写

用一句话说清你的 skill 是哪种

在脑子里(或便签上)填这个空:

我的 skill 在 [什么时候] 被调用,
负责 [做什么一件事],
产出 [一个什么东西]。
  • 例 1:项目刚初始化时被调用,负责问用户几个关于品牌口气和视觉风格的具体问题,产出 .impeccable.md
  • 例 2:用户发来截图时被调用,负责识别 UI 类型和 token,产出一份结构化清单。
一句话填不出来?说明 skill 边界不清,回去 Step 0 再想一遍。一句话装得下两件事?拆成两个 skill。
Step 2

写 description —— 给 skill 挂个门牌

description 就是你 skill 的门牌。AI 每次干活前扫一眼,决定"这个活归不归我"。 门牌写得糊,skill 就永远睡着。

一个好门牌包含三块信息,缺一不可:

1 · 动作

这个 skill 在做什么?

用动词开头:gather(收集)、analyze(分析)、route(转交)。

反例:"Design helper" —— 没动词,AI 读不出来该做什么。
2 · 场景

什么时候会用到?

写清楚"一次性还是经常用"、"用户处于什么状态时"。

反例:"when needed" —— 等于没说。
3 · 触发词

哪些具体的词会唤起你?

列 3–5 个具体名词:screenshotFigmaprojectbrandtoken

反例:"design", "UI", "beautiful" —— 太泛,AI 无法识别。

看参考怎么写:

Impeccable 真实摘录
One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.

动作:gathers · saves
场景:One-time setup(就跑一次)
触发词:project · design context · guidelines

TT Design System 真实摘录
Analyze TikTok Design System work as the shared design layer before implementation. Use for screenshot or Figma analysis, stabilizing the shared design contract, token semantics, component anatomy, hierarchy...

动作:Analyze · route
场景:before implementation(在写代码之前)
触发词:screenshot · Figma · token · component

现在换你写

把三块拼成一句话

打开任何文本编辑器,按这个模子填:

[动词开头的一句话说做什么].
Use when [什么场景].
Triggers on [触发词 1], [触发词 2], [触发词 3].
Do not use for [明显不该用的场景].
  • 动词打头:Gather / Analyze / Route / Audit …(别用 Help / Assist 这种虚词)
  • 触发词是具体名词:screenshot, Figma, brand, project。不要用形容词。
  • 最后那句 Do not use for… 极其重要 —— 边界画清,AI 不会乱触发。
贴到文件最顶部 SKILL.md
---
name: your-skill-name
description: [你刚写的那句话]
---
Step 3

决定文件放哪,和里面分几段

两个小决定:文件放在哪个文件夹(决定哪些项目能用到)、正文分几段(决定 AI 读起来顺不顺)。

A · 文件放哪? 二选一:

选项 1 · 所有项目都能用 家目录
# 方式 1:不用终端
# 在 Finder 里按 ⌘+⇧+G 输入 ~/.claude/skills/ 跳过去,
# 手动新建文件夹 "my-brand-check",在里面新建 SKILL.md。

# 方式 2:用终端(一行搞定)
mkdir -p ~/.claude/skills/my-brand-check

~/.claude/skills/
  my-brand-check/          # 文件夹名 = skill 名
    SKILL.md               # 必须叫这个
选项 2 · 只在一个项目里用 项目根目录
我的项目/
  .claude/skills/
    my-brand-check/
      SKILL.md

拿不准就选"选项 1"。以后发现只有这个项目在用,再手动挪过去也很快。

B · 正文分几段?两种写法,挑一个:

Impeccable 的分段 线性
## Step 1: Explore the Codebase ## Step 2: Ask UX-Focused Questions ## Step 3: Write Design Context

像菜谱。AI 从上到下照着做完就结束。
适合一次性、线性流程的 skill。

TT Design System 的分段 模块
## Layer Responsibility ## Mandatory Rules ## Workflow ## Output Contract ## Routing ## Checklist

像说明书。按"职责"分块,AI 翻到需要的段查。
适合反复调用、不同输入走不同流程的 skill。

现在换你写

先列出你的章节标题

不用写内容,就把 ## 标题 列下来,能有个骨架感觉:

## [标题 1]
## [标题 2]
## [标题 3]
## [...]

3–7 个标题最合适。少于 3 = 可能不用写 skill,一句 prompt 就够了;多于 7 = 可能太杂,得拆。

02再填细节
Step 4

写规则 —— 每条都要"当场能查"

规则是你画的红线。好规则的判断标准只有一个:看到成品,能一眼指出"这里违反了"。看不出来 = 假规则。

先学会分辨"好规则"和"烂规则":

所有颜色必须从 token 拿,不能写死 #FF0000。
搜一下 "#" 就知道有没违反。一眼可查。
正文字号必须 ≥ 14px。
直接看数字。
卡片嵌套不能超过 1 层。
数一下嵌套层数。
让设计有 TikTok 的感觉。
"感觉"没法检查。
保持设计干净简洁。
"干净"太主观。
尽量用好看的配色。
"尽量"+"好看",等于没写。

看参考是怎么写规则的:

Impeccable 反模式命名法

Impeccable 发现:AI 总会犯同几种套路。与其写"请避免套路设计",不如给每种套路起一个响亮的名字 —— 一看见就能喊出来。

比如 Cardocalypse(卡片大爆炸)、Purple Gradient Disease(紫渐变病)。

给坏例子起名,比给好例子下定义更有力。

TT Design System 规则节选

1. 优先使用 TUX 现成组件和模式。如果已有方案能用,别自己搭。

2. 所有视觉样式必须用语义 token(颜色、字号、圆角、间距、阴影)。

3. 所有文字必须用 TUX 字号系统,不要自己发明一套字号表。

4. 不要猜平台 API。

每条一个祈使句开头,加一句为什么。全部"可查"。

Impeccable 起的几个有名的"反模式"名字,拿来就能用:

Cardocalypse · 卡片大爆炸 —— 所有东西都包在卡片里,一层套一层。
规则写法:卡片嵌套不超过 1 层。
Purple Gradient Disease · 紫渐变病 —— 不管什么产品都用紫蓝渐变。
规则写法:除非品牌规范要求,不使用紫蓝渐变。
Inter Everywhere · Inter 无处不在 —— 所有项目默认都是 Inter 字体。
规则写法:字体要能表达品牌,不用默认字体。
Low-Contrast Gray-on-Gray · 浅灰糊一片 —— 次级文字和背景分不清。
规则写法:所有正文对比度达到 WCAG AA。
现在换你写

列出你的 3–5 条规则

每写完一条,自问一句"怎么检查违反了没?"答不上来 = 重写。

## 规则

1. [必须 / 不能 ...] [一句解释]
2. [必须 / 不能 ...] [一句解释]
3. ...
  • 句子用"必须 / 不能 / 始终 / 永不"开头,不要用"尽量 / 最好 / 建议"。
  • 总数 5–10 条。太少不够守线,太多 AI 反而会忽略。
  • 加分项:给常见的烂做法起个名字(像 Cardocalypse)。
Step 5

写步骤清单 —— 每步说清"做什么 + 留什么"

规则管"不能破的线",步骤管"按什么顺序走"。像写菜谱 —— 每一步都要交代:这步做什么,做完留下什么

最小可用模子:

步骤清单模子 ## Workflow
## Workflow

1. [动词] [做什么]
   → 留下:[什么东西给下一步用]

2. [动词] [做什么]
   → 留下:[什么东西给下一步用]

3. [动词] [做什么]
   → 留下:[最终产出]      # 最后一步必须是"交付"

看参考怎么写:

Impeccable 3 步 · 线性
1. 探索代码 → 留下:你大致知道项目用什么技术、 有没有已经定好的风格 2. 问用户几个具体问题 (产品讲话像谁?要什么视觉风格? 色调偏好?有无无障碍要求?) → 留下:用户的几条回答 3. 把答案写到 .impeccable.md → 留下:一份整理好的 markdown 文件

每步的产物都是下一步的原料。最后一步一定是"写文件"。

TT Design System 5 步 · 有分支
1. 搞清楚素材是什么 (截图 / Figma / 文字描述) 2. 只读必要的参考资料 3. 提取设计信息 (这是什么 UI、用什么 token、有什么状态) 4. 把提取的信息整理成结构化清单 5. 决定交给谁 → 自己做完 or 转给平台 skill

允许中途分叉,但最后一步必须是"交出结果"或"转给下家"。永远有终点。

现在换你写

把你的 skill 步骤写 3–5 条

每步开头用一个动词,结尾写"→ 留下:xxx"

  • 动词要具体:探索 / 询问 / 提取 / 整理 / 写入 / 决定 —— 不要用"处理"、"搞定"。
  • 产物要实体:一段 markdown、一份清单、一个文件。不要写"分析"、"理解"。
  • 最后一步必须交付:写到文件 or 交给下一个 skill。不能停在"分析完了"。
Step 6

定下"留下什么" —— 让下一步能接住

skill 跑完后会留下一份"交接单"。字段固定、格式固定,下一个人(或 AI)才知道去哪找什么。 两种常见形式:留文件留清单

形式 1 · 留文件 Impeccable 用这种
## Design Context ### Users(用户) [谁在用这个产品、什么场景下用] ### Brand Personality(产品个性) [产品讲话像谁,比如"友好的店员" "专业的医生",三个形容词] ### Aesthetic Direction(视觉方向) [极简 / 大胆 / 温暖 / 复古… + 几个参考站] ### Design Principles(指导原则) [3–5 条具体的设计准则]

写到哪:.impeccable.md(项目根目录)
谁来读:以后每次 AI 生成 UI 都会自动看这个文件。
什么时候用:产物是"一次定好、长期生效"的东西。

形式 2 · 留清单 TT DS 用这种
素材类型: screenshot / Figma / ... 界面类型: [页面框架 / 弹窗 / 列表 ...] 组件结构: [选用的 TUX 组件] token 使用: [颜色、字号、圆角 ...] 层级: [标题、副标题、正文 ...] 状态: [交互、加载、禁用 ...] 动效意图: [过渡、反馈 ...] 待澄清: [模糊点、缺口]

写到哪:当前对话中,传给下一个 skill
谁来读:ask-tux(Web)或 tux-ios(iOS)
什么时候用:你是中转站。产出用完就完,不存盘。

判断自己写得好不好:下家拿到你的输出,不用再翻一遍原始素材就能开始做事。做得到 = 合格。
现在换你写

决定你要留什么

先二选一:

  • 留文件 → 产物是长期用的东西(设计规范、产品个性定义、配色清单等)。写到项目根目录的一个 .md 文件里。
  • 留清单 → 产物是一次性交接(这次截图的设计信息)。直接在对话里输出结构化字段。

然后列出固定的字段名(不管这次跑什么输入,字段名都是这几个):

## 产出

字段 1: [一句话说明]
字段 2: [一句话说明]
字段 3: [一句话说明]
Step 7

写自查清单 —— 每条都能"是/否"回答

skill 的最后一节是"交付前最后扫一眼"。每一条都是一个封闭问题 —— 能用"是"或"否"回答,不能用"大概"、"基本上"、"感觉还行"。

TT Design System 的自查清单 真实摘录
交付前确认: - 素材来源已明确?(截图 / Figma / ...) - 界面类型已明确? - 主要层级已看清? - 所有 token 是按"含义"选的 (而不是看名字猜的)? - 页面表面样式统一? - 所有需要的状态都考虑了? - 有没有偷偷写进平台特定的代码?

每条一句"有没有/是不是"。没有模糊词。

现在换你写

写 5–8 条自查

每条要能用 "对 / 不对" 回答。一个快速判断法:

  • 好:description 里是否明确写了"Do not use for..."?
  • 好:所有规则是否都是祈使句?
  • 烂:规则写得清楚吗?("清楚"没法判断)
  • 烂:整体感觉对不对?("感觉"不是答案)
## 自查

交付前确认:
- [ ] [具体能 yes/no 回答的事]
- [ ] [具体能 yes/no 回答的事]
- [ ] ...
03整合上线
收尾

完整模板 —— 复制、改字、保存

把下面这段整个复制,粘贴到 ~/.claude/skills/<你的 skill 名>/SKILL.md, 然后把方括号 [...] 里的内容换成你自己的。就这样。

SKILL.md · 从这里整个复制 ~/.claude/skills/<你的 skill 名>/SKILL.md
---
name: [skill 的英文名,用连字符]
                          👆 例:brand-voice-check

description: [一句中文说清干嘛]。Use when [场景]. Triggers on
             [触发词 1], [触发词 2]. Do not use for [反向场景].
                          👆 例:检查界面文案是否符合品牌口气。Use when
                                reviewing UI text, button labels, notifications,
                                or onboarding copy. Do not use for marketing-only content.
                          
                            中文一句让人一眼看懂在干嘛,
                            后面的英文触发词是给 AI 匹配用的。
---

# [Skill 的中文标题]
👆 例:# 品牌口气检查

[一句话说明这个 skill 在做什么、谁会用到它]
👆 例:帮你检查界面文案是否符合我们品牌的讲话方式。


## 我负责什么

做:
- [能做的事 1]
- [能做的事 2]

不做:
- [不做的事 1] —— 这件事交给 <另一个 skill>
- [不做的事 2]

👆 例:
   做:
   - 检查按钮、提示、标题、错误信息的语气
   - 指出"过于客气"、"过于技术"、"机器味"的句子
   不做:
   - 不重写文案(那是 /rewrite 的事)
   - 不检查 marketing 长文


## 规则

1. 必须 / 不能 ... [一句话解释为什么]
2. 必须 / 不能 ... [...]
3. 不要 [具体动作]. [为什么不能做]

👆 例:
   1. 必须用第二人称"你",不用"您"
   2. 不能出现"请稍候"、"系统错误"这类机器词
   3. 必须主动语态("保存了" 而不是 "已被保存")
   4. 一句话不超过 14 个字

# 5–10 条。超过 10 条 AI 会开始忽略。


## 步骤

1. [动词] [做什么] → 留下:[什么东西给下一步]
2. [动词] [做什么] → 留下:[...]
3. [动词] [做什么] → 留下:[...]
4. [最后一步必须是"交付":写文件 或 转给下一个 skill]

👆 例:
   1. 列出所有 UI 文案 → 留下:一份完整清单
   2. 逐条对照 4 条规则打分 → 留下:违反清单
   3. 输出报告 → 留下:违反清单 + 修改建议


## 产出

# 二选一 —

# A. 留文件
写到 <某个路径>,格式:
### [小节 1]
### [小节 2]

# B. 留清单(交给下一个 skill)
- [字段 1]: [含义]
- [字段 2]: [含义]

👆 例(A 留文件):
   写到 .impeccable.md,格式:
   ### 总分(10 分制)
   ### 违反规则的句子(哪句、违反哪条)
   ### 建议改写


## 转给谁   # 只有"翻译型" skill 需要这一节

- 如果 [条件 A] → 自己做完
- 如果 [条件 B] → 转给 <某个下游 skill>

👆 例:
   - 如果是 Web 项目 → 转给 ask-tux
   - 如果是 iOS 项目 → 转给 tux-ios


## 自查

交付前确认:
- [ ] [能 yes/no 回答的事 1]
- [ ] [能 yes/no 回答的事 2]
- [ ] [能 yes/no 回答的事 3]

👆 例:
   - [ ] 每条违反都引用了具体句子?
   - [ ] 给出了具体改写,而不是"建议优化"?
   - [ ] 总分给出了 0–10 的具体数字?

小提示:第一次写不用每一节都填。最小可用 = name + description + 规则 + 步骤 + 产出。 "我负责什么"、"转给谁"、"自查"这几节,等你写熟了再加。

写完之后
验证

怎么知道 AI 真的会用、而且用得对?

保存完文件不代表就完事了。两条路: 捷径—— 把文件丢给 Claude 让它自己检查 + 翻译 + 给你测试 prompt; 手动—— 自己跑 4 步测试。

捷径 · 让 Claude 帮你做完

把 SKILL.md 整个发给 Claude,让它检查 → 翻译 → 调试 → 给安装指引

不想自己一项项测的话,复制下面这段贴给 Claude,把你写的 SKILL.md 一起贴上去:

让 Claude 帮你优化的提示词 复制 → 粘贴 + 你的 SKILL.md
这是我刚写的 design skill,请帮我做这几件事:

1. 检查质量
- 看有没有"假规则"(无法当场验证的,比如"让设计干净")
- 看 description 的触发词是不是足够具体(不是"设计相关"这种空话)
- 看每条步骤是不是都有"动词 + 留下什么"
- 看产出是不是有固定字段名

2. 把整份 SKILL.md 翻成英文(重点)
- 我担心 AI 触发中文不稳,请把 description、规则、步骤、产出、自查
  都翻成英文版本
- description 结构:
  "[Verb] [一句话做什么]. Use when [场景].
   Triggers on [3-5 个具体英文名词,比如 screenshot, button, copy].
   Do not use for [反向场景]."
- 翻译时保留中文原意,但用 AI 在训练里见过的标准英文术语
- 你可以在每节后面用 # 注释保留一行中文,方便我以后回读

3. 输出修过的完整 SKILL.md
- 直接给我能粘贴回文件的完整版本
- 改了哪里、为什么改,列在前面

4. 告诉我怎么安装
- 应该存到哪个具体路径(macOS / Windows 都说一下)
- 文件夹名应该叫什么

5. 给我 3 个测试 prompt
- 2 个应该触发的(写出我应该输入什么)
- 1 个不应该触发的(验证边界)
- 每个 prompt 后面写"成功的标志是 …"

下面是我的 SKILL.md:

---
[把你写的整个 SKILL.md 粘贴在这里]
---

Claude 会给你一份"修过的 SKILL.md + 安装路径 + 3 个测试 prompt"。把修过的版本存回文件,照着测试 prompt 跑一遍,就算上线了。

或者 · 自己手动跑 4 步
1
放对地方 + 让工具重新识别
确认文件在这个路径:~/.claude/skills/<skill 名>/SKILL.md
Claude Code 用户:输入 /help,列表里应该能看到你的 skill。看不到?检查文件夹名和 name: 字段是否一致,然后重开一个对话。
2
测"触发" —— AI 在该用的时候用没?
开一个新对话,发一句本该触发你 skill 的话(不要明说 skill 名)。
· 成功:AI 在回答时主动说"我会用 <skill 名>…"或直接按 skill 流程走
· 失败:AI 答得像没看过这个 skill → 说明 description 写得不够具体
3
测"产出" —— 按规则 & 步骤输出了没?
看 AI 的回答里:有没有"## 产出"那一节写的字段?步骤顺序对吗?规则有没有违反?
· 成功:产出结构和你写的"## 产出"对得上
· 失败:产出乱写 / 少字段 → 说明"## 产出"部分字段名没写死,或者步骤没说清"留下什么"
4
测"边界" —— 不该用的时候会不会乱触发?
发一句明显不该触发的话(和你的 skill 毫不相关),看 AI 会不会误用。
· 成功:AI 完全没提到你的 skill
· 失败:AI 也用上了 → 说明 description 里 Do not use for 没写清

常见毛病 → 对应改哪里:

AI 完全不用你的 skill。
改:把 description 里的触发词改得更具体(加 3–5 个具体名词)。
AI 用了但做得不对。
改:检查"规则"和"步骤"。规则太虚?改写成可验证的。步骤少说"留下什么"?补上。
AI 的产出结构乱。
改:在"## 产出"里写死字段名(字段 1、字段 2、字段 3),不要留模糊空间。
AI 在不该用的时候也在用。
改:description 末尾加一句 Do not use for [具体反向场景]
AI 说"skill 不存在"。
改:检查文件路径和 name 字段是否一致;重启你的 AI 工具。
迭代心法

第一版能跑就行,不要一次写完美

Skill 是"一边用一边改"的东西。第一版粗糙很正常。每次用完发现哪里不对,就改一条规则或一句 description,再测一次。改 3–5 轮,基本就能稳定运行。

什么时候算"做好了"?同一类任务,连续 3 次测试都触发成功 + 产出结构正确 —— 就算稳了,可以交给别人用。
上线前

保存前过一遍这 8 条

任何一条不过关,AI 在真实场景下可能就忽略你的 skill 或者乱做。

  • 01
    description 第一句就能看出"啥时候该用"。测试法:把这一句给没看过你 skill 的同事,看他能不能立刻说出一个触发场景。
  • 02
    触发词都是具体名词。好:screenshot、Figma、project、component。烂:设计相关、美观、好看。
  • 03
    明确写了"不做什么"。边界 > 能力。AI 不知道边界就会乱触发。
  • 04
    每条规则都能"当场查"。自问:违反了,我能在成品里指着说"这里错"吗?不能 = 改写。
  • 05
    每一步都有"动词 + 留下什么"。前一步留下的东西 = 下一步的原料。最后一步一定是"交付"。
  • 06
    产出的字段名是固定的。不是"看情况写什么",而是"不管输入什么,输出这几个固定字段"。
  • 07
    如果是中转站,写清楚交给谁。例:Web 项目 → ask-tux;iOS 项目 → tux-ios。不写下家 = 死胡同。
  • 08
    文件放在对的地方。所有项目都用 → ~/.claude/skills/。只在一个项目用 → 那个项目里的 .claude/skills/
分享给别人
分享

怎么让团队 / 朋友也用上你的 skill?

skill 是一个文件(最多带一个文件夹)。三种分享方式,按"简单 → 长期可维护"排。

方法 1 · 最简单

直接发文件

SKILL.md 文件直接发给对方 —— 飞书 / 邮件 / 微信都行。

对方做:新建文件夹 ~/.claude/skills/<skill 名>/,把 SKILL.md 放进去,重启 Claude Code。
什么时候用:你的 skill 只有 SKILL.md 一个文件。99% 的情况都是这种。
方法 2 · 多文件

打包成 zip

如果你的 skill 还有 references/ 文件夹(放细节文档、token 表等),把整个文件夹压缩成 zip 发出去。

对方做:解压到 ~/.claude/skills/ 下面,确认文件夹结构正确。
什么时候用:skill 比较大、有多个参考文件。
方法 3 · 长期维护

放到 GitHub / 内部 Git

把 skill 文件夹推到 GitHub 仓库(一个仓库可以放多个 skill),分享链接。

对方做:git clone~/.claude/skills/,以后你更新了 git pull 一下就同步。
什么时候用:会持续迭代、想让团队多人协作维护。

附一份"复制即可发给同事"的安装说明:

发给同事的安装说明(直接复制) 配合 SKILL.md 文件一起发
嗨,给你一个我写的 Claude skill:[skill 名 · 比如 brand-voice-check]
做的事:[一句话说干嘛 · 比如"检查界面文案是否符合品牌口气"]

📁 安装步骤

1. 在你电脑上新建一个文件夹(路径很重要):

   Mac:在 Finder 按 ⌘+⇧+G,输入 ~/.claude/skills/,回车。
        在打开的位置里新建文件夹,名字叫 [skill 名]。

   Windows:打开"我的电脑",进入 C:\Users\<你的名字>\.claude\skills\。
            新建文件夹,名字叫 [skill 名]。

2. 把附件里的 SKILL.md 放进刚建的文件夹里。

3. 完全退出 Claude Code(不是关窗口,是退出程序),再打开。

✅ 验证安装成功

打开 Claude Code,输入 /help,列表里应该能看到 [skill 名]。

试试这句话看会不会自动调用:
[一个具体的测试 prompt · 比如"帮我看看这几个按钮文案是不是符合品牌口气"]

❓ 出问题

· 看不到 skill → 检查文件夹名和 SKILL.md 里的 name: 字段一致吗?
· AI 没自动用 → 试着在 prompt 里直接说"用 [skill 名] 来…"
· 还是不行 → 找我,我帮你看

团队分享小提示:如果是给整个团队用,建议建一个内部 GitHub 仓库(比如 team-skills),把所有 skill 都放进去。新人入职,git clone 一次就能装上一整套。