用什么写?产出什么?多快能写完?
先把这三件事说清楚,下面的步骤才不会越看越懵。
任何能写纯文本的工具都行
- 最快Mac 的 TextEdit、Windows 的记事本,已经装好,打开就用。 TextEdit 要先在菜单里"格式 → 转换为纯文本",不然会存成 .rtf。
- 已经在用飞书文档、Notion、Apple Notes 也行,先在熟悉的地方组织思路。 飞书写完后:右上角 ⋯ → 导出 → Markdown,把文件改名成 SKILL.md。
- 长期最舒服Cursor 或 VS Code,免费、5 分钟装好,以后多写不会出错。
一个 SKILL.md 文件
就一个文件,扩展名是 .md(Markdown)。里面全是文字 —— 名字、说明、规则、步骤、模板。
~/.claude/skills/<skill 名>/SKILL.md第一次 10 分钟
- 路径 A照模板自己填,约 10 分钟。
- 路径 B让 Claude 帮你写,约 2 分钟。
最终产出长这样 —— 一个完整、能跑的 skill:
--- 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 就是这么一个文件。
跟着下面 Step 0 → Step 7 走一遍。每步都有"现在换你写"面板,照着填。最后到 Step ★ 复制完整模板,把方括号换成你的内容,保存到 ~/.claude/skills/<名字>/SKILL.md。
适合第一次写、想搞懂每一节为什么这么写。
用一两句中文说清你想要 AI 做什么,把下面那段 meta-prompt 复制到 Claude,它会给你一份完整的 SKILL.md,自己再扫一眼,保存。
适合已经知道想要什么、懒得手写。
路径 B 用的 meta-prompt —— 复制下面整段贴给 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 回答)
写完之后告诉我:
- 我应该把这个文件存到哪个路径
- 怎么测试它能不能用
design skill 到底是什么?
想象你是店长,给新来的实习生贴一张便签:"客人说 X,你就做 Y,做完记到本子上。" Design skill 就是贴给 AI 看的这张便签。
动笔前,用大白话回答三个问题。答不上来 = 还没想清楚,别急着写。
例:"用户发来一张 UI 截图"、"用户说'帮我搭个落地页'"、"项目刚新建好"。
越具体越好 —— 别写"设计相关的时候"。
例:"先问 3 个问题 → 再看代码 → 最后把答案写到 .md 文件"。
想不出 3 步 = skill 太小,可能不用写;想写 10 步 = skill 太杂,要拆。
例:"一个 .impeccable.md 文件"、"一段结构化文字,让下一个 skill 接着做"。
没有产出 = 这个 skill 白跑了。必须留下点东西。
一个 skill 只做一件事
常见的 design skill 大致分三种。先认出你想写的是哪种,后面每一步才有方向。
帮项目定风格
问你几个具体问题(产品讲话该像谁、要什么视觉风格、喜欢什么色调…),把答案存成文件。之后 AI 生成 UI 都会看这个文件。
/teach —— 跑一次,之后所有项目都用这套品味。把图翻成文字清单
看一张截图或 Figma,输出"这是什么 UI、用了什么 token、有哪些状态"。自己不写代码,交给下一个 skill。
按清单写代码
拿到上游的清单,变成真实的 React / iOS 代码。只管实现,不管"好不好看"。
ask-tux(Web)、tux-ios(iOS)。看看两个参考分别落在哪里:
它不生成 UI、不写代码,只负责"问问题 + 记答案"。后面真正生成 UI 时,另一批 /polish、/typeset 小命令再照着这份答案做事。
问答归问答,生成归生成 —— 拆开。
它不写代码、不定品味,只负责"看图 → 列清单 → 转给谁"。Web 项目转给 ask-tux;iOS 项目转给 tux-ios。
翻译归翻译,落地归落地 —— 拆开。
用一句话说清你的 skill 是哪种
在脑子里(或便签上)填这个空:
我的 skill 在 [什么时候] 被调用, 负责 [做什么一件事], 产出 [一个什么东西]。
- 例 1:项目刚初始化时被调用,负责问用户几个关于品牌口气和视觉风格的具体问题,产出
.impeccable.md。 - 例 2:用户发来截图时被调用,负责识别 UI 类型和 token,产出一份结构化清单。
写 description —— 给 skill 挂个门牌
description 就是你 skill 的门牌。AI 每次干活前扫一眼,决定"这个活归不归我"。 门牌写得糊,skill 就永远睡着。
一个好门牌包含三块信息,缺一不可:
这个 skill 在做什么?
用动词开头:gather(收集)、analyze(分析)、route(转交)。
什么时候会用到?
写清楚"一次性还是经常用"、"用户处于什么状态时"。
哪些具体的词会唤起你?
列 3–5 个具体名词:screenshot、Figma、project、brand、token。
看参考怎么写:
动作:gathers · saves
场景:One-time setup(就跑一次)
触发词:project · design context · guidelines
动作: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 不会乱触发。
--- name: your-skill-name description: [你刚写的那句话] ---
决定文件放哪,和里面分几段
两个小决定:文件放在哪个文件夹(决定哪些项目能用到)、正文分几段(决定 AI 读起来顺不顺)。
A · 文件放哪? 二选一:
# 方式 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 # 必须叫这个
我的项目/
.claude/skills/
my-brand-check/
SKILL.md
拿不准就选"选项 1"。以后发现只有这个项目在用,再手动挪过去也很快。
B · 正文分几段?两种写法,挑一个:
像菜谱。AI 从上到下照着做完就结束。
适合一次性、线性流程的 skill。
像说明书。按"职责"分块,AI 翻到需要的段查。
适合反复调用、不同输入走不同流程的 skill。
先列出你的章节标题
不用写内容,就把 ## 标题 列下来,能有个骨架感觉:
## [标题 1] ## [标题 2] ## [标题 3] ## [...]
3–7 个标题最合适。少于 3 = 可能不用写 skill,一句 prompt 就够了;多于 7 = 可能太杂,得拆。
写规则 —— 每条都要"当场能查"
规则是你画的红线。好规则的判断标准只有一个:看到成品,能一眼指出"这里违反了"。看不出来 = 假规则。
先学会分辨"好规则"和"烂规则":
所有颜色必须从 token 拿,不能写死 #FF0000。搜一下 "#" 就知道有没违反。一眼可查。
正文字号必须 ≥ 14px。直接看数字。
卡片嵌套不能超过 1 层。数一下嵌套层数。
让设计有 TikTok 的感觉。"感觉"没法检查。
保持设计干净简洁。"干净"太主观。
尽量用好看的配色。"尽量"+"好看",等于没写。
看参考是怎么写规则的:
Impeccable 发现:AI 总会犯同几种套路。与其写"请避免套路设计",不如给每种套路起一个响亮的名字 —— 一看见就能喊出来。
比如 Cardocalypse(卡片大爆炸)、Purple Gradient Disease(紫渐变病)。
给坏例子起名,比给好例子下定义更有力。
1. 优先使用 TUX 现成组件和模式。如果已有方案能用,别自己搭。
2. 所有视觉样式必须用语义 token(颜色、字号、圆角、间距、阴影)。
3. 所有文字必须用 TUX 字号系统,不要自己发明一套字号表。
4. 不要猜平台 API。
每条一个祈使句开头,加一句为什么。全部"可查"。
Impeccable 起的几个有名的"反模式"名字,拿来就能用:
规则写法:
卡片嵌套不超过 1 层。规则写法:
除非品牌规范要求,不使用紫蓝渐变。规则写法:
字体要能表达品牌,不用默认字体。规则写法:
所有正文对比度达到 WCAG AA。列出你的 3–5 条规则
每写完一条,自问一句"怎么检查违反了没?"答不上来 = 重写。
## 规则 1. [必须 / 不能 ...] [一句解释] 2. [必须 / 不能 ...] [一句解释] 3. ...
- 句子用"必须 / 不能 / 始终 / 永不"开头,不要用"尽量 / 最好 / 建议"。
- 总数 5–10 条。太少不够守线,太多 AI 反而会忽略。
- 加分项:给常见的烂做法起个名字(像 Cardocalypse)。
写步骤清单 —— 每步说清"做什么 + 留什么"
规则管"不能破的线",步骤管"按什么顺序走"。像写菜谱 —— 每一步都要交代:这步做什么,做完留下什么。
最小可用模子:
## Workflow
1. [动词] [做什么]
→ 留下:[什么东西给下一步用]
2. [动词] [做什么]
→ 留下:[什么东西给下一步用]
3. [动词] [做什么]
→ 留下:[最终产出] # 最后一步必须是"交付"
看参考怎么写:
每步的产物都是下一步的原料。最后一步一定是"写文件"。
允许中途分叉,但最后一步必须是"交出结果"或"转给下家"。永远有终点。
把你的 skill 步骤写 3–5 条
每步开头用一个动词,结尾写"→ 留下:xxx"。
- 动词要具体:探索 / 询问 / 提取 / 整理 / 写入 / 决定 —— 不要用"处理"、"搞定"。
- 产物要实体:一段 markdown、一份清单、一个文件。不要写"分析"、"理解"。
- 最后一步必须交付:写到文件 or 交给下一个 skill。不能停在"分析完了"。
定下"留下什么" —— 让下一步能接住
skill 跑完后会留下一份"交接单"。字段固定、格式固定,下一个人(或 AI)才知道去哪找什么。 两种常见形式:留文件 或 留清单。
写到哪:.impeccable.md(项目根目录)
谁来读:以后每次 AI 生成 UI 都会自动看这个文件。
什么时候用:产物是"一次定好、长期生效"的东西。
写到哪:当前对话中,传给下一个 skill
谁来读:ask-tux(Web)或 tux-ios(iOS)
什么时候用:你是中转站。产出用完就完,不存盘。
决定你要留什么
先二选一:
- 留文件 → 产物是长期用的东西(设计规范、产品个性定义、配色清单等)。写到项目根目录的一个
.md文件里。 - 留清单 → 产物是一次性交接(这次截图的设计信息)。直接在对话里输出结构化字段。
然后列出固定的字段名(不管这次跑什么输入,字段名都是这几个):
## 产出 字段 1: [一句话说明] 字段 2: [一句话说明] 字段 3: [一句话说明]
写自查清单 —— 每条都能"是/否"回答
skill 的最后一节是"交付前最后扫一眼"。每一条都是一个封闭问题 —— 能用"是"或"否"回答,不能用"大概"、"基本上"、"感觉还行"。
每条一句"有没有/是不是"。没有模糊词。
写 5–8 条自查
每条要能用 "对 / 不对" 回答。一个快速判断法:
- 好:
description 里是否明确写了"Do not use for..."? - 好:
所有规则是否都是祈使句? - 烂:
规则写得清楚吗?("清楚"没法判断) - 烂:
整体感觉对不对?("感觉"不是答案)
## 自查 交付前确认: - [ ] [具体能 yes/no 回答的事] - [ ] [具体能 yes/no 回答的事] - [ ] ...
完整模板 —— 复制、改字、保存
把下面这段整个复制,粘贴到 ~/.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 步测试。
把 SKILL.md 整个发给 Claude,让它检查 → 翻译 → 调试 → 给安装指引
不想自己一项项测的话,复制下面这段贴给 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 跑一遍,就算上线了。
确认文件在这个路径:
~/.claude/skills/<skill 名>/SKILL.md
Claude Code 用户:输入
/help,列表里应该能看到你的 skill。看不到?检查文件夹名和 name: 字段是否一致,然后重开一个对话。
开一个新对话,发一句本该触发你 skill 的话(不要明说 skill 名)。
· 成功:AI 在回答时主动说"我会用 <skill 名>…"或直接按 skill 流程走
· 失败:AI 答得像没看过这个 skill → 说明 description 写得不够具体
看 AI 的回答里:有没有"## 产出"那一节写的字段?步骤顺序对吗?规则有没有违反?
· 成功:产出结构和你写的"## 产出"对得上
· 失败:产出乱写 / 少字段 → 说明"## 产出"部分字段名没写死,或者步骤没说清"留下什么"
发一句明显不该触发的话(和你的 skill 毫不相关),看 AI 会不会误用。
· 成功:AI 完全没提到你的 skill
· 失败:AI 也用上了 → 说明 description 里
Do not use for 没写清
常见毛病 → 对应改哪里:
改:把 description 里的触发词改得更具体(加 3–5 个具体名词)。
改:检查"规则"和"步骤"。规则太虚?改写成可验证的。步骤少说"留下什么"?补上。
改:在"## 产出"里写死字段名(字段 1、字段 2、字段 3),不要留模糊空间。
改:description 末尾加一句
Do not use for [具体反向场景]。改:检查文件路径和 name 字段是否一致;重启你的 AI 工具。
第一版能跑就行,不要一次写完美
Skill 是"一边用一边改"的东西。第一版粗糙很正常。每次用完发现哪里不对,就改一条规则或一句 description,再测一次。改 3–5 轮,基本就能稳定运行。
保存前过一遍这 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/。