案例解剖板块到这里收尾。八个项目挨个看完，你心里应该已经形成了感觉——每家都在不同程度地实现"Thin Harness, Fat Skills"，差别就在哪一层做厚、哪一层做薄、用什么方式做。
这一篇从案例里抽出来一条横切面——专门讲skills本身。不是"某家的skill怎么做"，是"skills这件事整体往哪走"。
—— Skill的本质
先把根上的事捋清楚。
Skill不是prompt。prompt是当下要传给模型的那段文本，每次调用一次性消耗。skill是被存起来、可复用、可被多个Agent读取的文档。
Skill不是工具。工具是确定性的可执行函数——参数确定、输出确定。skill是概率性的判断和流程描述——参数一样，不同时候、不同上下文、不同模型执行结果都会有差异。
Skill是"可复用的知识单元"。它把"如何做某类任务"的判断和流程编码成文档，让agent读了就能照着做。
那skill跟function最本质的区别在哪——function的弹性来自参数，skill的弹性来自模型。同一个skill被不同代的模型读，效果会不一样——更强的模型能把skill的指令落得更精准、把判断做得更细腻。
这就是Garry Tan说"模型升级时skill自动变强"的底层机制——skill是描述性的、不锁死实现细节，所以模型越强，skill的"潜力上限"越高。
而工具不是这样——工具的实现固定，模型再强也不会让一个错误的SQL查询自动变对。
理解了这一层，你就明白为什么"Thin Harness, Fat Skills"是面向未来的设计——harness绑定具体实现，会被时代淘汰；skill是描述性资产，跟着模型一起增值。
—— 五种Skill形态
八个项目里我数了下，skill其实有五种主要形态。横向比一下，你心里就有数了——
Anthropic官方SKILL.md——基础设施。
YAML frontmatter加markdown主体内容。这是Claude Code原生的skill格式，也是整个生态的事实标准。Superpowers和ECC进了官方Plugin Marketplace，本质上都是在这套格式上建立的社区层。学skills先学这个格式，是绕不过去的基础。
Superpowers的mandatory trigger skill——强制执行。
每个skill有明确的触发条件——"在code被写之前触发"、"在design被approved之后触发"。这不是suggestion，是harness强制读的。最特别的——它把"不该做什么"也写成skill。testing-anti-patterns这种negative skill在其他形态里很少见，但效果出奇地好。
ECC的SKILL.md加Instinct系统——分层沉淀。
SKILL.md是静态定义的、经过审核的skill。Instinct是动态学到的"前体"——有confidence scoring、可以evolve聚合成正式SKILL.md。这是static和learned两层并存的设计——也是目前最完整、最工程化的skill pipeline。
Hermes的Auto-generated Skill——完全自动。
5次以上tool call后自动生成，使用时自动patch更新。最轻量，但也最缺confidence控制。适合个人快速积累、不适合团队强一致性场景。
gbrain的Fat Skill——重度封装。
把一个完整工作流编码进去（when to fire、what to check、how to chain、what quality bar）。同时skill里可以调deterministic TypeScript code做"不该交给LLM判断的部分"。"Thin Harness, Fat Skills"那个"fat"就是这个意思——skill不只是prompt，是workflow加代码的组合。
五种形态没有谁绝对好——取决于你的场景对"自动化程度"和"质量保证"的相对优先级。
个人快速试错——Hermes auto-gen最快。
团队协作沉淀——ECC的Instinct加SKILL两层最稳。
强制工程纪律——Superpowers的mandatory最有效。
重度业务逻辑——gbrain的fat skill最能装。
跨生态分发——Anthropic官方SKILL.md兼容性最好。
—— Skill的生命周期管理
你做企业项目，会发现skill不只是"写完就完了"，是有完整生命周期的——
写——SKILL.md格式规范要遵守。Superpowers有个writing-skills skill专门教你怎么写好skill。ECC有个skill-stocktake审计现有skill的质量——找出过时的、重复的、低质量的。这些"写skill的skill"听着套娃，但确实管用。
测——skill不是纯文档，是agent行为的依据，必须验证。Superpowers的writing-skills本身就有TDD方法论——给skill写测试用例，agent按skill干活时跑这些用例验证。ECC有997 internal tests，覆盖整个skill库的核心行为。
分发——做完skill怎么让别人用上。Anthropic官方Plugin Marketplace是大众路径，一行命令安装。ECC的Skill Creator GitHub App可以从git history批量生成SKILL.md，自动化程度更高。
复用——团队场景下skill共享。ECC的/instinct-export和/instinct-import让团队间skill能流通。pi-mono的awesome-pi-agent是社区生态的中心仓库。
淘汰——skill不是越多越好，过期的、错的要清。ECC的/prune命令清过期instinct（默认30天TTL）。Hermes的skill auto-patch机制避免手动维护过时skill。
这五个环节都要管，skill库才是健康的。只写不淘，就跟代码不删一样，越积越乱。
—— 三种Skill自动生成路径
skill到底从哪儿来——这件事八个项目给了三种不同回答。
ECC Skill Creator——基于git history的反向工程。
从历史的commit message、PR description、代码变更里抽取pattern，生成SKILL.md。这是"从你已经做过的事情里学"。
适用于团队已经积累了几年代码、有大量历史经验沉淀但没文档化的场景。把隐性知识从git history里挖出来变成显性skill，特别适合那种"老员工脑子里很多东西、但没人写下来"的团队。
Hermes的auto-generation——基于tool call trace的在线学习。
agent干活的过程中自己发现pattern并生成skill。这是"从你正在做的事情里学"。
适用于快速迭代的个人开发场景——你在用agent干活儿，agent顺手把经验沉淀下来。但要做好"质量参差"的预期——前期生成的skill经常需要返工。
gbrain的dream cycle——基于所有积累内容的离线综合。
agent在你睡觉的时候扫描所有conversation、enriching missing entities、fixing broken citations、consolidating memory。这是"从你已经积累的所有知识里综合"。
适用于知识资产已经积累了一段时间、需要做periodic整理和升级的场景。这种异步、批量的处理方式适合大规模知识系统。
三种路径代表三种"skill从哪里来"的哲学——过去的记录、当前的行为、存量的知识。最终都在服务"thin harness fat skills"这个命题——让skill库不依赖人工持续投入也能成长。
—— Skills生态的下一步
skill生态接下来会往哪走，我自己的几个预测——
从个人skill到团队skill到组织skill。现在大部分skill是个人开发者写给自己用的、或者是开源社区给所有人用的。下一步会出现"团队私有skill库"——一个公司内部按业务领域、按团队角色组织的skill资产，有完整的访问控制、版本管理、变更审计。
从platform-specific到跨harness标准格式。目前Claude Code的SKILL.md、OpenCode的format、Cursor的plugin格式互不通用。ECC已经在做DRY adapter、Superpowers已经在做跨平台skill。下一步会出现公认的"跨harness skill标准"——可能是Anthropic的SKILL.md胜出，也可能是个新的中立格式。
Skill的版本管理和diff。现在skill更新基本就是覆盖。下一步会有skill的semantic versioning、变更diff、回滚能力。当skill是企业资产，它必须像代码一样被严格版本管理。
Skill的A/B测试和eval。现在skill效果好不好基本靠感觉。下一步会有标准的skill eval套件——同一个任务用skill A和skill B各跑20次，统计成功率、token、cost。没有eval的skill就是没有数据的代码，谈不上工程化。
Skill和MCP server之间的边界重新划定。当skill里的代码越来越多——比如gbrain的fat skill里大量deterministic code——它跟MCP server的差异在哪——MCP server是独立运行的进程提供工具能力，fat skill是文档形式调用代码描述工作流。两者会逐渐有融合，可能出现"可执行skill"或"可声明MCP"这种中间形态。
—— 案例板块和这一篇的总结
回看整个案例解剖板块加这一篇横切面——
八个项目展示了harness生态当下的多元状态。这一篇把skills这条主线从八家里抽出来横向比较。
结论是清晰的——skills是harness这一年沉淀下来最有共识的"知识资产形式"。不管你用哪家harness，能写好skill库，就有了不可剥夺的资产；harness再换、模型再升级、平台再变迁，skill库都在。
最后用Garry Tan那句话再点一次题——Harness是借来的，Skill是自己的。
下一篇换轨道，讲orchestration——multi-agent还是single-agent，这是harness工程化最容易踩坑的地方。八个案例里每家的多agent设计哲学都不一样，正好做横向对比。然后会引出几条很硬的"什么时候不要上多agent"原则——这一篇基调偏批判，因为业内有太多团队在不该上多agent的场景上多agent，最后系统跑不起来。
