GitHub 趋势的 AI 仓库中，一半是“skills”包，但其形态差异可达千倍。真正的原语是去做一些真实的事。

三个趋势中的“skills”仓库，看看里面有什么： * karpathy-skills：1 个 markdown 文件，4 条规则，~70k stars * mattpocock/skills：~10 个 SKILL.md 文件，~115k stars * everything-claude-code：182 个 SKILL.md 文件 + 48 个 agent + 68 个命令 + hooks + rules + MCP 配置 + npm 包，~178k stars（另外同一位作者还有第二个仓库也在前十） 范围相差三个数量级，却使用相同的标签。所有这些的背后都是 Anthropic 的 SKILL.md 格式。带有 YAML 前置元数据的 Markdown 文件，在会话启动时由 Claude Code 自动加载（并通过 shim 被 Cursor、Codex、OpenCode、Gemini、Antigravity 加载）。它就是带有约定的提示词。这才是真正有趣的部分。 两年来，“如何让这个智能体在 X 方面做得更好”的答案一直是提示工程、手动上下文和胶水代码。SKILL.md 是第一个被广泛采用的尝试，它让智能体能力的单元变得可发布、可复刻、可安装，并具有定义的调用模式（文件自动加载，前置元数据声明触发时机）。这是一个真正的原语，即使围绕它的趋势列表很嘈杂。 以下是我作为构建者反复思考的四个影响： 1. 打包方式才是原语，而不是内容。mattpocock 的 tdd 技能和 ECC 的 tdd-workflow 技能用类似的措辞解决了同一个问题。区分点在于你是否以其他人可以组合的格式发布它，而不是你的措辞是否更巧妙。 2. 跨平台的可移植性是有漏洞的。ECC 发布了到 .claude/、.cursor/、.codex/、.opencode/、.gemini/、.agent/ 六个路径，每个都有其独特之处（Cursor 有 20 个 hook 事件，而 Claude Code 只有 8 个，插件分发不能携带规则，OpenCode 有不同的插件系统）。一次编写到处运行是可行的，但需要付出代价。 3. 工作流强制与能力扩展之间存在真正的分裂。2024-2025 年关于 agent-skills 的讨论大多集中在能力（工具使用、浏览器、API）上。而 2026 年中真正趋势的是工作流（TDD、分类、代码审查、计划）。关于价值所在的不同赌注。 4. 看空观点。如果你的“技能”是一个从推文衍生而来的 markdown 文件，并且有 7 万星，那么护城河几乎为零。一个以技能包为差异化的初创公司应该假设该包会在 12 个月内被复制、复刻或被基础模型吸收。Karpathy 的四条规则将在下一个 Claude 版本中成为默认行为。 对于交付生产级智能体的人来说，你是将技能视为真正的分发原语（发布、版本管理、依赖管理），还是视为偶尔推送到 GitHub 的个人便签？跨平台的故事对你来说是否成立，还是你最终会为每个设置而分叉？