Claude Code /plugins 命令——Skill Creator 实测

适读人群：想自定义 Claude Code 工作流的开发者 | 阅读时长：约13分钟 | 核心价值：从真实需求出发，完整记录用 Skill Creator 制作一个自定义 skill 的过程

最开始用 Claude Code 的时候，我的工作流大概是这样的：打开终端、进项目目录、开始敲命令、让 Claude 帮我做事。

后来我发现一个问题：我每次让 Claude 做某些特定的事时，我都要打一段差不多的背景说明。

比如，我有一个内部的 API 设计规范——接口命名怎么规范、错误码怎么定义、分页参数怎么统一——每次让 Claude 帮我设计 API 的时候，我都要把这些规范粘贴给它，或者重复说一遍。

有一天我终于烦了。这种重复劳动本身就是在浪费时间。

然后我找到了 /plugins 命令。

---

/plugins 里有什么

在 Claude Code 里输入 /plugins，会打开插件管理界面。

里面主要有两部分：

一是已安装的 skills 列表，可以在这里管理、启用、禁用已装的 skill。

二是 Skill Creator，这是 Anthropic 官方出的工具，作用是帮你创建属于自己的 skill。

Skill Creator 的思路很直接：你告诉它你想做什么、触发条件是什么、希望 Claude 在这个场景下怎么行动，它帮你生成一个结构化的 skill 文件，然后你可以直接安装使用。

我做的第一个自定义 skill，就是解决我上面说的那个问题：API 设计规范注入。

---

从需求到 Skill：完整流程记录

需求梳理

在用 Skill Creator 之前，我先想清楚了这个 skill 要做什么：

• 触发时机：当我在对话里说"帮我设计 API"或者"设计一个接口"的时候
• 注入内容：我们内部的 API 设计规范（URL 命名规则、HTTP 方法使用规范、统一的请求/响应结构、错误码规范、分页规范）
• 希望的行为：Claude 在设计 API 时，自动遵循这些规范，不需要我每次说

这个需求很清晰，适合做成 skill。

用 Skill Creator 生成

打开 /plugins，选择 Skill Creator，它会引导你回答几个问题：

1. 这个 skill 的名字是什么？
2. 这个 skill 在什么时候应该被激活？
3. 当它被激活时，Claude 应该做什么、或者有什么不同的行为？
4. 有没有需要注入的固定上下文（比如规范文档、代码模板）？

我按照引导填了内容，Skill Creator 生成的初版 skill 文件大概是这样的结构：

name: api-design-standard
description: 注入内部 API 设计规范，在 API 设计任务中自动生效
triggers:
  - "设计 API"
  - "设计接口"
  - "help me design an API"
  - "create endpoint"
context: |
  ## 内部 API 设计规范 v2.1

  ### URL 命名规范
  - 使用复数名词表示集合资源：/users, /orders, /products
  - 使用连字符而非下划线：/user-profiles 而非 /user_profiles
  - 不在 URL 中包含动词，HTTP 方法本身就是动词
  - 版本号放在 URL 前缀：/api/v1/users

  ### HTTP 方法使用规范
  - GET：查询，幂等，不修改数据
  - POST：创建新资源，或执行复杂查询（如搜索）
  - PUT：完整替换资源
  - PATCH：部分更新资源
  - DELETE：删除资源

  ### 统一响应结构
  成功响应：
  {
    "code": 0,
    "message": "success",
    "data": { ... },
    "requestId": "uuid"
  }

  失败响应：
  {
    "code": 40001,
    "message": "参数校验失败",
    "details": [...],
    "requestId": "uuid"
  }

  ### 错误码规范
  - 4xxxx：客户端错误（40001 参数错误，40101 未授权，40301 权限不足，40401 资源不存在）
  - 5xxxx：服务端错误（50001 内部错误，50201 依赖服务不可用）

  ### 分页规范
  请求参数：pageNum（从1开始），pageSize（默认20，最大100）
  响应结构：total, pageNum, pageSize, list

behavior: |
  当用户请求设计 API 时：
  1. 先确认业务场景和资源类型
  2. 按照上述规范设计 URL 结构
  3. 给出完整的请求/响应示例，遵循统一响应结构
  4. 如果发现用户的要求与规范冲突，主动指出冲突点
  5. 给出 Spring Boot Controller 的代码骨架（非完整实现）

这个初版出来之后，我装上测试了一下，发现有几个问题。

第一轮测试和迭代

问题一：触发条件太窄

我说"帮我写一个查用户列表的接口"，它没触发。因为我没用"设计 API"这几个字。

修正：在 triggers 里加更多的触发词，包括"写接口"、"写一个接口"、"增加一个接口"。

问题二：behavior 里的步骤 5 不对

我不需要每次都要 Controller 骨架，有时候我只是想确认 URL 设计。这条规则让 Claude 每次都输出一大段代码，有点烦。

修正：把"给出 Spring Boot Controller 代码骨架"改成"如果用户需要代码示例，提供 Spring Boot Controller 骨架"，变成可选的。

问题三：context 里的规范太完整，有时候反而在强调不需要的细节

比如用户只是问"这个接口用 POST 还是 GET"，它会把整个规范都搬出来。

修正：在 behavior 里加一条"根据用户问题的具体焦点，有针对性地引用规范的相关部分，不需要每次输出完整规范"。

第二轮测试

改完之后重新测试，好多了。

测了几个场景：

• "帮我设计一个用户注册接口" — 给出了 URL、方法、请求体、响应结构，完全符合规范
• "这个接口该用 PUT 还是 PATCH" — 只回答了这一个问题，引用了相关规范，没有输出多余内容
• "帮我看看这个接口设计有没有问题"（然后粘贴了一个不符合规范的接口定义）— 它准确找出了两个不符合规范的地方，还说明了哪条规范被违反了

这个 skill 之后我几乎每天都在用，完全不需要再重复粘贴规范了。

---

另一个 Skill：提交信息规范

用 API 设计那个 skill 用顺手之后，我又做了一个：Git commit message 规范注入。

原因是我们团队的 commit 信息风格很乱，我在做 code review 的时候经常要改 commit message。我想让 Claude Code 在帮我提交代码的时候，自动遵循 Conventional Commits 格式。

这个 skill 相对简单，核心 context 就是 Conventional Commits 的规范：

name: git-commit-standard
description: 按照 Conventional Commits 规范生成提交信息
triggers:
  - "git commit"
  - "提交代码"
  - "帮我提交"
  - "生成提交信息"
context: |
  ## Git Commit Message 规范（Conventional Commits）

  格式：<type>(<scope>): <subject>

  type 取值：
  - feat: 新功能
  - fix: Bug 修复
  - docs: 文档更新
  - style: 代码格式（不影响功能）
  - refactor: 重构（不是新功能也不是 bug 修复）
  - perf: 性能优化
  - test: 测试相关
  - chore: 构建/依赖/工具变更

  scope 是可选的，描述影响范围，如 (user-service), (auth), (payment)

  subject 规范：
  - 不超过 50 个字符
  - 用祈使句，不用过去式（add, not added）
  - 中英文均可，但团队内统一

  示例：
  feat(user): add email verification on registration
  fix(payment): resolve duplicate charge on retry
  refactor(auth): extract token validation to middleware

behavior: |
  生成 commit message 时：
  1. 先分析 diff 或用户描述，判断变更类型
  2. 如果有多个变更类型，建议拆分 commit
  3. scope 根据实际改动的模块确定
  4. subject 简洁准确，不超过 50 字
  5. 如果变更复杂，在 subject 后加空行，写 body 说明

这个 skill 的价值不是让我少打几个字，是让团队的提交历史更整洁。

---

Skill Creator 有什么局限

用了一段时间，有几个局限是实际存在的：

触发词匹配有时候不准

Skill Creator 目前的触发机制是关键词匹配，不是语义匹配。所以你要尽量覆盖用户可能的表达方式，但总会有覆盖不到的情况。

context 长度有限制

如果你的规范文档很长（比如几千字），全部塞进 context 不现实，会影响 Claude 的整体响应质量。需要提炼出核心规则，而不是直接复制粘贴文档。

skill 之间可能冲突

我装了几个 skill 之后，发现在某些场景下，两个 skill 同时被触发，Claude 会有点不知道该听哪个。这种情况需要在 skill 设计上明确优先级，或者收窄触发条件。

---

什么样的需求适合做成 Skill

做了几个 skill 之后，我总结出一个判断标准：

适合做成 skill 的需求：

• 有固定的上下文需要反复注入（规范、模板、约束）
• 触发场景相对明确
• 期望的行为可以被明确描述

不适合做成 skill 的需求：

• 一次性的任务（直接给 Claude 说就行）
• 触发条件非常模糊的场景（Claude 会不知道要不要触发）
• 期望行为本身就很复杂、难以描述清楚的

Skill Creator 是个好工具，但不是所有问题都适合用它解决。把合适的需求做成 skill，能真正提升工作效率；把不合适的需求强行做成 skill，只会让你在维护上花更多时间。