引言

你可能遇到过这种情况：同一个任务（会议纪要、代码评审、发布流程、合规检查）每次都要把“长长的规则”再贴一遍；而当这些规则越来越复杂，又会把上下文挤爆、让模型抓不住重点。

这期视频把 Agent Skill 讲得很透：它不是“更强的提示词”，而是一种可复用的能力封装方式，并且通过 渐进式披露（progressive disclosure） 做到“只在需要时加载”。视频还强调了一个关键对比：Skill 和 MCP 能力有交集，但定位不同，很多场景应该组合使用。Agent Skill 从使用到原理，一次讲清

本文会基于视频主线，结合 Agent Skills 规范与主流工具文档，把“从使用到原理”讲清楚，并给你一套可直接复用的写 Skill 方法论。

Agent Skill 是什么

用一句话概括：Agent Skill 是一个目录（folder），里面包含 SKILL.md 指令文件，以及可选的脚本、参考资料、资源文件；AI 工具会在合适的时机发现并加载它们。Agent Skills 概览 Skills explained

从规范角度看，一个最小 Skill 的目录结构如下：Agent Skills Specification

1
2
skill-name/
  SKILL.md

而更实用的结构通常会把“长知识/长规则”放到 references/，把“可执行自动化”放到 scripts/：

1
2
3
4
5
6
meeting-minutes/
  SKILL.md
  references/
    FINANCE.md
  scripts/
    upload.py

核心机制：渐进式披露（Progressive Disclosure）

Agent Skills 的关键不是“把提示词收纳起来”，而是 加载策略。规范把它分成三层：Agent Skills Specification

  1. Metadata（约 ~100 tokens）：启动时只加载 name、description，让 agent 知道“有哪些技能”和“什么时候用”。
  2. Instructions（建议 < 5000 tokens）：当 agent 认为某个 Skill 相关时，才加载 SKILL.md 正文指令。
  3. Resources（按需）：只有当指令引用到 references/、scripts/、assets/ 等文件时，才会进一步读取/执行。

VS Code 文档也用类似的“三层加载”描述了这一点：Use Agent Skills in VS Code

注意：这套设计直接解决了“可复用规则很长”与“上下文很贵”之间的矛盾：你可以装很多 Skill，但每次只为当前任务付出必要的上下文成本。

基础用法：写一个会议纪要 Skill（可复用、可迁移）

1) 先写对目录名和 Frontmatter

Agent Skills 规范对 name 有硬性约束：小写字母/数字/连字符（hyphen），最长 64，且必须与父目录名一致。Agent Skills Specification

例如目录叫 meeting-minutes/，则 SKILL.md 的 frontmatter 应该是：

1
2
3
4
5
---
name: meeting-minutes
description: Summarize meeting transcripts into attendees, agenda items, and decisions. Use when the user asks for meeting minutes, meeting summary, or action items.
compatibility: Works with Agent Skills compatible tools. Requires ability to read local files.
---

2) 再写正文指令（Instruction）

建议把正文写成“可执行的 SOP”，包括输出格式、步骤、边界条件、示例输入输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
---
name: meeting-minutes
description: Summarize meeting transcripts into attendees, agenda items, and decisions. Use when the user asks for meeting minutes, meeting summary, or action items.
---

## Goal
Produce clear meeting minutes from a raw transcript.

## Output format (required)
### Attendees
- <name>

### Agenda
1. <topic>

### Decisions
- <decision>

### Action Items
- <owner>: <task> (due: <date or TBD>)

## Procedure
1. Read the transcript carefully and infer attendee names if stated.
2. Group discussion into agenda topics.
3. Extract explicit decisions; do not invent decisions.
4. If budgets, procurement, expenses, or payments are mentioned, follow the Finance Check section and read references/FINANCE.md.
5. If the user asks to upload/sync/send to a server, run scripts/upload.py with the minutes content.

注意：正文越长，触发 Skill 后的上下文成本越高。规范建议把 SKILL.md 控制在 500 行以内，把长材料下沉到 references/。Agent Skills Specification

高级用法一：Reference（按需读取长资料）

视频里用“集团财务手册”演示了 Reference 的价值：只有当会议内容提到费用/预算等关键词时，才加载财务规则；否则不占用上下文 token。Agent Skill 从使用到原理，一次讲清

你可以在 references/FINANCE.md 放合规规则（越聚焦越好）：

1
2
3
4
5
6
7
# Finance policy (excerpt)

## Hotel
- Max hotel reimbursement: 500 CNY per night

## Meals
- Max meal reimbursement: 300 CNY per person per day

然后在 SKILL.md 里写清楚“何时读取”与“读完要做什么”，并用相对路径引用：Agent Skills Specification

1
2
3
4
## Finance Check
Only when budget, procurement, expenses, reimbursement, or payments are mentioned:
- Read [references/FINANCE.md](references/FINANCE.md)
- Flag any amount that exceeds the policy and specify the required approver

高级用法二：Script（执行自动化，而不是堆更多上下文）

视频强调了 Script 的一个关键点：脚本是被执行的，通常不会被当作长文本读进上下文；因此你可以把复杂逻辑放到脚本里，避免把上下文“塞爆”。Agent Skill 从使用到原理，一次讲清

例如 scripts/upload.py（示例为安全起见使用环境变量，不要硬编码密钥）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import os
import sys
import json
import urllib.request


def main() -> int:
    upload_url = os.environ.get("UPLOAD_URL", "https://example.com/upload")
    token = os.environ.get("UPLOAD_TOKEN", "")

    content = sys.stdin.read()
    if not content.strip():
        print("No content to upload.", file=sys.stderr)
        return 2

    payload = json.dumps({"content": content}).encode("utf-8")
    req = urllib.request.Request(upload_url, data=payload, method="POST")
    req.add_header("Content-Type", "application/json")
    if token:
        req.add_header("Authorization", f"Bearer {token}")

    with urllib.request.urlopen(req, timeout=30) as resp:
        body = resp.read().decode("utf-8", errors="replace")
        print(body)
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

警告：任何“会产生副作用”的脚本（发请求、改线上、发消息）都要做权限与确认机制。不同平台对脚本执行、自动批准（auto-approve）有不同的安全控制，务必先读文档、再在受控环境中试运行。Use Agent Skills in VS Code

Skills 的制作（含最佳实践）

目前 Skills 的制作方式大致可以分成两类：

  • 本地制作（以 Claude Code 为代表）：借助 skill-creator 等技能，在本地文件系统里生成/迭代 Skill（更可控，但对工具与环境有一定门槛）。
  • 云端制作（以扣子为代表）：全程自然语言对话，在云端沙盒中生成/调试/部署 Skill（上手更轻量，适合大多数“先做出来再优化”的场景）。

在 Claude Code 中制作 Skills（以 skill-creator 为核心）

这里默认你已经安装并能正常使用 Claude Code。若是初次接触，可以先参考官方文档的安装与能力说明，再回到本文继续（重点在“如何把流程固化成 Skill”）。

案例一：做一个「英文博客翻译」Skill（把固定流程固化为可复用 SOP）

这是一个典型的“高频处理 + 可复用流程”任务：你经常读英文博客，遇到好文章想保存为中英双语两份文档，步骤通常比较固定：

  • 获取博客内容并保存为英文版 Markdown
  • 基于英文 Markdown 翻译为中文
  • 审阅译文并润色，输出中文最终版

Step 1：安装 skill-creator

Step 2：梳理需求并写成“可执行提示词”

为了让模型更稳定地产出你想要的 Skill，建议把提示词拆成 4 类信息（越明确越不跑偏）：

  • 用途：这个 Skill 用来解决什么问题（做什么）。
  • 触发方式：什么场景/用户表达会触发（什么时候用）。
  • 输出要求：输出格式、命名规则、保存位置、边界条件（怎么输出）。
  • 所需资源（可选）：脚本、术语表、润色规则、参考资料（用什么支撑它做对）。

下面是一份“英文博客翻译”Skill 的真实提示词示例（可直接复制给 skill-creator 使用，后续再逐步补齐脚本/术语表/润色规则）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
我要创建一个「英文博客翻译」Skill，这个Skill可以获取任意英文博客URL并将它转换为Markdown文件保存在本地，同时支持将英文Markdown文件翻译为中文保存在同一目录下。

1、核心流程：
步骤一：获取英文博客内容并保存为英文版Markdown（用python脚本固定）
步骤二：根据英文版Markdown翻译为中文（将翻译prompt固定）
步骤三：审阅译文并润色输出为中文最终版（将润色prompt和术语表固定，稍后提供）

2、输出文件：一份英文版Markdown，一份中文版Markdown

3、输出文件要求：保存的Markdown文件按域名组织，例如：

<项目根目录>/
└── <domain>/
    └── <blog>.md
    └── <中译-blog>.md

- <domain>：即站点名，如github.com、mp.weixin.qq.com
- 英文版Markdown文件命名：<blog>，从页面标题（首选）或 URL 路径中提取信息，转换为 kebab-case 格式，2-6 个单词
- 中文版Markdown命名：<中译-blog>，即在英文版Markdown文件命名前加上  中译- 进行连接

4、触发时机：当用户想要保存并翻译博客文章时使用。

小建议：提示词里“输出文件要求”一定要写得非常具体（保存位置、命名规则、目录结构），否则模型很容易在这一步自由发挥，导致后续脚本/测试都不好收敛。

Step 3：用 skill-creator 生成 Skill

把 Step 2 的提示词交给 Claude Code。若你发现它触发了“别的 Skill”（比如触发到 superpowers），通常意味着：

  • 你的 description/触发条件不够精准，关键词与意图描述太泛；
  • 或你同时安装了多个相近技能，导致匹配冲突。

解决思路很简单：收敛 description、加上更具体的触发语句与关键词，必要时把某些技能设为 disable-model-invocation: true 只允许手动调用。

Step 4：测试并迭代

建议重点验证两个稳定性：

  • 稳定触发：在预期场景下是否能触发（多换几种用户表达方式）。
  • 稳定执行：流程是否会跳步/漏步、输出是否符合命名与目录要求（多换几个不同站点/不同结构的博客 URL）。

Step 5：分享（可选）：制作 Plugin/Marketplace

如果你希望把自定义 Skill 分享给更多人，除了直接分享本地文件，也可以按官方插件文档把它打包成可安装/可更新的形式：

案例二：做一个「Chrome 插件图标」Skill（先验证脚本，再打包进 Skill）

这个案例的目标很工程化：解决“AI 写 Chrome 插件但总忘了配置图标/图标格式不对”的问题，并支持两种输入路径：

  • 有现成 SVG：直接把 SVG 转成 Chrome 插件所需的 4 种 PNG 尺寸（16×16、32×32、48×48、128×128）。
  • 没有现成 SVG：先在图标库搜索并下载 SVG，再做格式转换。

经验教训是：这类技能更适合先把脚本跑通，再让 skill-creator 把脚本与说明一起“封装进 Skill”。你可以把流程拆成更可复用的“原子能力”：

  • 搜索/下载图标：一个脚本负责（输入关键词，输出 SVG）
  • 格式转换：另一个脚本负责（输入 SVG，输出多尺寸 PNG）

这样就能同时兼容“只想转格式”和“需要从零找图标”两种场景，而不是被一个大而全脚本绑死。

参考（文字版）：https://mp.weixin.qq.com/s/7VUIzD0tnkImN8atADEGRg

在扣子中制作 Skills（自然语言对话 + 云端沙盒）

扣子这类平台的优势是门槛更低：你可以先用自然语言把“需求 → 技能 → 调试 → 部署”跑通，再逐步把规则写得更严谨、更可复用。

案例一：一次性提示词生成「中英文混合排版优化」Skill

典型痛点：中文与【英文/数字】之间需要保留 1 个半角空格，手动改很重复。它特别适合做成 Skill，因为规则明确、可批量复用。

制作要点同样是 4 件事：用途、触发方式、输出要求、所需资源。然后在右侧调试区用多份真实文本测试：

  • 稳定触发：在用户说“帮我优化中英文内容排版”等表达时是否能加载技能
  • 稳定执行：是否能一致地补空格、且不引入额外格式破坏

完成后部署上线，即可在对话中直接调用。

案例二：多轮对话得到满意产物，再“固化为 Skill”

当你一开始说不清楚规范时，可以先用多轮对话把产物打磨到满意（例如：初翻 → 译后审校 → 最终润色），然后再让平台把“对话流程”总结并打包成 Skill。

需要注意的是：对话固化时可能会丢失细节（平台会做摘要/归纳），因此最终一定要用新样例做回归测试，必要时把关键规则（术语表、语体要求、输出结构）显式写进 Skill 里。

一个比较稳的做法是把“审校维度”和“术语表”明确下来，让 Skill 有可复用的约束条件。例如审校维度可以固定为：准确性、流畅性、风格适配、术语统一；术语表可以作为可选输入参数传入（或固化在 references/ 中）。示例术语映射（节选）：

  • AGI → 通用人工智能
  • LLM/Large Language Model → 大语言模型
  • Generative AI → 生成式 AI
  • AI Agent → AI 智能体
  • few-shot → 少样本学习
  • fine-tuning → 微调
  • Agent Skills → Agent Skills
  • Skills → Skills

同时把输出结构写死也很重要，例如固定输出为：原始译文 + 审校报告 + 润色后的最终译文。这样测试时更容易判断“有没有漏步骤/跑偏”。

另外，云端平台通常会提供版本记录与回滚能力：当你某次迭代不满意时，可以直接回到上一版本，减少试错成本。

Skills 制作最佳实践（整理自官方建议）

这里的要点主要来自官方的“Skill authoring best practices”与渐进式披露思想，适合当作“写 Skill 的默认规范”。Skill authoring best practices

核心原则

  • 简洁是关键：只添加 AI 原本不知道、但对任务质量至关重要的上下文。
  • 设定适当的自由度：任务越脆弱/越容易出错，越应该减少自由度（更多脚本/更明确格式）；任务越开放，越可以保留弹性（更多原则/示例/边界条件）。

结构建议（SKILL.md 与资源层）

  • name 命名清晰：尽量用动名词/可执行动作表达（如 processing-pdfs、writing-documentation），避免 helper、documents 这类含糊名称。
  • description 写清“做什么 + 什么时候用”：让 agent 能稳定匹配触发条件。
  • 渐进式披露：SKILL.md 正文建议控制在 500 行以内；接近上限时，把长内容拆到 references/。
  • 资源层一层深度：资源文件建议放在与 SKILL.md 同级的一级目录（如 references/、scripts/），并且在 SKILL.md 中显式链接/引用，确保 agent “需要时能读到”。
  • 资源文件超过 100 行加目录：在文件顶部加 TOC，方便预览截断时仍能定位到信息。

工作流与反馈回路

  • 把复杂任务拆成清晰步骤：必要时提供可复制的检查清单，让 agent 执行时逐项勾选。
  • 引入反馈回路：用“运行验证器 → 修复错误 → 重复”的循环，显著提升稳定性与一致性。
  • 双 Agent 开发：用 Agent A 负责创建/修改 Skill，用 Agent B 负责黑盒测试与挑错，把问题再反馈给 Agent A 迭代。

发布前自检清单（可直接复用）

核心质量

  • description 具体，包含关键术语
  • description 同时包含“功能”与“使用时机”
  • SKILL.md 正文在 500 行以内
  • 长细节拆分到独立文件（如有需要）
  • 全 Skill 术语一致
  • 示例具体，不抽象
  • 文件引用保持一层深度
  • 渐进式披露使用得当
  • 工作流步骤清晰

代码与脚本

  • 脚本是为了解决问题，而不是把问题“推回给 Claude”
  • 错误处理清晰、可定位、提示有帮助
  • 没有“神秘常量”（所有关键值都有合理解释/来源）
  • 列出并验证所需依赖/软件包
  • 脚本文档清晰（如何运行、输入输出、失败模式）
  • 避免 Windows 风格路径（统一使用正斜杠 /，提升跨平台复用性）
  • 关键操作有验证步骤（例如生成文件后检查是否存在/尺寸是否正确）

测试

  • 至少用 3 个真实样例做评估
  • 在不同模型/配置上做过测试（如适用）
  • 覆盖真实使用场景与边界情况
  • 团队/同伴反馈已纳入（如适用）

什么任务值得做成 Skills？

一个更“工程化”的判断标准是：当你需要 Claude 持续、高效、稳定地执行某个特定任务时，就值得用 Skill 来固化流程。Skills explained

典型适用方向包括：

  • 组织工作流程：品牌指南、合规流程、文档模板
  • 专业领域：Excel 公式、PDF 处理、数据分析
  • 个人偏好：笔记系统、编码模式、研究方法

结合社区安装热度（如 skills.sh 的榜单）常见任务类型大致呈现如下分布（示例统计）：

类型 数量
增长/营销（SEO/CRO/投放/定价/增长策略） 23
软件工程：前端/全栈 UI 与最佳实践 19
内容生产（图文/幻灯片/图片/媒体处理/社媒分发） 17
工程方法论（计划/执行/协作/评审/调试等流程） 13
文档与办公（PDF/DOCX/PPTX/XLSX/文档协作） 8
Agent 工程（MCP/工具链/浏览器自动化等元技能） 5
软件工程：移动开发（Expo/RN/iOS/Android） 4
软件工程：DevOps/发布/CI/CD/依赖维护 4
软件工程：后端/API/数据与数据库 4
沟通与管理（会议/汇报/内部沟通） 2
软件工程：测试/质量保障/验证（偏测试方法） 1

从任务特征上看，值得做成 Skill 的任务通常落在三类（可重叠）：

  • 高频处理 + 可复用流程：步骤固定、目标明确（如 code review、CI/CD、SEO 审计）。
  • 强模板化产出：产物格式/风格强约束（如报告、周报、PPT、品牌设计）。
  • 多模块/多流程组合：需要串并联多个子流程（如社媒发布：选题 → 写作 → 配图 → 分发）。

最简单的二分法也很好用：一次性任务不值得做 Skill；需要反复做的任务，优先固化成 Skill。实践中建议遵循这个顺序：

  1. 手动跑通，沉淀标准：先手动执行几次，厘清固定步骤与高质量标准。
  2. 示范教学，封装 Skill：在支持 Skills 的工具里完整演示一遍，让 agent 把流程封装为 Skill。
  3. 循环使用，持续迭代：后续直接调用 Skill；每次输出后做校验，按反馈不断修正。

Skill 放哪儿？不同工具的常见落地点

同一个 Skill 的目录结构与 SKILL.md 格式是通用的（Agent Skills 标准），但各工具的“扫描路径”和“优先级”不同。

Claude Code

Claude Code 文档给出了清晰的层级与路径：个人级 ~/.claude/skills/<skill-name>/SKILL.md，项目级 .claude/skills/<skill-name>/SKILL.md，并支持用 /skill-name 显式调用。Extend Claude with skills

OpenAI Codex

Codex 支持从 .codex/skills（以及用户/管理员等多个层级）加载 skills，并支持显式/隐式调用两种模式。Agent Skills (Codex)

VS Code GitHub Copilot

VS Code 推荐把项目 skills 放在 .github/skills/（同时兼容 .claude/skills/ 作为 legacy），并且目前处于预览阶段，需要开启 chat.useAgentSkills。Use Agent Skills in VS Code

Cursor

Cursor 也提供了 Agent Skills 的落地文档，并且把“目录结构、触发方式、如何查看/安装/迁移”写得很具体。Agent Skills | Cursor Docs

1) 技能目录（项目级 vs 全局）

根据 Cursor 文档，Cursor 会自动从以下位置发现并加载技能（优先用 .cursor/skills/ 做项目级管理，兼容 .claude/skills/ 和 .codex/skills/ 便于跨工具复用）：Agent Skills | Cursor Docs

  • 项目级：.cursor/skills/
  • 项目级（兼容 Claude）：.claude/skills/
  • 项目级（兼容 Codex）：.codex/skills/
  • 用户级（全局）：~/.cursor/skills/
  • 用户级（全局，兼容 Claude）：~/.claude/skills/
  • 用户级（全局，兼容 Codex）：~/.codex/skills/

2) 创建一个项目级 Skill（推荐）

Cursor 推荐的最小目录结构如下（每个 Skill 是一个文件夹，包含 SKILL.md）：Agent Skills | Cursor Docs

1
2
3
4
.cursor/
  skills/
    meeting-minutes/
      SKILL.md

SKILL.md 的写法与 Agent Skills 标准一致（YAML frontmatter + Markdown 正文）。示例（内容建议用英文写清楚关键词，提升匹配命中率）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
---
name: meeting-minutes
description: Summarize meeting transcripts into attendees, agenda items, decisions, and action items. Use when the user asks for meeting minutes or a meeting summary.
---

## Output format
### Attendees
- <name>

### Agenda
1. <topic>

### Decisions
- <decision>

### Action Items
- <owner>: <task> (due: <date or TBD>)

3) 在 Cursor 里如何触发 Skills

Cursor 文档明确了两种方式：Agent Skills | Cursor Docs

  • 自动触发：Cursor 启动时会发现并加载技能，Agent 会“看到”所有技能，并根据当前上下文决定何时调用。
  • 手动触发：在 Agent 对话中输入 /，搜索技能名称并显式调用。

如果你希望把某个 Skill 变成“只允许手动调用”的斜杠命令效果，可以在 frontmatter 里加 disable-model-invocation: true，这样它只有在 /skill-name 显式调用时才会被包含进上下文。Agent Skills | Cursor Docs

4) 如何在 Cursor UI 里查看已发现的 Skills

Cursor 提供了一个查看入口，便于排查“为什么我写了 Skill 但 Agent 没用”：Agent Skills | Cursor Docs

  1. 打开 Cursor Settings（Windows/Linux：Ctrl+Shift+J）
  2. 进入 Rules
  3. 技能会显示在 Agent Decides 部分

5) 从 GitHub 安装/导入 Skills（团队共享）

如果你想把 skills 放在一个 GitHub 仓库里共享给团队，Cursor 文档给出的操作路径是：Agent Skills | Cursor Docs

  1. Cursor Settings → Rules
  2. 在 Project Rules 部分点击 Add Rule
  3. 选择 Remote Rule (Github)
  4. 输入 GitHub 仓库 URL

6) 从 Rules/Slash Commands 迁移到 Skills（Cursor 2.4+）

如果你之前已经积累了不少“动态规则（Apply Intelligently）”或斜杠命令，Cursor 2.4 内置了 /migrate-to-skills，可以辅助迁移到 .cursor/skills/。Agent Skills | Cursor Docs

文档也给了迁移的边界条件（建议迁移前先读一遍，避免误解）：例如 alwaysApply: true 或带特定 globs 的规则不会被迁移；用户规则也不会被迁移（因为不存储在文件系统中）。Agent Skills | Cursor Docs

共享/可复用的 Agent Skills 项目（GitHub）

如果你不想从零写 Skill，最实用的方式就是“先复用、再改成自己的版本”。这里把你列出的 GitHub 项目按定位做了分组，并给出我建议的阅读顺序（先官方/准官方 → 再精选合集 → 最后按领域挑专用 skills）。

注意：无论从哪里拉取 skills，都建议先人工 Review 一遍 SKILL.md 与 scripts/，特别是会产生副作用的脚本（发请求、改配置、部署、删数据等）。必要时把这类技能设为 disable-model-invocation: true，只允许手动触发。

0) Skills 目录站（可检索/发现）

1) 官方/准官方 Skills Catalog（优先看）

2) 社区“技能包/技能合集”（适合快速找灵感/模板）

3) 面向特定产品/工程场景的 Skills（更“即插即用”）

4) AutoGen Studio（可直接复制粘贴的 skills）

5) 在 Cursor 里复用这些仓库的推荐姿势

结合 Cursor 的 skills 目录约定（项目级 .cursor/skills/ + 全局 ~/.cursor/skills/）以及其 GitHub 导入入口，你通常有两种落地方式：Agent Skills | Cursor Docs

  1. 直接复制某个 skill 文件夹到你的项目里（最稳、最可控）：
1
2
3
# Copy a skill folder into your project-level skills directory
mkdir -p .cursor/skills
cp -R /path/to/repo/skills/<skill-name> .cursor/skills/
  1. 用 Cursor 的 GitHub 导入入口做团队共享：Cursor Settings → Rules → Project Rules → Add Rule → Remote Rule (Github)，把 skills 仓库当作“可版本控制的共享来源”。

6) 实用 Skills 推荐（案例向）

下面这些是我认为“上手就能用、并且很适合拿来学习工作流拆解”的技能。它们覆盖了 UI 设计、头脑风暴/方案设计、上下文工程、自动循环执行、个人知识库写作、笔记体系、React 工程规范、浏览器自动化，以及“用 Skill 来创建 Skill”等方向。

提醒：一些技能仓库会带 scripts/ 或插件机制（hooks/stop hook）。首次使用前建议先扫一遍代码，明确它会不会产生副作用（发请求、写文件、改 git、执行命令等）。

1) frontend-design（UI 设计风格纠偏）

适合用来“纠正 AI 总爱出紫色渐变 UI”的问题，尤其在你想要更现代、更克制、更像真实产品的前端设计时很有效。

2) superpowers（把头脑风暴与工程化流程做成“固定工作流”）

它解决的不是“会不会写代码”，而是“方案设计阶段问得够不够细、够不够准”，并且把从设计到开发、测试、评审的流程做成了可复用的工作流模板，非常值得当作“团队标准流程”的参考。

  • Superpower skills：https://github.com/obra/superpowers
  • 工作流亮点（值得抄作业）：
    • brainstorming：结构化对话把粗想法变成可落地设计，探索多方案、权衡、增量验证
    • using-git-worktrees：用 git worktrees 隔离不同功能分支，避免互相干扰
    • writing-plans：把工作拆到具体文件路径、完整代码与验证步骤
    • 执行开发：可选子代理驱动开发（任务间审查）或批量执行计划（人工分批审批）
    • test-driven-development：强制 RED-GREEN-REFACTOR，防止过度设计并确保每步可验证
    • requesting-code-review：按严重等级输出审查问题（Critical/Important/Minor）
    • finishing-a-development-branch：收尾合并/PR/保留/丢弃，并清理 worktrees

3) planning-with-files（用文件系统做“外部工作记忆”）

这是典型的“上下文工程”思路：把阶段计划、研究记录、最终交付拆成独立文件，让 agent 在长任务里不容易漂移，也更容易断点续跑。

4) ralph-loop / ralph-wiggum（循环执行：一次启动，自动迭代到目标）

ralph-loop 是 Anthropic 官方插件仓库里的循环执行器，核心思路是用 Stop Hook 拦截退出，并把相同提示词再次喂回去，让 Claude Code 反复迭代（读代码、看 git、修测试）直到达成目标或达到预设次数。

5) notebooklm-skill（把 NotebookLM 的“知识库能力”带到支持 Skills 的工具）

适合 AI 写作、以及任何需要高质量 RAG/知识库的场景：你可以把资料组织在 NotebookLM/类似体系里，再用 Skill 把能力带到 Claude Code 等支持 Skills 的工具中。

6) obsidian-skills（把 Obsidian 工作流技能化）

Obsidian 团队/社区围绕“如何让 AI 更好地融入 Obsidian”做了很实用的技能集合，尤其适合做知识管理、知识可视化与结构化笔记。

  • Obsidian Skills：https://github.com/kepano/obsidian-skills
  • 包含的代表性技能：
    • Obsidian Markdown Skill：输出 Obsidian 风格 Markdown（wikilinks、embeds、callouts、properties 等）
    • Obsidian Bases Skill：把笔记变成数据库（表格/卡片/列表/地图等视图）
    • JSON Canvas Skill：用 Canvas 做思维导图/流程图，更适合知识可视化

7) react-best-practices（Vercel 的 React 工程“经验浓缩包”）

如果你在做 React 项目（尤其是 Next.js 生态），这类“最佳实践 Skill”比泛化建议更稳定，适合当作 code review 的“默认标准”。

8) agent-browser（轻量交互式浏览器壳层）

适合一次性任务或简单自动化：相对“重量级的浏览器自动化方案”，它更轻、交互成本更低，很多情况下也更省 token。

9) skill-creator（用 Skill 来创建 Skill）

这是 Anthropic 官方提供的“创建 Skill 的 Skill”。你后面如果要批量沉淀团队工作流，强烈建议先用它做一次标准化的目录结构与写法练习，再逐步形成自己的模板。

7) 高质量 Skills 资源库（用来“找技能/学写法/抄工作流”）

除了本文前面列出的官方/社区仓库，这里补充一批我认为质量更稳定、覆盖更广、也更适合检索的资源库与目录站：

Claude / Anthropic 官方与准官方

awesome-claude-skills（合集类索引）

GitHub 的 awesome 系列通常是“找灵感/找同类方案”的最快入口，这里是多个 stars 较高的合集：

skillsmp（超大规模收录 + 语义搜索）

目前收录量非常大，并支持语义搜索与筛选/排序，适合“我知道我想要什么能力，但不知道技能叫啥”的场景。

skills.sh（安装排行榜 + 快速安装生态）

把多个技能项目整合成网站，并提供安装排行榜（总榜/24h 榜），适合快速捕捉近期热门技能。

科研方向资源库（垂直领域）

如果你是科研/工程研究方向，这个集合覆盖了很多学科的技能模板与流程。

个人高质量工作流仓库（适合学拆解）

个人开发者的技能仓库往往更“工作流导向”，特别适合学习如何把真实生产流程拆成可复用的 Skill。

moltbot（clawbot）生态技能索引

如果你在用 moltbot（原 clawbot）相关生态，这个索引比较集中：

Skill vs MCP：到底该选哪个？

视频引用了 Anthropic 的一句话，非常精准：Skills explained

MCP connects Claude to data; Skills teach Claude what to do with that data.

把它翻译成工程视角就是：

  • MCP：解决“连得上”——把 agent 接到数据源/业务系统/工具上，让它能读写、能查、能操作。
  • Skills：解决“会做事”——把流程、规范、模板、判断规则固化下来，让 agent 用一致的方法处理数据并产出结果。

选型建议（实践向）

  1. 如果你现在的问题是“模型总是忘了规则/输出不稳定/每次都要贴提示词”——优先写 Skill。
  2. 如果你现在的问题是“模型拿不到数据/无法执行操作/需要对接系统”——优先上 MCP。
  3. 如果你要做的是“既要拿数据，又要按公司流程处理并输出”——Skill + MCP 组合通常最强：MCP 负责连接与能力暴露，Skill 负责步骤、格式、合规、边界条件。

常见坑与最佳实践清单

  • name/目录名不一致：规范要求 name 必须匹配父目录名，且必须小写+连字符。Agent Skills Specification
  • description 太泛：description 应该同时描述“做什么”和“什么时候用”，并包含关键词以便检索与匹配。Agent Skills Specification
  • 多个 Skill 意图相近导致误触发：当你安装了多个“功能看起来差不多”的技能时，如果触发条件写得不够具体，就可能调用错 Skill。解决方式是收敛 description、补充更明确的触发语句与关键词，必要时对某些技能启用 disable-model-invocation: true 只允许手动调用。
  • SKILL.md 太长：把长材料拆到 references/，保持主文件精炼，避免触发后上下文暴涨。Agent Skills Specification
  • 带副作用的 Skill 让模型自动触发：在 Claude Code 里可以用 frontmatter 控制自动触发（例如 disable-model-invocation: true），把“部署/提交/发布”等动作收回到人工显式调用。Extend Claude with skills
  • “对话固化为 Skill”信息丢失：云端平台把多轮对话总结为 Skill 时，可能会丢掉关键细节（术语表、输出结构、边界条件）。建议把关键规则写成显式约束（或下沉到 references/），并用新样例做回归测试。
  • 脚本依赖不清：脚本必须写清运行方式、依赖与错误提示，否则 agent 可能会退回去“读代码找怎么跑”，反而浪费上下文并引入风险（视频也提到了这一点）。Agent Skill 从使用到原理，一次讲清

总结

  • Agent Skill = 可移植的能力包：指令（SKILL.md）+ 参考资料（references/）+ 自动化脚本（scripts/）。
  • 渐进式披露是精髓：先元数据、再指令、最后按需资源，既复用又省上下文。
  • Skill vs MCP 不纠结：MCP 负责连接数据与工具，Skill 负责流程与规则；多数工程场景是组合拳。

参考资料

本文由 AI 辅助生成，如有错误或建议，欢迎指出。