简报

技术简报AI Skill集合优秀SKILL侦测与发现

优秀SKILL侦测与发现 第 2 期

生成
2026-11-07 13:28
首次公开
2026-11-07 13:28
本版公开
2026-11-10 00:19 · v2
来源
开源技术雷达
自动排版

本期新发现 5 个技能资产项目，重要更新 0 项，论文 0 篇（本源不含 arxiv/openreview）。与上期「技能库盘点」不同，本期看到的是技能生态正在分化出三种形态：Spec Kit 与 BMAD 把方法论写成可执行流程（后者还处在 v6→V7 版本换代期，采用需锁版本）；wshobson/agents 把「一份 Markdown 源文件适配 7 种编码工具」做成带 CI 校验的工程流程，是上期七个库里没有的做法；awesome-copilot 与 claude-code-templates 则是注册表，后者的价值与风险都集中在「它是聚合器」。

目录 · 6 节
  1. 项目比较与观察
  2. 本期精选
  3. 候选项目
  4. 相关资料
  5. 值得进一步研究
  6. 原始阅读依据

项目比较与观察

本期五个项目实则四种形态spec-kit 是「方法论包」（把 SDD 的模板与流程写成命令，让 agent 按流程做）；BMAD 也是方法论包但更重，加了角色化 agent 与简报→计划→架构的交付循环，且已进入版本换代期；wshobson/agents 是「多 harness 适配层」，一份 Markdown 经生成器与 CI 验证后同时供给 7 种编码工具，这是上期七个技能库里没有出现过的工程做法；awesome-copilot 与 claude-code-templates 都是注册表，前者是官方背书的社区合集，后者是带 CLI 的聚合包，且明确保留各来源原许可。选型口径：要「让 agent 按流程做事」选前两个；要「一套资产走多个工具」只剩第三个；要「发现与安装」则看后两个。

本期精选

Spec Kit

把「先写规约再写代码」从口号变成可执行流程：提供一套模板与命令，让编码 agent 按 /specify → /plan → /tasks 的顺序推进，每一步都产出可审阅的文档，再进入实现。它要防的是「assistant 把未说出的假设直接变成代码」。

主要应用领域多人协作的软件项目里让 agent 按固定流程产出文档、需求与架构变更的可审计、把「口头需求」转化为可审阅规格、新人用 agent 接手日项目时先建上下文。

核心价值把「流程」而不是「提示词」作为资产沉淀下来，是本方向从「技能收集」走向「团队规范」的一个具体样本。

采用建议适合已经有协作规范、痛点在于「agent 乱猜需求」的团队；如果只是单人写小工具，流程成本可能高于收益，建议只挑其中一两个模板用。

能力、接入与限制

能力与接入模板与命令集（配合支持斜杠命令的编码工具），提供规范/计划/任务分阶段流程与可归档产出；148.2k stars、13.3k forks、91 open issues。仅读仓库页与 README，未实装。

关键限制模板与命令是流程约束，不能保证 agent 真的遵守；91 个 open issues 说明模板细节仍在打磨；本轮未在真实项目里跑过全流程，无法评价对交付速度的实际影响。

项目原始入口12

148,200MIT

wshobson/agents

把同一套 agent、技能与命令写成 Markdown，再用生成器与 CI 适配到 Claude Code、Codex CLI、Cursor、OpenCode、Antigravity CLI、GitHub Copilot、Pi 七种工具，让资产只维护一份。

主要应用领域多工具并行使用的团队、需要把内部技能资产跨 harness 分发、想把「技能质量」纳入 CI 验证的工程组织、评估不同编码工具能力差异的团队。

核心价值把技能资产从「手工作抄」推到「可生成、可校验、可多平台分发」，是本期最具工程价值的做法。

采用建议团队同时用多个编码工具时，这套「写一次、生成多份、CI 校验」的做法最值得借鉴；即便不用它的组件，其适配器与验证流程也可以直接拸。

能力、接入与限制

能力与接入Markdown 源文件 + tools/adapters 生成器 + CI 校验，覆盖 7 种 harness；94 插件 / 202 agents / 185 skills / 105 命令；42.3k stars、4.5k forks、仅 3 个 open issues。仅读仓库页与 README，未安装。

关键限制大量组件是他人作品的再分发，质量与后续维护取决于上游；外部插件有各自许可；适配器生成的文件与原格式的细微差异需实际验证；本轮未安装任何 harness 实测。

项目原始入口3

42,300MIT

BMAD-METHOD

把敏捷交付写成一套带角色的 agent 流程：从模糊想法进入 Clarify、明确的大想法进入 Plan、小改动直接 Build，并用简报、规格、架构等文档把决定沉淀下来，避免每次对话重新解释。

主要应用领域中小团队统一 agent 协作流程、接手遗留系统时先建可信上下文、把需求澄清与架构决策变成可归档交付物、多人多 agent 讨论式评审。

核心价值把「敏捷」真正变成 agent 能执行的步骤，而不是写在文档里的口号；对流程混乱的团队，它提供的是护栏而不是提速。

采用建议适合想把「需求澄清→方案→拆任务」固定成团队习惯的项目；上生产需锁定 v6.12 而非跟 V7 alpha，并预留升级评估成本。

能力、接入与限制

能力与接入Markdown 技能与工作流 + npm 安装器，内置角色化 agent 与文档产出链；55.1k stars、6.1k forks、76 open issues；v6.12 稳定 / V7 alpha。仅读仓库页与 README，未安装。

关键限制正处版本换代期：稳定版 v6.12、V7 仍为 alpha 且安装路径与文档频繁变动（官方称 V7 预计 2026 年 11 月中发布），选型要指定版本；76 个 open issues；未实测。

项目原始入口45

55,100

awesome-copilot

由 GitHub 官方维护的社区贡献合集：集中收纳面向 GitHub Copilot 的自定义 agent、instructions、skills、hooks、workflows 与 plugins，并区分「直接复制即用」与「需安装」两类。

主要应用领域企业 Copilot 场景的指令与技能模板、给不同团队分发标准化 instructions、把内部规范写成可审查的 prompt 文件、作为新同事学习 prompt 工程的材料。

核心价值提供了一条「官方收录 + 社区投稿」的技能供给渠道，降低从个人仓库搬技能带来的供应链不确定性。

采用建议团队已用 Copilot 且需要一套可审计的技能来源时优先看这里；但投稿制成不等于质量把关，建议内部先做一次小范围试用再入库。

能力、接入与限制

能力与接入组件合集（instructions/agents/skills/hooks/workflows/plugins）+ 文档站；40.9k stars、5.3k forks、29 open issues；采用 all-contributors 与 CONTRIBUTING 流程。仅读仓库页与 README，未安装。

关键限制各类组件质量参差且依赖社区贡献，缺乏统一评测；29 个 open issues、20 个 open PR 在官方仓库中属正常但意味着人工审核为主；本轮未安装。

项目原始入口6

40,900MIT

claude-code-templates

做一个 Claude Code 组件的开源注册表与 CLI：把 agents、commands、skills、hooks、MCP、settings 与 mods 集中到一处，用一条 npx 命令安装，并按场景提供成套模板（含 loop 类工程模板）。

主要应用领域快速搭建编码助手的初始技能集、比较不同上游组件的实际效果、给团队批量安装统一组件、学习组件目录的组织方式。

核心价值把「发现-选择-安装」的链缩短到一条命令，是技能生态从「仓库分散」走向「包管理」的一个现实样本。

采用建议想快速试不同技能组合时很方便；但若要把装好的组件带进交付物，先用它的归属表逐个核许可，免得把 CC0、Apache-2.0 与 MIT 混为一谈。

能力、接入与限制

能力与接入Node CLI + 注册表（npm 分发），组件按类别组织并提供成套模板；33.2k stars、3.9k forks、101 open issues / 372 open PRs。仅读仓库页与 README，未安装。

关键限制聚合型项目：README 明确列出多来源组件（各保留原许可），实际使用需逐个追溯上游；101 个 open issues、372 个 open PR 说明合并积压明显；组件质量与上游同步情况未验证。

项目原始入口7

33,200MIT

候选项目

暂无符合条件的项目，不为凑数重复推荐。

相关资料

技能包的三种形态：方法论包、多 harness 适配层与注册表

本期五个项目可以归为三种形态，这直接决定了它们能不能被「安装使用」，也决定了评估方法： 1) 方法论包：Spec Kit、BMAD-METHOD。产物是模板、命令与工作流，装完不会自动生效，需要团队真的按流程走。评估口径应是「它能不能阻止 agent 乱猜假设」，而不是「它有多少 star」。 2) 多 harness 适配层：wshobson/agents。一份 Markdown 源文件经 tools/adapters 生成 7 种工具的格式，CI 重生成并校验、部分产物还会在对应 CLI 里实际跑。它的价值在于「资产不随工具更换而作废」，评估口径是多工具一致性与验证覆盖率。 3) 注册表/聚合器：awesome-copilot、claude-code-templates。价值在发现与安装效率，但质量方差大、许可来源多层，评估口径是「能不能追溯到具体组件的上游许可与质量证据」。 一个可操作的判断：先用一行写下团队真正的痛点（流程 / 工具碎片化 / 找不到好技能），再对应到上面三类，不要混用同一套评估标准。

研究价值给出按形态而非按星标评估技能包的方法，避免拿「装完能不能用」去衡量方法论包、或拿「流程完不完整」去衡量注册表。

13467

聚合型技能库的许可边界：MIT 只管自己那一层

claude-code-templates 暴露了聚合型技能库的典型许可结构，值得作为通用检查方法： - 项目自身是 MIT，但 README 专设 Attribution 一节，逐个列出上游及许可：anthropics/skills（官方）、obra/superpowers（MIT）、wshobson/agents（MIT）、awesome-claude-code（CC0 1.0）、awesome-claude-skills（Apache-2.0）等； - 并明确「每个资源保留其原许可与归属」。 结论：聚合器的 MIT 只覆盖它自己的代码，不覆盖装进去的组件。所以企业内部采用时应做一张归属表，逐行记录：组件名 / 上游 URL / 上游许可 / 是否需要保留声明 / 是否含商标资产。 配套做法：对于 awesome-copilot 这类含微软标志与商标声明的仓库，二次分发前要移除品牌资产；对于「开源但带 ee/ 目录」的项目，默认按 source-available 对待。这些都属于同一个习惯——读具体文件，不读仓库的那个许可徽标。

研究价值给出「归属表」这一可执行动作，避免把聚合器的 MIT 当成所有被收录组件的许可。

67

值得进一步研究

建议下一步1) 选一个真实的中等需求，分别用 Spec Kit 与 BMAD v6.12 跑一遍，对比「文档产出量」与「返工次数」，而不是对比速度；2) 若团队同时用 Copilot 与 Claude Code，直接试用 wshobson/agents 的适配器流程，重点看 CI 生成产物与实际工具读取是否一致；3) 从 awesome-copilot 与 claude-code-templates 各取 3 个组件，做一张归属表并实测兼容性，再决定是否入库；4) 把「是否含商标/品牌资产」「是否保留原上游许可」加入内部技能准入清单。

原始阅读依据

  1. 1GitHub - github/spec-kit: Toolkit to help you get started with SDD or any other process
  2. 2HN Algolia 检索：spec-kit
  3. 3GitHub - wshobson/agents: plugins, agents, skills and commands for AI coding tools
  4. 4GitHub - bmad-code-org/BMAD-METHOD: Breakthrough Method for Agile Ai Driven Development
  5. 5HN Algolia 检索：bmad method
  6. 6GitHub - github/awesome-copilot: Community-contributed instructions, agents, skills and configurations
  7. 7GitHub - davila7/claude-code-templates: open-source registry and CLI for Claude Code components