十问 Agent Skills：一场围绕 AI 编码新范式的深度研讨

十问 Agent Skills：一场围绕 AI 编码新范式的深度研讨 十问 Agent Skills：一场围绕 AI 编码新范式的深度研讨 Modified November 16, 2025 source: https://www.aitmpl.com/agents 在我看来， claude code template 正在做一件类似于 Next.js 对 React 做的事情——它首次将 Claude Code 的工程化实践统一到了一个标准里 。 它解决的核心问题是，未来 AI 编程将从“手工拼装”时代进入“ 组件化 + 自动化 ”时代。这个仓库就像一个巨大的“武器库”或者“商城”，你可以进去挑选你需要的各种组件，一键安装到你的工作流里。 我自己的工作流通常是这样： 1. 安装 CLI ：通过 npx claude code template@latest 命令安装。 2. 项目初始化 ：使用它内置的项目模板（如 React, Node.js, Python）快速生成项目骨架，它会自动帮你配置好项目结构、默认组件和 SDK。 3. 挑选组件 ：去它的线上市场挑选我需要的 Agents、Commands 或者 Skills，比如我今天的 PPT 就是用它提供的一个 pptx Skill，只花十分钟就做出来了。 4. 使用工具链 ：它还提供了一套强大的工具链。我最喜欢的是它的“分析仪表盘”和“健康检查”功能。 ◦ 分析仪表盘 ：它能读取你本地 Claude Code 的所有运行数据，生成一个可视化的 Web 界面，你甚至可以在手机上实时监控 AI 的工作进展。 ◦ 健康检查 ：每次启动一个新项目，我都会用它来检查项目的验证状态、兼容性、环境依赖和版本问题。 claude code template 的哲学是，它不是一个人闭门造车，而是鼓励全世界的工程师把遇到的问题用代码解决，然后开源共享。如果你写了一个很棒的 Skill ，可以直接提交到这个仓库，与全球的开发者分享。 南川 : lords 的分享非常有启发。这个项目让我看到了一个有趣的商业化可能性：做一个“GitHub 深度研究”的 SaaS。比如，当你想研究一个新的技术领域，如“笔记软件”，你在这个 SaaS 里输入关键词，它会自动去 GitHub 爬取所有相关的开源项目，按照 star 数、技术栈、功能特性等维度进行分析、排名，并生成一份详尽的研究报告。这本质上也是一种 template 或 Skill 的思想。 第六问：创建和调试 Skills 的具体流程是怎样的？有没有官方工具支持？ 南川 : Anthropic 官方代码库里其实提供了一个名为 skill creator 的 Skill 。它就是一个“Skill 生成器”，你可以用它来创建新的 Skill 。这是一种“元编程”的思路，用 Skill 来生成 Skill ，生成的 Skill 质量通常不会差。 source: https://github.com/anthropics/skills 一个标准的 Skill 文件夹结构包含： • SKILL.md : 核心文件，用 YAML Frontmatter 定义 name 和 description ，正文是给 Claude 的指令。 • meta 文件: 元数据。 • resources 文件夹: 存放各种资源，如脚本 ( scripts )、参考材料 ( references )、模板等。 李不凯 : 我目前创建的十个 Skill 基本都是用官方的 skill creator 写出来的。 至于调试，我的方法是一种 自我循环、持续迭代 的模式： 1. 在实际任务中使用一个 Skill 。 2. 发现它在某个环节做得不好，或者出错了。 3. 立即调用 skill creator 这个 Skill ，告诉它刚才遇到了什么问题，让它来修改原来的 Skill 。 4. 修改后，在下一个任务中继续使用，观察效果。 通过这样不断的“ 使用 发现问题 调用元 Skill 修正 再使用 ”的循环， Skill 的能力会变得越来越好，越来越贴合你的需求。 陈涵洋 : 我在使用 Skill 时发现一个痛点，就是 断点调试能力非常差 。如果 Skill 写错了，在错误发生时你几乎没有什么挽回措施。不知道大家有没有什么好的尝试？ 李不凯 : 这确实是一个问题，目前的调试主要还是依赖于我上面说的那种“事后复盘、迭代优化”的模式，缺乏实时的断点调试能力。 第七问：如何让 Claude 更“聪明”地、恰到好处地调用我们编写的 Skill？ 李不凯 : 这是我目前遇到的最大挑战之一。有时候，Claude 无法精准地判断用户的意图，导致该调用 Skill 的时候没调用，或者调用了错误的 Skill 。 为了解决这个问题，我尝试了一个方法，就是在系统级的 claude.md 文件里，把所有我创建的 Skill 的名称和它们对应的触发关键词都明确地列出来。 这么做之后，我感觉调用的成功率大概提升了一到两倍，但仍然无法做到 100% 的精准匹配。我也在思考，是不是可以把我的 Skill 命名规范化，比如按照“ 产品 功能 操作 ”的三段式来命名，也许能进一步提高调用的精准度。这个问题也希望能和大家一起探讨，看看有没有更好的办法。 伍鹏 : 模型在匹配规则时，是根据 语义相似度 来实现的。它会计算你的指令和每个 Skill 描述之间的“蕴含关系”。比如，当你的指令是“烹饪”，模型就会去寻找与“炊具”、“食材”、“烹饪方法”等概念相关的 Skill 。 它最终选择哪个 Skill ，取决于注意力机制计算出的权重得分。所以，就像南川老师一开始强调的， 尽可能保证每个 Skill 的描述都是正交的、相互独立的，避免在场景上产生混淆，这是提升调用准确率的根本 。 尤江彬 : 我在实际使用中发现，光靠 description 有时候是不够的。AI 对于“什么时候用”甚至“什么时候不用”的理解，还不够精确。 我自己摸索出的最佳实践是，在 Skill 的 .md 文件里， 明确地用自然语言告诉它 ：“在 A、B、C 场景下，你必须使用这个 Skill”、“在 X、Y、Z 情况下，你绝对不能用这个 Skill”。这种类似 SOP (Standard Operating Procedure) 的强约束，效果非常显著。 长期来看，虽然我们希望模型能通过微调或能力进化，自动理解这些微妙的边界，但短期内，这种显式的、规则化的指令约束，可能还是保证 Skill 调用符合预期的最可靠手段。 第八问：在 Cursor 这样的 AI IDE 中，Skills 的管理和调用逻辑是怎样的？它和 Claude Code 有什么异同？ 橙龙 : 我们团队大部分成员更习惯使用 Cursor ，因为它的用户粘性很强。我发现 Cursor 在规则管理上有一个优势，就是它提供了一套 分层、分级的规则调用机制 。 在 Cursor 的设置里，你可以添加规则 ( Rules )，并且为每条规则指定生效的条件： 1. 始终有效 (Always) ：在任何对话中都会启用。 2. AI 决定 (Agent Decides) ：由 Agent 自行判断当前对话是否与该规则相关。 3. 文件匹配 (On File Match) ：当对话涉及到匹配特定文件（如 .vue ）时才生效。 4. 手动触发 (Always Manually) ：只有当你手动 @ 它的时候才会生效。 我觉得 Claude Code 目前似乎缺少这种精细化的规则管理机制。比如，当一个场景下有多个 Skill 可能都适用时，如果能有一个机制让我手动指定本次对话强制使用某一个 Skill ，而不是让 AI 自己去猜，会大大增强可控性。 伍鹏 : 关于你提到的工作流编排问题，可以关注一下一个名为 Claude Flow 的库。我看到在很多开源的 Skill 实现中，都使用了这个库来对任务进行编排，掌控整个流程的执行顺序。 第九问：从社区分享的数据来看，Skills 主要被应用在哪些领域？呈现出怎样的发展趋势？ skills 技能分类全景，by 伍鹏 skills 复杂度分布，by 伍鹏 伍鹏 : 我在上个月做了一个 Skill 网站，因此收集并分析了 GitHub 上近 5800 个开源的 Skill 仓库数据，有一些有趣的发现： 1. 软件工程领域占据绝对主导 ：在所有 Skill 中，有超过 3750 个与软件工程相关，占比极高。这反映了目前 Skill 的主要创建者和使用者仍然是开发者群体。 2. “自动化”是核心诉求 ：在所有 Skill 的关键词中，“自动化 (automation)”出现了 1180 次，平均每五个 Skill 就有一个与自动化强相关。这说明，大家使用 Skill 的最主要目的，就是将重复性的工作自动化，比如每天编写文档、计算 Excel 表格、处理财务数据等。 3. 社区想象力远超官方 ：官方仓库提供的 Skill 更多是作为示例，或者对自己已有产品在新路径上的适配。而社区贡献的 Skill 则展现出了更丰富的多样性和想象力，涵盖了各种意想不到的组合和可能性。 4. 复杂度分布 ： ◦ 高阶 Skill (占比最小) ：拥有多种复杂能力组合，通常包含多个脚本和引用文件。 ◦ 中阶 Skill (占比接近一半) ：具备简单的引用文件，可能包含脚本。 ◦ 初阶 Skill (占比较多) ：只有一个 SKILL.md 文件，不含脚本，纯粹是模型能力的调用。 5. 技术栈偏好 ：在需要编写脚本的 Skill 中，创作者们普遍倾向于使用那些排名靠前、成熟且活跃的库，比如 git , pandas 以及前面提到的 claude flow 。大家更愿意使用经过验证的“轮子”，而不是重复发明。 我的一个观点是，虽然目前软件开发领域的 Skill 占主导，但这主要是因为数据来源是 GitHub。 Skill 作为一种通用的技术路径， 其未来巨大的拓展空间在于面向更广大的、非开发背景的用户群体 ，比如我的电商客户，他们需要处理大量重复性的运营工作，非常需要这种被解耦的、开箱即用的“技能包”。 第十问：放眼未来，Skills 这条技术路线将如何演进？它对国内大模型和开发者生态有何启示？ 尤江彬 : 我们作为面向公众提供通用智能体服务的产品，一个核心的顾虑是， Skill 这套机制非常依赖 Claude 自身模型的针对性微调，如果换成国内的模型，效果可能会大打折扣。 但我的怀疑是， 这本质上考验的是大模型对 SOP (标准作业程序) 这类语义的理解与严格遵循的能力 。这种能力本身应该是通用的，微调也许有用，但作用可能非常小。不知道各位大佬怎么看？ 李不凯 : 我最近的实践体验可以部分回答这个问题。我把我的“微信公众号写作” Skill 分别用三个模型跑了一遍： • Claude 4.5 : 基本能 100% 完美地按照我的指令执行下来，非常顺畅。 • Kimi : 大概能完成 85% 到 90% 的任务。 • 豆包 : 大概只能完成 60% 左右。 我个人的感觉是， Skill 这套理念和技术实现，其核心是简单和通用的，这也是它最大的价值所在。所以，切换到别的模型上，重点还是考验模型本身对于 指令遵循 (Instruction Following) 的能力。像 Kimi，它的指令遵循能力也很好，所以实现的效果和 Claude 就很接近。而豆包可能在这方面能力稍弱，所以效果打了折扣。 因此，我非常看好 Skill 能够成为一个业内通用的标准，未来在各个模型和 IDE 中都能得到很好的支持。 source: https://www.aitmpl.com/agents 在我看来， claude code template 正在做一件类似于 Next.js 对 React 做的事情——它首次将 Claude Code 的工程化实践统一到了一个标准里 。 它解决的核心问题是，未来 AI 编程将从“手工拼装”时代进入“ 组件化 + 自动化 ”时代。这个仓库就像一个巨大的“武器库”或者“商城”，你可以进去挑选你需要的各种组件，一键安装到你的工作流里。 我自己的工作流通常是这样： 1. 安装 CLI ：通过 npx claude code template@latest 命令安装。 2. 项目初始化 ：使用它内置的项目模板（如 React, Node.js, Python）快速生成项目骨架，它会自动帮你配置好项目结构、默认组件和 SDK。 3. 挑选组件 ：去它的线上市场挑选我需要的 Agents、Commands 或者 Skills，比如我今天的 PPT 就是用它提供的一个 pptx Skill，只花十分钟就做出来了。 4. 使用工具链 ：它还提供了一套强大的工具链。我最喜欢的是它的“分析仪表盘”和“健康检查”功能。 ◦ 分析仪表盘 ：它能读取你本地 Claude Code 的所有运行数据，生成一个可视化的 Web 界面，你甚至可以在手机上实时监控 AI 的工作进展。 ◦ 健康检查 ：每次启动一个新项目，我都会用它来检查项目的验证状态、兼容性、环境依赖和版本问题。 ◦ 分析仪表盘 ：它能读取你本地 Claude Code 的所有运行数据，生成一个可视化的 Web 界面，你甚至可以在手机上实时监控 AI 的工作进展。 ◦ 健康检查 ：每次启动一个新项目，我都会用它来检查项目的验证状态、兼容性、环境依赖和版本问题。 claude code template 的哲学是，它不是一个人闭门造车，而是鼓励全世界的工程师把遇到的问题用代码解决，然后开源共享。如果你写了一个很棒的 Skill ，可以直接提交到这个仓库，与全球的开发者分享。 南川 : lords 的分享非常有启发。这个项目让我看到了一个有趣的商业化可能性：做一个“GitHub 深度研究”的 SaaS。比如，当你想研究一个新的技术领域，如“笔记软件”，你在这个 SaaS 里输入关键词，它会自动去 GitHub 爬取所有相关的开源项目，按照 star 数、技术栈、功能特性等维度进行分析、排名，并生成一份详尽的研究报告。这本质上也是一种 template 或 Skill 的思想。 第六问：创建和调试 Skills 的具体流程是怎样的？有没有官方工具支持？ 南川 : Anthropic 官方代码库里其实提供了一个名为 skill creator 的 Skill 。它就是一个“Skill 生成器”，你可以用它来创建新的 Skill 。这是一种“元编程”的思路，用 Skill 来生成 Skill ，生成的 Skill 质量通常不会差。 source: https://github.com/anthropics/skills 一个标准的 Skill 文件夹结构包含： • SKILL.md : 核心文件，用 YAML Frontmatter 定义 name 和 description ，正文是给 Claude 的指令。 • meta 文件: 元数据。 • resources 文件夹: 存放各种资源，如脚本 ( scripts )、参考材料 ( references )、模板等。 李不凯 : 我目前创建的十个 Skill 基本都是用官方的 skill creator 写出来的。 至于调试，我的方法是一种 自我循环、持续迭代 的模式： 1. 在实际任务中使用一个 Skill 。 2. 发现它在某个环节做得不好，或者出错了。 3. 立即调用 skill creator 这个 Skill ，告诉它刚才遇到了什么问题，让它来修改原来的 Skill 。 4. 修改后，在下一个任务中继续使用，观察效果。 通过这样不断的“ 使用 发现问题 调用元 Skill 修正 再使用 ”的循环， Skill 的能力会变得越来越好，越来越贴合你的需求。 陈涵洋 : 我在使用 Skill 时发现一个痛点，就是 断点调试能力非常差 。如果 Skill 写错了，在错误发生时你几乎没有什么挽回措施。不知道大家有没有什么好的尝试？ 李不凯 : 这确实是一个问题，目前的调试主要还是依赖于我上面说的那种“事后复盘、迭代优化”的模式，缺乏实时的断点调试能力。 第七问：如何让 Claude 更“聪明”地、恰到好处地调用我们编写的 Skill？ 李不凯 : 这是我目前遇到的最大挑战之一。有时候，Claude 无法精准地判断用户的意图，导致该调用 Skill 的时候没调用，或者调用了错误的 Skill 。 为了解决这个问题，我尝试了一个方法，就是在系统级的 claude.md 文件里，把所有我创建的 Skill 的名称和它们对应的触发关键词都明确地列出来。 这么做之后，我感觉调用的成功率大概提升了一到两倍，但仍然无法做到 100% 的精准匹配。我也在思考，是不是可以把我的 Skill 命名规范化，比如按照“ 产品 功能 操作 ”的三段式来命名，也许能进一步提高调用的精准度。这个问题也希望能和大家一起探讨，看看有没有更好的办法。 伍鹏 : 模型在匹配规则时，是根据 语义相似度 来实现的。它会计算你的指令和每个 Skill 描述之间的“蕴含关系”。比如，当你的指令是“烹饪”，模型就会去寻找与“炊具”、“食材”、“烹饪方法”等概念相关的 Skill 。 它最终选择哪个 Skill ，取决于注意力机制计算出的权重得分。所以，就像南川老师一开始强调的， 尽可能保证每个 Skill 的描述都是正交的、相互独立的，避免在场景上产生混淆，这是提升调用准确率的根本 。 尤江彬 : 我在实际使用中发现，光靠 description 有时候是不够的。AI 对于“什么时候用”甚至“什么时候不用”的理解，还不够精确。 我自己摸索出的最佳实践是，在 Skill 的 .md 文件里， 明确地用自然语言告诉它 ：“在 A、B、C 场景下，你必须使用这个 Skill”、“在 X、Y、Z 情况下，你绝对不能用这个 Skill”。这种类似 SOP (Standard Operating Procedure) 的强约束，效果非常显著。 长期来看，虽然我们希望模型能通过微调或能力进化，自动理解这些微妙的边界，但短期内，这种显式的、规则化的指令约束，可能还是保证 Skill 调用符合预期的最可靠手段。 第八问：在 Cursor 这样的 AI IDE 中，Skills 的管理和调用逻辑是怎样的？它和 Claude Code 有什么异同？ 橙龙 : 我们团队大部分成员更习惯使用 Cursor ，因为它的用户粘性很强。我发现 Cursor 在规则管理上有一个优势，就是它提供了一套 分层、分级的规则调用机制 。 在 Cursor 的设置里，你可以添加规则 ( Rules )，并且为每条规则指定生效的条件： 1. 始终有效 (Always) ：在任何对话中都会启用。 2. AI 决定 (Agent Decides) ：由 Agent 自行判断当前对话是否与该规则相关。 3. 文件匹配 (On File Match) ：当对话涉及到匹配特定文件（如 .vue ）时才生效。 4. 手动触发 (Always Manually) ：只有当你手动 @ 它的时候才会生效。 我觉得 Claude Code 目前似乎缺少这种精细化的规则管理机制。比如，当一个场景下有多个 Skill 可能都适用时，如果能有一个机制让我手动指定本次对话强制使用某一个 Skill ，而不是让 AI 自己去猜，会大大增强可控性。 伍鹏 : 关于你提到的工作流编排问题，可以关注一下一个名为 Claude Flow 的库。我看到在很多开源的 Skill 实现中，都使用了这个库来对任务进行编排，掌控整个流程的执行顺序。 第九问：从社区分享的数据来看，Skills 主要被应用在哪些领域？呈现出怎样的发展趋势？ skills 技能分类全景，by 伍鹏 skills 复杂度分布，by 伍鹏 伍鹏 : 我在上个月做了一个 Skill 网站，因此收集并分析了 GitHub 上近 5800 个开源的 Skill 仓库数据，有一些有趣的发现： 1. 软件工程领域占据绝对主导 ：在所有 Skill 中，有超过 3750 个与软件工程相关，占比极高。这反映了目前 Skill 的主要创建者和使用者仍然是开发者群体。 2. “自动化”是核心诉求 ：在所有 Skill 的关键词中，“自动化 (automation)”出现了 1180 次，平均每五个 Skill 就有一个与自动化强相关。这说明，大家使用 Skill 的最主要目的，就是将重复性的工作自动化，比如每天编写文档、计算 Excel 表格、处理财务数据等。 3. 社区想象力远超官方 ：官方仓库提供的 Skill 更多是作为示例，或者对自己已有产品在新路径上的适配。而社区贡献的 Skill 则展现出了更丰富的多样性和想象力，涵盖了各种意想不到的组合和可能性。 4. 复杂度分布 ： ◦ 高阶 Skill (占比最小) ：拥有多种复杂能力组合，通常包含多个脚本和引用文件。 ◦ 中阶 Skill (占比接近一半) ：具备简单的引用文件，可能包含脚本。 ◦ 初阶 Skill (占比较多) ：只有一个 SKILL.md 文件，不含脚本，纯粹是模型能力的调用。 ◦ 高阶 Skill (占比最小) ：拥有多种复杂能力组合，通常包含多个脚本和引用文件。 ◦ 中阶 Skill (占比接近一半) ：具备简单的引用文件，可能包含脚本。 ◦ 初阶 Skill (占比较多) ：只有一个 SKILL.md 文件，不含脚本，纯粹是模型能力的调用。 5. 技术栈偏好 ：在需要编写脚本的 Skill 中，创作者们普遍倾向于使用那些排名靠前、成熟且活跃的库，比如 git , pandas 以及前面提到的 claude flow 。大家更愿意使用经过验证的“轮子”，而不是重复发明。 我的一个观点是，虽然目前软件开发领域的 Skill 占主导，但这主要是因为数据来源是 GitHub。 Skill 作为一种通用的技术路径， 其未来巨大的拓展空间在于面向更广大的、非开发背景的用户群体 ，比如我的电商客户，他们需要处理大量重复性的运营工作，非常需要这种被解耦的、开箱即用的“技能包”。 第十问：放眼未来，Skills 这条技术路线将如何演进？它对国内大模型和开发者生态有何启示？ 尤江彬 : 我们作为面向公众提供通用智能体服务的产品，一个核心的顾虑是， Skill 这套机制非常依赖 Claude 自身模型的针对性微调，如果换成国内的模型，效果可能会大打折扣。 但我的怀疑是， 这本质上考验的是大模型对 SOP (标准作业程序) 这类语义的理解与严格遵循的能力 。这种能力本身应该是通用的，微调也许有用，但作用可能非常小。不知道各位大佬怎么看？ 李不凯 : 我最近的实践体验可以部分回答这个问题。我把我的“微信公众号写作” Skill 分别用三个模型跑了一遍： • Claude 4.5 : 基本能 100% 完美地按照我的指令执行下来，非常顺畅。 • Kimi : 大概能完成 85% 到 90% 的任务。 • 豆包 : 大概只能完成 60% 左右。 我个人的感觉是， Skill 这套理念和技术实现，其核心是简单和通用的，这也是它最大的价值所在。所以，切换到别的模型上，重点还是考验模型本身对于 指令遵循 (Instruction Following) 的能力。像 Kimi，它的指令遵循能力也很好，所以实现的效果和 Claude 就很接近。而豆包可能在这方面能力稍弱，所以效果打了折扣。 因此，我非常看好 Skill 能够成为一个业内通用的标准，未来在各个模型和 IDE 中都能得到很好的支持。 南川 : 这场研讨会让我们看到了 Agent Skills 背后的巨大潜力与现实挑战。它不仅是一个新工具，更像是一个新的“思想容器”，让我们可以将抽象的知识、重复的流程、宝贵的经验，固化成可调用、可组合、可迭代的 AI “能力单元”。 从 Prompt 到 Skill ，从 MCP 的外部调用到 Skill 的本地深耕， 我们正处在一个 AI 开发范式剧烈变革的时代 。未来，每一位开发者或许都将拥有一个属于自己的、不断进化的“技能库”，而衡量一个开发者能力的，除了代码本身，或许还要看他“教会”了 AI 多少独特的 Skills 。 这场对话只是一个开始，我们期待看到更多开发者加入到 Skills 的探索与创造中来，共同塑造 AI Native 开发的未来。 注 • Anthropic 官方对 skills 的标准定义是 「Agent Skills」（不局限于Claude Code），因此对原会议中所有「Claude Code Skills」做了修正，统一使用 Agent Skills，具体可以见：Introducing Agent Skills | Claude [1] 。 • 本场研讨会所涉及外部资料： ◦ 官方文档： ▪ 介绍：Agent Skills Claude Docs [2] ▪ 区别：Skills explained: How Skills compares to prompts, Projects, MCP, and subagents | Claude [3] ▪ 最佳实践：Skill authoring best practices Claude Docs [4] ▪ 开发指引：Agent Skills Claude Code Docs [5] ◦ 仓库 ▪ 官方：anthropics/skills: Public repository for Skills [6] ▪ awesome：travisvn/awesome claude skills: A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows — particularly Claude Code [7] ▪ claude code template: davila7/claude code templates: CLI tool for configuring and monitoring Claude Code [8] ◦ 独立站： ▪ Claude Skills Marketplace & Hub | Anthropic Skills Repository [9] ▪ Claude Code Templates Supercharge Your AI Powered Development with Anthropic's Claude Code [10] ◦ 官方文档： ▪ 介绍：Agent Skills Claude Docs [2] ▪ 区别：Skills explained: How Skills compares to prompts, Projects, MCP, and subagents | Claude [3] ▪ 最佳实践：Skill authoring best practices Claude Docs [4] ▪ 开发指引：Agent Skills Claude Code Docs [5] ▪ 介绍：Agent Skills Claude Docs [2] ▪ 区别：Skills explained: How Skills compares to prompts, Projects, MCP, and subagents | Claude [3] ▪ 最佳实践：Skill authoring best practices Claude Docs [4] ▪ 开发指引：Agent Skills Claude Code Docs [5] ◦ 仓库 ▪ 官方：anthropics/skills: Public repository for Skills [6] ▪ awesome：travisvn/awesome claude skills: A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows — particularly Claude Code [7] ▪ claude code template: davila7/claude code templates: CLI tool for configuring and monitoring Claude Code [8] ▪ 官方：anthropics/skills: Public repository for Skills [6] ▪ a