提取

extract
分类通用
作者Alireza Rezvani
许可MIT
评分4.30/5
使用14.7K

/si:extract — 从模式创建技能

将重复出现的模式或调试方案转化为独立的、可移植的技能，以便安装到任何项目中。

用法

code
/si:extract <模式描述>                  # 交互式提取
/si:extract <模式> --name docker-m1-fixes       # 指定技能名称
/si:extract <模式> --output ./skills/            # 自定义输出目录
/si:extract <模式> --dry-run                     # 预览而不创建文件

何时提取

当满足以下任一条件时，该学习内容符合技能提取标准：

| 标准 | 信号 |
|---|---|
| 重复出现 | 同一问题出现在 2 个或更多项目中 |
| 非显而易见 | 需要实际调试才能发现 |
| 广泛适用 | 不绑定于某个特定的代码库 |
| 方案复杂 | 包含多个步骤且容易遗忘的修复方案 |
| 用户标记 | “将此保存为技能”、“我想复用这个” |

工作流

第一步：识别模式

阅读用户的描述。在自动记忆（auto-memory）中搜索相关条目：

bash
MEMORY_DIR="$HOME/.claude/projects/$(pwd | sed 's|/|%2F|g; s|%2F|/|; s|^/||')/memory"
grep -rni "<keywords>" "$MEMORY_DIR/"

如果在自动记忆中找到，则将这些条目作为素材。否则，直接使用用户的描述。

第二步：确定技能范围

询问（最多 2 个问题）：

  • “这解决了什么问题？”（如果尚不明确）

  • “是否应包含代码示例？”（如果适用）

第三步：生成技能名称

命名规则：

  • 小写，单词之间用连字符 - 分隔

  • 描述准确且简洁（2-4 个单词）

  • 示例：docker-m1-fixes, api-timeout-patterns, pnpm-workspace-setup

保留片段 —— 技能名称中不得出现：

  • claude

  • anthropic

对于关于 Claude Code 本身的技能，请使用 cc- 前缀：

  • ❌ claude-code-settings → ✅ cc-settings

  • ❌ claude-code-maintenance → ✅ cc-maintenance

  • ❌ claude-mcp-tools → ✅ cc-mcp-tools

  • ❌ claude-plugin-development → ✅ cc-plugin-development

在创建技能目录前，请对照此列表检查拟定名称。
如果存在保留片段，请对其进行转换（删除该片段或将 claude*/anthropic* 前缀替换为 cc-）并与用户确认。

第四步：创建技能文件

启动 skill-extractor 代理进行实际的文件生成。

代理将创建：

code
<skill-name>/
├── SKILL.md            # 包含 frontmatter 的主技能文件
├── README.md           # 面向人类的可读概览
└── reference/          # （可选）支持文档
    └── examples.md     # 具体示例和边缘情况

第五步：SKILL.md 结构

生成的 SKILL.md 必须遵循以下格式：

markdown
---
name: "skill-name"
description: "<单行描述>。适用场景：<触发条件>。"
---

<技能标题>


> 该技能解决问题的单行总结。


快速参考


| 问题 | 解决方案 |
|---------|----------|
| {{问题 1}} | {{解决方案 1}} |
| {{问题 2}} | {{解决方案 2}} |


问题描述


{{用 2-3 句话解释发生了什么问题以及为什么它不直观。}}


解决方案


方案 1：{{名称}} (推荐)


{{包含代码示例的分步指南。}}


方案 2：{{替代方案}}


{{适用于...}}

选项 1 不适用}}

权衡 (Trade-offs)

| 方案 | 优点 | 缺点 |
|----------|------|------|
| 选项 1 | {{pros}} | {{cons}} |
| 选项 2 | {{pros}} | {{cons}} |

边界情况 (Edge Cases)

  • {{边界情况 1 及其处理方式}}
  • {{边界情况 2 及其处理方式}}
code
### 第 6 步：质量门禁 (Quality gates)

在最终确定前，请验证：


  • [ ] SKILL.md 包含有效的 YAML frontmatter，且具有 name 和 description


  • [ ] name 与文件夹名称一致（小写，用连字符分隔）


  • [ ] name 不包含保留片段 claude 或 anthropic（Claude Code 技能请使用 cc- 前缀）


  • [ ] 描述中包含 "Use when:" 触发条件


  • [ ] 解决方案是自包含的（无需外部上下文）


  • [ ] 代码示例完整且可直接复制粘贴


  • [ ] 无项目特定的硬编码值（路径、URL、凭据）


  • [ ] 无不必要的依赖


第 7 步：报告
✅ 技能已提取：{{skill-name}}

创建的文件：
{{path}}/SKILL.md ({{lines}} 行)
{{path}}/README.md ({{lines}} 行)
{{path}}/reference/examples.md ({{lines}} 行)

安装：/plugin install (复制到你的 skills 目录)
发布：clawhub publish {{path}}

来源：MEMORY.md 第 {{n, m, ...}} 行的条目（已保留 —— 技能是可移植的，而内存是项目特定的）

code
## 示例


提取调试模式
/si:extract "修复 Apple Silicon 上因平台不匹配导致 Docker 构建失败的问题"
code
创建 docker-m1-fixes/SKILL.md，包含：

  • 平台不匹配的错误消息


  • 三种解决方案（构建标志、Dockerfile、docker-compose）


  • 权衡表


  • 关于 Rosetta 2 模拟的性能说明


提取工作流模式
/si:extract "在修改 OpenAPI 规范后始终重新生成 TypeScript API 客户端" ``

创建 api-client-regen/SKILL.md`，包含：

  • 为什么需要手动重新生成

  • 准确的命令序列

  • CI 集成代码片段

  • 常见失败模式

技巧

  • 提取那些在*另一个*项目中也能节省时间的模式
  • 保持技能聚焦 —— 每个技能只解决一个问题
  • 包含用户可能会搜索的错误消息
  • 通过在脱离原始上下文的情况下阅读该技能来测试 —— 它是否依然清晰易懂？