AI Agent Skills 技能库：选型、离线归档与安全迁移

技能（Skill）不是一个神奇插件，也不天然可信。它通常是带有 SKILL.md 的目录，可能还包含脚本、模板和参考资料；它会影响模型如何完成任务，附带脚本则可能直接读写文件、启动进程或访问网络。因此先把技能当成第三方代码审查，再决定是否放进会自动加载的目录。星标反映关注度，不代表安全、兼容性或维护质量。

技能库从哪里开始

不建议按星标做一份“最强技能排行榜”。更实用的目录字段是：用途、目标客户端、来源 URL、作者、固定 commit/tag、许可证、最后审阅日期、是否含可执行脚本、联网/文件权限、验证结果和回滚版本。热门项目只作为候选池。

个人技能目录分层

把下载、审阅、启用分成三层，避免新拉取的内容立刻进入自动加载路径：

~/Knowledge/agent-skills/
  sources/       # 带上游 Git 历史的只读镜像或浅克隆
  reviewed/      # 已审阅、固定版本的技能副本
  manifests/     # 来源、commit、许可、审阅日期和校验和
  quarantine/    # 尚未检查或存在可疑行为的内容

客户端实际技能目录可能是 ~/.codex/skills、某个项目内的 .agents/skills，或其他产品自己的路径。先查当前版本的官方说明；只把选中的技能安装到对应目录，不要把整个候选仓库或上游 .git 目录塞进自动发现目录。对具体客户端进行迁移时，记录来源路径与安装目标，避免机器间产生多个互相覆盖的副本。

先下载，再审阅，再启用

对公开 Git 仓库，先固定来源和 revision。以下命令只创建本地资料副本，不执行仓库代码：

git clone --filter=blob:none https://github.com/anthropics/skills.git ~/Knowledge/agent-skills/sources/anthropics-skills
git -C ~/Knowledge/agent-skills/sources/anthropics-skills rev-parse HEAD
git -C ~/Knowledge/agent-skills/sources/anthropics-skills status --short
find ~/Knowledge/agent-skills/sources/anthropics-skills -name SKILL.md -print

不要把示例中的 main 当作可复现版本。记录 rev-parse HEAD 输出的完整 commit；挑选单个技能后，先只读其 SKILL.md、引用文件、脚本、依赖清单和许可证，再拷贝到 reviewed/。启用前对照所需工具和数据范围，拒绝不必要的 shell、网络、浏览器配置目录、SSH key、云凭据或全盘文件访问。

人工安全审查表

• 指令范围：是否要求忽略用户/系统要求、隐藏行为、外传数据、伪造结果或调用未说明的工具？出现这类要求立即隔离并检查完整上下文。
• 脚本行为：搜索网络请求、子进程、动态执行、下载后执行、凭据读取、递归删除、覆盖写入和权限提升；阅读完整调用链，不只看文件名。
• 输入与输出：是否把用户内容拼入 shell 命令、SQL、HTML 或模板？是否能覆盖仓库外文件？是否会把日志或环境变量发往第三方？
• 依赖与供应链：锁定依赖版本，确认来源、许可证和安装脚本；不在含真实密钥的主机或个人主目录直接试运行陌生技能。
• 权限最小化：优先在临时副本、无凭据账户、网络关闭或受限环境验证。需要网络时记录目的域名、请求内容与退出行为。
• 验收与回滚：使用合成数据验证成功路径、异常路径、文件改动范围和网络副作用；保存启用前版本，能恢复旧目录并复验 Agent 不再发现新技能。

Skill 文件的指令属于不可信输入，不应覆盖更高优先级的安全要求。即使纯文本技能没有脚本，也可能诱导 Agent 执行高风险命令；代码沙箱不能代替指令审查。

更新、固定版本与换机

固定版本的副本不要自动 git pull。更新时在 sources/ 拉取新提交，比较上游差异，重新审查变化过的指令、脚本、依赖和许可，再生成新的 manifest 与校验和。测试通过后才替换 reviewed/，并保留上一个可用 revision 作为回滚点。不要用符号链接指向会自动更新的 main 分支。

换机时迁移经过审阅的技能和 manifest，而不是迁移 .env、私钥、浏览器 profile 或完整 shell 历史。可将无敏感信息的技能纳入私有备份；公开仓库仅放自写且确认许可允许的内容。换机恢复后逐个确认客户端识别路径、技能是否按预期触发、依赖是否存在，以及技能没有获得多余权限。

本机 skills-main 目录状态

截至 2026-10-16，本机下载目录中存在 skills-main，共发现 38 个 SKILL.md，目录名分类为：Engineering 18、Productivity 7、Misc 4、In-progress 9。本机根 package.json 标记包名 mattpocock-skills、版本 1.2.3、许可证 MIT，和 Matt Pocock 官方仓库相符；本次复核时上游 package.json 与最新公开 release 均为 1.3.1（release notes），本机 v1.2.3 发布页指向签名 commit 6acc160。GitHub 星标不在本机清单中固化，因为它会持续变化，也不能说明技能安全或适配性。本机目录没有 Git 元数据，无法证明副本逐字节对应该 tag 或已经同步。本段只是初次目录清点：只按路径记录名称，未执行技能或安装到自动发现目录；后续只读正文审阅见下文。根许可证不能替代对每项实际依赖、引用资产和许可的检查。 2026-10-16 只读检查了本机 skills-main/scripts/list-skills.sh 与 skills-main/scripts/link-skills.sh：前者只列出技能路径；后者自述为维护者开发脚本、不是受支持安装器，会把非 deprecated/misc 技能（包括 in-progress）软链接到 ~/.claude/skills 与 ~/.agents/skills。若同名目标存在且不是软链接，脚本会直接执行 rm -rf，没有确认、备份或碰撞恢复。不要把它当成个人换机安装器运行；先检查目标目录，并只将单个已审阅、固定版本的技能放入隔离副本。两个脚本均未执行；本地 1.2.3 副本没有 Git 元数据，无法据此证明与上游 1.3.1 逐文件一致。

四个候选的静态审查（2026-10-16）

• code-review 目录只有 SKILL.md 与 agents/openai.yaml，没有附带可执行代码。它的固定 diff 点、Spec/Standards 双轴和不重排发现值得借鉴；但流程强制并行子代理，并依赖 docs/agents/issue-tracker.md，不适合直接当成所有 Agent/仓库通用的一键审查器。若 issue-tracker 设置缺失或当前环境不支持并行子代理，应明确缩小流程而不是假装已完成两轴审查。
• tdd 目录只有 SKILL.md、tests.md、mocking.md 与 agents/openai.yaml，同样没有附带可执行代码。行为测试、独立期望值、边界 mock、红绿小步和纵向切片是可复用要点；“每个测试前必须先向用户确认 seam”过于僵硬。日常代理任务应先遵循仓库已有测试边界，只有接口/测试范围会实质改变方案时才暂停确认。
• diagnosing-bugs 附有 scripts/hitl-loop.template.sh，不是纯文本技能。模板通过终端采集 ERROR_MSG 并原样打印为 ERROR_MSG=...；它不会自动脱敏。虽然主说明要求手动遮盖秘密，使用模板时仍必须先删去 Cookie、token、邮箱和个人数据，不能把整段 HAR/请求头直接贴入采集变量。没有执行该模板。
• setup-pre-commit 只有 SKILL.md 与 agents/openai.yaml，没有附带可执行脚本。它建议对所有暂存文件运行 Prettier，并在结尾暂存全部新建/修改文件后直接提交；如果仓库已有 hooks、工作区有用户改动或格式配置不同，照做可能覆盖约定或把无关改动一起提交。实际使用前必须检查现有 hooks/package manager、git status 和暂存区，仅修改明确授权的文件；不自动暂存或提交。
• 以上四项只对本机标为 1.2.3 的副本及列出的全部附属文件做了只读阅读；没有运行任何命令、测试或安装。上游 1.3.1 与本机文件的差异尚未逐项比对，因此结论不自动适用于上游新版。截至这批复核时，另有 34 个技能正文及引用资源未逐项审查；后续批次见下节。

另外四个变更与 Git 候选的静态审查（2026-10-16）

• implement 的 TDD、分层检查和完成后复审建议可复用，但它要求“提交到当前分支”。在工作区存在用户改动或用户没有要求提交时，不能照搬该步骤；先核对改动归属，只在用户明确授权后暂存和提交指定文件。
• resolving-merge-conflicts 要求“永远不要 --abort”、始终解决冲突，并在结束时暂存全部文件和提交。冲突状态可能需要安全退出；全量暂存也会混入无关改动。应先保存状态、理解双方意图，逐个解决受影响文件；无法安全完成时保留现场并说明，不自动 abort、stage 或 commit。
• implement-spec 位于 in-progress，假定存在关联工单和任务图，并要求创建分支/草稿 PR、后台并行实现子代理、合并子代理 worktree，最后清理 worktree。它是特定团队流程草案，不是通用默认步骤；没有工单/PR 后端或未获用户授权时，不创建这些外部状态，也不清理工作树。
• git-guardrails-claude-code 会写项目级或全局 .claude/settings.json、复制 hook 并 chmod +x。附带脚本只用 grep 匹配命令字符串；缺少 set -e 时 JSON 无效或 jq 失败会得到空命令并以 0 放行，且没覆盖常见的 git checkout -- .、git clean --force 等参数形式。因此只能当提醒层，不能当安全边界；安装前需先修成解析失败即拒绝并覆盖命令变体。没有安装或运行 hook。
• 这四项也只做了本机快照的只读审阅，没有执行命令。前两批累计审阅 8/38 个技能正文；当时其余 30 个正文、脚本及引用资源未逐项审查，后续进度见下节。

五个研究、设计与规划技能的静态审查（2026-10-16）

• research 只提供流程指令，却默认启动后台代理并将研究写入仓库 Markdown。只问答或明确要求只读时不应自动造文件/委派；有研究产物需求时逐条引用规范、官方文档或一手来源，并先确认写入位置和敏感信息边界。
• improve-codebase-architecture 会扫描后写临时 HTML 并自动打开，模板从 Tailwind 与 Mermaid CDN 加载脚本，且配置 Mermaid securityLevel: loose。官方说明 loose 允许文本中的 HTML 标签和点击，而默认 strict 会编码 HTML 并禁用点击；私有代码分析应避免把不可信文本直塞图表，优先用 strict 或 sandbox，并考虑离线/本地资源。详见 Mermaid securityLevel。
• to-spec 把当前对话直接整理成 spec 并发布到配置的 issue tracker，还会自动加 ready-for-agent；它虽要求确认测试 seam，却没有清楚的发布前最终确认门。创建外部 issue 或写 .scratch/ 前应先给用户看完整草稿并取得明确授权，内容先做公司/个人隐私脱敏。
• to-tickets 有较好的发布前检查点：先列出 ticket 和阻塞关系，请用户确认拆分后再写本地文件或批量创建 issue。实际执行仍需核对目标仓库/平台、票数和敏感信息；ready-for-agent 不代表系统已具备可靠隔离或自动执行授权。
• setup-matt-pocock-skills 会配置 AGENTS.md 或 CLAUDE.md，并生成 docs/agents/ 下的 issue tracker、domain/ADR 与 triage 规则。它要求先探索、逐段询问并展示待写草稿，是相对稳妥的配置流程；迁移时只改约定区块，不覆盖用户原有规则，也不因模板存在就自动创建远端 issue tracker 资源。
• 这五项及列出的模板只做了本机快照静态阅读，没有运行技能、代理、CDN 报告或 CLI。前三批累计审阅 13/38 个技能正文；当时其余 25 个正文、脚本及引用资源待审查，后续进度见下节。本地副本与上游 1.3.1 的差异也未完成全量比对。

需要人工把关的 issue、交接与脚本候选（2026-10-16）

• triage 可能给 issue/PR 写评论、改标签或关闭条目，并要求 AI 评论带免责声明；流程包含先推荐并等维护者方向的检查点。应限于用户明确授权的仓库与对象，发布评论、改标签、关闭 issue 前复述具体动作并确认，不能把“move”理解为不需确认的外部写操作。
• wayfinder 会创建 map 和子 issue、连依赖、指派/claim、评论、关闭，也可能更新或删除失效 ticket；这是会持续修改团队 tracker 的长流程。启用前明确目的仓库、tracker 与写入范围，先给出对象/关系草案；不要把个人博客的未完成事项自动转成公开 issue。
• wizard 的模板用隐藏输入收集密钥，随后可写 .env 并通过当前目录推断的 gh 仓库设置 Actions secrets/variables。它有阶段确认，但没有显式核对目标仓库身份，也没有在每次写入前验证 .env 权限或值的格式；运行前需检查 cwd、ENV_FILE、目标仓库、工作区和 secrets 名称，绝不把测试密钥当生产值。模板没有被执行。
• handoff 把会话摘要写进系统临时目录，claude-handoff 会把摘要作为命令参数传给当前目录启动的后台 Claude。两者都明确要求脱敏；跨代理传递前仍要删掉凭据、用户/公司内部内容和不必要的历史，不自动启动第二个代理，也不把临时文件当长期安全存储。
• loop-me 可能新建、编辑或删除 workflows/*.md 和 NOTES.md，其“唯一产物是 workflow spec”适合专门的需求访谈，不适合一般实现请求。只有用户明确进入流程设计时才使用，修改既有 spec 前保留原文与版本。
• retro 可能读取本机 session logs；默认使用当前 session，但对指定历史 session 的检索也可能带出机密上下文。先限定 session 和时间范围，只取相关片段，不把日志原样复制到报告。
• pr 是 PR 描述模板，不含可执行代码；它鼓励放入伪代码、文件树和 Mermaid 图。生成 PR 正文前仍要检查是否混入私有路径、内部域名、业务数据或完整 diff，发布 PR/评论不由模板本身授权。
• migrate-to-shoehorn 建议运行 npm i 并批量替换测试中的类型断言；它强调只用于测试代码，但没有先核对仓库 package manager、锁文件和各断言语义。先选窄范围逐个迁移，避免把用于验证非法输入的断言也机械替换。
• scaffold-exercises 会创建目录/文件、运行课程专属 lint，并在流程目标中要求 git commit。命令只适用于匹配的课程仓库；创建前预览文件树，确认私有 CLI 来源；未经明确授权不暂存或提交。
• 上述十个 SKILL.md 正文完成静态审阅，引用脚本/模板仅按本文注明范围抽查；没有运行任何技能或命令。截至该批结束累计审阅 23/38 个正文，另有 15 个正文未审；本批范围外的引用资源和上游版本差异仍未逐项复核。

工程设计、写作与进行中技能的最后一批正文审阅（2026-10-16）

• ask-matt 及其 phase-boundaries 文档把澄清、计划、实现、复审串成固定路由，也鼓励 issue、子代理和提交。它有利于复杂工程任务形成检查点，但“继续”可能被设为默认推进动作；不能因此跳过本仓库约定、授权边界或真实完成条件。只在符合当前任务的阶段使用，不因模板要求就创建 issue、启动代理或提交。
• codebase-design 与 DEEPENING.md、DESIGN-IT-TWICE.md 提供深模块、加深设计和比较替代方案的思路。适配器数量、强制多个子代理和清理旧单元测试等规则应视为该工作流的启发式，不是通用架构定律；删除测试前先确认覆盖由什么替代。
• domain-modeling 的 CONTEXT/ADR 模板适合沉淀经确认的领域词汇和决策。不要把模型推断的术语直接写成团队共识；只记录用户或代码证据支持的定义，ADR 保持短小并明确状态。
• grill-with-docs 只有一段路由说明，会组合 grilling 与领域建模。它适用于用户明确要求一起澄清复杂设计的场景；逐轮提出完整问题树、等待共识再行动，不应阻塞已经清晰的执行请求。
• prototype 明确追求快速验证，允许临时路由/文件、跳过测试与错误处理，并把结果留在临时分支后链接 issue。只能在隔离原型分支按明确范围使用；不能把未验证原型直接合入生产，也不能清理用户已有文件来满足模板。
• grill-me 只是转到 grilling；后者要求一轮问完当前所有已知前提的问题、等待用户回答，并在达成共识前不行动。它适合压力测试方案，不适合日常事实调查或已授权的实现；环境事实应由代理先查，且不要把“提问流程”当作额外授权。
• teach 建立有 mission、资源、课程、参考资料和学习记录的持续教学工作区，并要求不清晰时先向用户确认学习目标；to-questionnaire 则先问收件人的角色和需要回收的决策，再生成问卷。二者是专用协作模式，不应在普通技术解释/执行任务中擅自创建目录或反复向用户索要可由环境查明的信息。
• wait-what 用于用户明确表示没听懂时，要求改用简化英语并遵循仓库 CONTEXT 词汇；这是窄场景的重述工具，不应改写用户原本的中文内容，也不能把上下文文件中未经确认的领域词当成事实。
• writing-for-agents 提出 context/cognitive load、逐步披露、完成条件与单一事实来源等有用审稿角度；关于 leading words、否定表达和何时拆分文档的主张带有较强作者观点，应通过当前仓库和读者验证，不能机械套用成格式规范。
• setup-ts-deep-modules 标为 in-progress：会新增依赖、改包配置/脚本/AGENTS 文档、生成样例模块，并暂时改测试验证规则。no-circular 等全局规则可能影响整个仓库；运行前要确认包管理器、目标目录、规则适用范围并隔离临时测试改动。本次只读检查，没有安装依赖或运行该技能。
• writing-fragments、writing-beats、writing-shape 是三种不同的协作写作模式：分别先累积无结构片段、由用户逐个选择文章 beat、以及保留原始素材并逐段塑形为新文章。它们都含多轮停顿和用户选择条件；只在用户明确选择该工作流时启用，普通知识文章不必被拆成逐轮审批，且 writing-shape 明确要求原始素材只读。三项均标为 in-progress。
• 本批完成剩余 15 个 SKILL.md 正文的静态阅读，累计 38/38 个正文已审；其中 9 项标记为 in-progress，该数字不代表它们已稳定、可安装或安全。所有技能、脚本、子代理、外部 tracker 与配置均未运行或写入。对引用资料只做了本批记录注明的抽查；与上游 v1.3.1 的逐文件差异见下节，但完整配套文件、依赖和逐项许可仍待专项复核。

与上游最新公开 v1.3.1 release 的文件差异（2026-10-16）

• GitHub 的 Latest release 页面在本次核对时指向 v1.3.1，tag 对应提交 24fe0ef7737efae15c87225755e9f6f5965e4888。本机 package.json 声明 1.2.3，但下载目录没有 Git 元数据；以下是本机现有文件与该 release 的内容差异，不证明下载目录是未经修改的官方 v1.2.3 副本，也不代表 main 分支当前内容。
• 本机快照有 38 个正文，分类为 Engineering 18、Productivity 7、Misc 4、In-progress 9；v1.3.1 有 37 个正文，分类为 Engineering 20、Productivity 7、Misc 4、In-progress 6。对 34 个同路径正文逐项比较后，8 个有内容差异，主要是流程路由更新和 CONTEXT.md 迁到 GLOSSARY.md；其余 26 个正文相同。
• implement-spec、pr、retro 从 in-progress 转入 engineering；它们现在分别是整份 spec 的并行实现流程、PR 正文模板、以及会后改进 Agent 环境的回顾流程。resolving-merge-conflicts 已从上游移除，没有专用替代技能。分类和状态已变，不要把本机旧目录结构当作上游现状。
• 新版 implement-spec 修正了旧草案的部分外部副作用：明确依赖已提供的 issue tracker；只有 tracker 以 PR 关闭工作或用户要求时才开 draft PR。它仍会创建 integration branch、为 ticket 开 worktree、派发/合并子代理、关闭工单并清理 worktree；这些分支/仓库操作仍须按用户授权、现有改动和仓库政策逐项判断，不能因技能写了流程就自动执行。
• 新版 pr 是 model-invoked，建议用图示、前后证据和单向/双向门及影响范围组织 PR 正文；写正文不等于获准发布。retro 是 user-invoked，会回读指定 coding session 的来源日志并提出环境改进；使用时限定 session 和片段，避免把日志中的密钥、个人信息或公司内容带入产物。
• 领域术语文件从 CONTEXT.md / CONTEXT-MAP.md 改为 GLOSSARY.md / GLOSSARY-MAP.md，格式模板也从 CONTEXT-FORMAT.md 改为 GLOSSARY-FORMAT.md。若从旧目录升级，应先检查所有消费者、上下文映射和现有文件，再按官方迁移说明改名，避免出现新技能读不到旧术语文档的断链；本次没有改动本机下载目录。
• 上节比较了技能正文、元数据、分类 README 和直接引用的领域格式文件；本批继续核对技能目录文件清单、根许可证、包清单与明确署名的第三方来源。深层引用内容、每个依赖的实际使用和许可证仍未全部审计。没有运行技能/脚本；启用前固定 revision，并重新核对主分支 release 后的变化。

这是一份 2026-10-16 本机快照及其与固定 v1.3.1 tag 的只读比较，不表示每项都适合当前 Agent。正文 38/38 已做静态审阅，但不是完整源码/许可证审计或安全认证。要迁移或公开某个技能，先固定来源 revision，再逐项检查 SKILL.md、脚本、引用资源和实际许可证；In-progress 条目尤其不能当作稳定功能。

支持文件、依赖与来源署名的复核（2026-10-16）

• 对 skills/ 下文件做了只读逐路径哈希比较，排除 .DS_Store：本机快照 108 个文件、上游 v1.3.1 有 106 个；98 个相同路径中 85 个逐字节相同、13 个内容不同，另有本机独有 10 个、上游独有 8 个。差异覆盖 README、技能辅助模板和移动/新增文件；它补充了上一节 34 个同路径 SKILL.md 的统计，不代表逐句审阅全部辅助资料。
• 两个快照的仓库根 LICENSE 都是字节相同的 MIT 文件；根 package.json 标记仓库为 private，且只有 @changesets/changelog-github、@changesets/cli 两个直接开发依赖。lockfile v3 有 112 个 package 条目。没有安装、执行 package 脚本或开展传递依赖安全/许可证扫描；仓库根 MIT 与此清单不能自动证明第三方摘录、图片或依赖的授权范围。
• 本机 skills/in-progress/pr/CREDITS.md 将其中一个近乎逐字复用的段落归因于 Dex Horthy 与 HumanLayer 的 show-me，所以本文不复制该段，只原创概括并保留署名线索。该说明指向的 humanlayer/humanlayer 当前根许可证为 Apache-2.0；另一个独立仓库 humanlayer/skills 当前也提供 show-me，其根许可证为 MIT。仓库和版本不能混为一谈，当前分支也不能证明历史片段的精确来源 revision；若要转载原文或随技能再分发，应先固定实际来源并确认适用许可及署名。
• 本轮只读取清单、包元数据、LICENSE、credits 和脚本文本；没有运行/安装任何技能、模板或依赖。脚本与配置的具体安全发现见前文；未完成所有深层资料的内容核验、传递依赖审计或真实 Agent 迁移测试。

建议的首批实践

1. 先阅读开放规范和官方技能仓库中的纯文档示例，写一个不含脚本、只做项目测试说明的自用技能。
2. 用测试任务检查触发条件是否明确、指令是否简洁、失败时是否停止并报告，而非猜测或扩大操作范围。
3. 再从精选目录选一个与当前工作直接相关的技能，检查源仓库、许可证、脚本和依赖并固定 revision。
4. 将 reviewed 技能复制到当前 Agent 官方支持的位置，用无敏感内容的临时仓库试运行。
5. 将 manifest、验证记录和回滚 revision 纳入个人换机清单；每季度复核上游是否有安全公告或破坏性更新。

参考资料

• Agent Skills 开放规范。
• Anthropic Agent Skills 公开仓库 与 第三方声明。
• VoltAgent Awesome Agent Skills。
• GitHub Awesome Copilot。
• obra/superpowers、分离后的 obra/superpowers-skills 与 Superpowers 发布说明。
• OpenAI Codex Skills 指南、OpenAI Plugins 示例仓库 与已弃用的旧 Skills 仓库说明。