extract

extract skill 概览

extract 的作用

extract 是一个 Skill Authoring 工具，用来把反复出现的修复方法、工作流、调试模式，或在项目中踩坑后总结出的经验，整理成可复用的 Claude skill。与其让有价值的知识埋在聊天记录或记忆里，extract skill 会帮助你把它封装成一个可迁移的 SKILL.md，其中包含清晰的触发条件、适用范围、执行流程、示例，以及可选的支持文件。

extract 最适合什么场景

当你已经解决过某个问题一两次，并希望 agent 以后能稳定复用同一套解决方案时，就适合使用 extract。它尤其适合工程团队、自我改进型 agent 配置，以及需要维护重复项目规范、调试方案、迁移步骤或特定工具流程的开发者。它不适合从一个模糊想法凭空发明全新的 skill；当这个模式已经有实际案例支撑时，extract 的效果最好。

这个 extract skill 的实用之处

extract 最有价值的部分在于它的判断逻辑：它会判断某个经验是否会重复出现、是否不够直观、是否具备较广泛适用性、是否复杂到容易遗忘，或者是否是用户明确要求沉淀的内容。这样可以避免把每一条笔记都做成 skill。它的流程还鼓励在编写前检查 Claude auto-memory，因此最终产出的 skill 可以基于真实的历史解决方案，而不是泛泛的提示词模板。

安装前需要了解什么

这个仓库路径下只有一个 SKILL.md，没有附带脚本、参考资料或辅助资源。因此 extract 安装起来很轻量，但也意味着你应预期它是一个由提示词驱动的编写流程，而不是带验证工具的自动生成器。如果你需要 lint、发布自动化或多文件脚手架，可能需要自行在这个 skill 外围补充。

如何使用 extract skill

extract 安装与仓库阅读路径

使用以下命令安装：

npx skills add alirezarezvani/claude-skills --skill extract

安装后，先阅读 SKILL.md；它是主要实现文件，包含命令模式、提取标准和编写流程。当前 skill 路径下没有 references/、resources/、rules/ 或 scripts/ 文件夹，因此不要期待还有隐藏工具。最重要的准备步骤，是确保你的 agent 能访问包含待提取模式的项目上下文或记忆条目。

实际调用 extract

推荐的命令形式是：

/si:extract <pattern description>
/si:extract <pattern> --name docker-m1-fixes
/si:extract <pattern> --output ./skills/
/si:extract <pattern> --dry-run

当你希望进行交互式提取时，使用 /si:extract。如果 skill 名称已经很明确，可以加 --name；如果你的项目把 skills 存在自定义目录，可以加 --output；如果想在创建文件前先审阅拟定结构，可以加 --dry-run。

把粗略想法改写成高质量的 extract 提示

一个较弱的提示是：

/si:extract make a skill for Docker problems

一个更好的提示是：

/si:extract We repeatedly fix Docker build failures on Apple Silicon by pinning platform, rebuilding base images, clearing stale buildx cache, and checking native dependency images. This came up in two Node projects and one Python service. Create a reusable troubleshooting skill with decision steps and examples. --name docker-apple-silicon-debugging --dry-run

更好的版本提供了重复出现的信号、上下文、平台、解决方案形态和目标产物。这能帮助 extract 写出触发条件准确的 skill，而不是生成一篇泛泛的 Docker 建议页。

推荐的 extract 使用流程

先描述已经解决的问题、出现的位置、症状、实际修复方式，以及这个解决方案为什么不显而易见。如果有可用记忆，让 skill 检查或基于记忆进行推理。然后在接受输出前审阅拟定范围：一个好的提取型 skill 应当有窄而明确的触发条件、可重复执行的步骤、已知约束，以及与未来请求相似的示例。如果第一版过于宽泛，让 agent 将它拆成更小的 skills，或只保留其中可复用的部分。

extract skill 常见问题

extract 适合 Skill Authoring 新手吗？

适合，前提是你已经有一个具体模式要封装。extract skill 对新手友好，因为它提供了判断某件事是否值得做成 skill 的标准，也提供了组织 SKILL.md 的流程。不过，新手应避免过早提取一次性修复。最好等到该方案很可能再次出现，或者细节复杂到一旦遗忘就会浪费时间时再提取。

extract 和普通提示词有什么不同？

普通提示词也可以让 Claude “write a skill”，但 extract 给 agent 提供的是一套可重复的编写流程：识别模式、检查支持性记忆、确定范围，并生成可复用的 skill 内容。它的价值在于一致性。你不只是在生成文档，而是在创建一个可安装的行为包，让未来的 agents 能通过清晰描述触发它。

什么时候不该使用 extract？

不要用 extract 处理项目专属机密、临时 workaround、不完整假设，或依赖某个私有代码库且没有可复用逻辑的流程。若内容更适合作为一小段 README 说明、shell alias、测试或脚本，也不应使用它。skill 最适合 agent 需要进行流程判断的场景；如果一个确定性的命令就能解决问题，skill 的价值反而不高。

extract 会创建完整的多文件 skill 包吗？

它可以指导你创建一个独立 skill，包括 SKILL.md、示例和必要的参考文档，但当前仓库证据只显示有核心 skill 文件。应把 extract 视为一种编写工作流，而不是完整的脚手架框架。如果你的组织要求特定元数据、测试或发布步骤，请把这些要求写进提示中。

如何改进 extract skill

给 extract 提供证据，而不只是结论

当输入中包含原始失败模式、尝试过但失败的方法、最终修复方案，以及问题重复出现的证据时，extract skill 的产出会更好。例如，“we solved this in three repos after OAuth redirects broke behind a proxy” 比 “make an OAuth proxy skill” 更有用。证据能帮助 agent 判断触发条件、警告事项，以及可复用指导和本地实现细节之间的边界。

在接受 skill 前控制范围

最常见的失败模式，是提取出来的 skill 过于宽泛，例如 “Kubernetes debugging”、“frontend performance” 或 “API design”。让 extract 明确说出未来在什么具体时刻应该激活这个 skill。好的范围更像是 “debug pnpm workspace dependency resolution after package moves” 或 “migrate GitHub Actions from Node 16 to Node 20”。范围越窄，未来调用越可靠。

用示例和反例提升输出质量

要求至少包含一个真实感强的使用示例，以及一个 “do not use this when…” 场景。示例会教 agent 如何应用这个 skill；反例则能防止误触发。对于共享 skill 库中的 extract 使用，这一点尤其重要，因为模糊的 skills 会制造噪音，并与更具体的 skills 竞争触发机会。

在第一版 extract 草稿后继续迭代

第一版输出后，重点检查四件事：触发条件是否清晰、步骤顺序是否合理、约束是否缺失，以及是否具备可迁移性。如果草稿默认依赖你当前的仓库结构，让它改写成更通用的版本。如果缺少验证步骤，让它补充能证明修复生效的检查。如果读起来像一篇博客文章，让 extract 将其改写成面向 agent 的操作说明，方便以后真正执行任务。