Dog-Skills 续篇，从四十八到一百一十六之后，我开始认真考虑维护成本
我之前写过一篇 Dog-Skills 的文章。
那时仓库里有四十八个 Skill，我花了很多篇幅介绍每个 Skill 是做什么的，适合什么任务，又该怎么触发。
后来数量涨到一百一十六。
等我真正开始写这篇续篇时，仓库首页的数字已经变成了一百一十八。
这很符合 Dog-Skills 的状态。
文档刚追上代码，代码又往前跑了两步。
所以这篇文章不再逐个介绍 Skill。再这么写下去，它会变成一本没有人能读完的产品目录。
我更想谈谈另一件事。
当一个收藏夹增长成项目之后，怎样才能让它不崩掉。
从收集到维护，中间差了很多工作
一百一十六个 Skill 并不意味着我从空白开始原创了一百一十六套方法。
Dog-Skills 里有几类内容。
一类是我自己设计或深度整合的 Skill。
一类是基于优秀开源项目改编的工作流。
还有一类是对社区现有 Skill 的收录、翻译、适配和重新组织。
如果把所有内容都写成「我做了」，既不准确，也不尊重上游作者。因此仓库会尽量保留来源、许可证和归属信息，复杂的整合 Skill 还会单独提供 ATTRIBUTIONS.md。
社区贡献目前也不是大家想象中那种热闹的 PR 队列。
直接向 Dog-Skills 提交代码的外部贡献仍然很少。大部分扩充工作由我完成，但大量知识与实现来自更广泛的开源社区。换句话说，社区贡献主要发生在上游生态，而不是集中发生在这个仓库的 Pull Request 页面。
这个区别很重要。
把别人的开源成果整理进仓库，不等于按下复制按钮。
我需要检查许可证，理解原 Skill 的触发条件，调整目录名称，补充说明，避免与现有内容冲突，再决定它究竟应该独立存在，还是被整合进一个更高层的入口。
我装过和看过的 Skill 远远超过最终保留的数量。
筛选标准其实很现实。
它是否解决一个明确问题。
它是否提供了可执行的工作流，而不只是一段漂亮提示词。
它是否与已有 Skill 高度重复。
它是否要求不存在的工具。
它的许可证是否允许收录和修改。
它是否真的比直接对 Claude 说一句话更有价值。
装了一百多个 Skill 之后，我每天真正频繁使用的仍然不到十个。
数量从来不是最终目的。
元 Skill 不是把提示词粘在一起
Dog-Frontier 是一个比较典型的元 Skill。
普通 Skill 通常专注于一个任务。比如生成设计令牌、审查界面、制作动画或优化前端代码。
元 Skill 处理的不是某一个具体动作。
它负责理解需求、选择子 Skill、安排执行顺序、检查阶段产物，最后把多个能力组合成一个完整工作流。
可以把它想象成下面这条路径。
用户提出模糊需求 ↓元 Skill 判断任务类型 ↓选择对应子 Skill 与参考库 ↓需求分析 ↓设计系统 ↓代码实现 ↓交接检查 ↓质量审查 ↓统一输出Dog-Frontier 不需要把二十多个子 Skill 的全部内容复制进同一个文件。
它更像一个路由器和流程控制器。
用户要做完整落地页时，它走完整流程。用户只想审查现有页面时，它可以直接进入质量阶段。用户已经指定品牌风格时，就不必重新做一轮开放式风格探索。
其中还有阶段门控。
需求卡不完整，就不能进入设计阶段。
设计令牌不完整，就不能直接生成代码。
移动端存在水平滚动、表单没有标签、对比度过低时，质量检查不能通过。
这套架构的价值，不是让提示词显得更长。
它是在减少随机性。
一个复杂任务如果只依赖模型临场发挥，每次结果都可能不同。元 Skill 把任务拆成阶段，规定每个阶段需要什么输入、产生什么输出，以及什么条件下可以继续。
它更接近一份可以执行的工程流程。
一百多个 Skill 最怕的不是文件太多
真正麻烦的是冲突。
两个 Skill 可能使用相似的名称。
三个 Skill 可能都声称自己应该在「帮我设计一个网页」时触发。
某个 Skill 认为自己负责完整开发流程，另一个 Skill 也认为自己负责完整开发流程。
如果不做治理，Claude 面对任务时就会像站在商场门口，同时被七个导购抓住。
我先从命名规范开始。
目录名尽量使用稳定的小写英文和连字符。frontmatter 中的 name 与目录用途保持一致。description 不只写宣传语，还要写清楚适用场景、边界和典型触发词。
触发词需要去重。
相似 Skill 不能都无限扩大自己的适用范围。综合型 Skill 应该明确自己负责路由，轻量 Skill 则保留更窄的入口。Dog-Frontier 会说明完整前端项目由它处理，单独的 UI 能力可以交给更轻量的 Skill。
版本信息同样重要。
元 Skill 引用了哪些上游能力，当前按什么规则整合，许可证是什么，都应该被记录。否则上游更新后，我甚至不知道哪些内容需要重新检查。
测试也不能只看 Markdown 能不能打开。
基础测试会检查 YAML frontmatter、名称和 description 是否存在。更进一步的测试要关注触发词是否重叠、引用文件是否缺失、允许使用的工具是否真实可用，以及示例工作流能否走通。
这里还有一个很有代表性的维护问题。
Dog-Frontier 的 metadata、简介和正文曾经出现过不同的集成数量。一个地方写十八个，一个地方写十九个，另一个地方已经更新到二十一个。
文件没有坏。
CI 也能通过。
但语义已经漂移了。
这提醒我，格式检查只能发现结构错误，发现不了所有内容错误。自动化很重要，人工 Review 仍然不能消失。
为什么不能把一百多个 Skill 平铺在首页
Dog-Skills 最早主要按开发、设计、写作、学习、商业和健康等用途理解。
随着数量增长，我又把思考研究、工具发现等入口单独拆出。当前仓库已经形成七个主要分类。
分类不是为了让 README 看起来整齐。
它是在决定用户从哪里进入。
开发者来到仓库，通常不想先浏览健康和内容运营 Skill。做设计的人也不需要在一百多个名称中寻找配色、图表和前端相关能力。
扁平列表在十个项目时很方便。
到一百多个时，它只会制造选择压力。
分类也不能只看 Skill 的内部技术。
一个使用 Python 的报告生成 Skill，用户目的可能是商业分析。一个由 Markdown 编写的 Skill，实际用途可能是代码审查。真正有意义的分类维度应该是用户在什么场景下需要它，而不是它的文件里出现了什么语言。
我还逐渐加入了组合推荐。
新项目可以使用规划、架构和代码审查组合。
前端任务可以使用设计系统、实现和质量审查组合。
研究任务可以使用问题拆解、资料收集和报告编辑组合。
这比告诉用户「这里有一百多个，你自己挑」更负责任。
GitHub Actions 能做什么，又不能做什么
仓库已经有每周自动运行的 Skill Validation 工作流。
它也会在主分支推送和 Pull Request 时执行。
当前检查会扫描每个 SKILL.md，确认 YAML frontmatter 是否存在，name 和 description 是否完整，并统计 Skill 数量。每周一自动运行，可以及时发现结构性问题。
仓库里还加入了 README 同步和 Skill 脚手架相关工作流，用于减少新增 Skill 时漏改安装说明、验证列表和分类内容的概率。
我最初还希望 GitHub Actions 每周自动生成完整更新日志。
真正实现后才发现，这件事比想象中难。
提交记录可以自动汇总，但提交记录不等于面向用户的更新日志。一次提交可能同时修改三个 Skill，也可能只是修正拼写。自动生成的内容如果只是把 Commit Message 全部复制出来，通常没有多少阅读价值。
所以目前更准确的说法是，每周兼容性与结构检查已经落地，README 同步也已经进入自动化流程。真正可靠的语义化更新日志仍在继续完善。
我宁愿承认功能还没完全做完，也不想为了文章好看，把计划写成现实。
开源之后，反馈并不会自动出现
我曾经以为，只要项目公开，就会自然收到大量 Issue、PR 和使用反馈。
现实比较安静。
公开记录里的直接贡献并不多，甚至有一个 Issue 的标题只有「我吗？」三个字。我盯着它看了一会儿，认真思考这究竟是 Bug 报告、哲学问题，还是有人测试按钮。
最后它没有提供更多信息。
这件事有点好笑，也很真实。
开源只是允许别人参与，不会自动创造参与动机。贡献者需要清楚的入口、足够低的修改成本、明确的规范，以及维护者及时的回应。
至于哪些 Skill 使用最多，我也没有遥测数据。
Skill 在本地运行，我不应该凭感觉宣称整个社区最喜欢什么。只能说在我自己的工作流里，Dog-Frontier、规划类 Skill、代码审查、代码简化和中文写作优化出现得最频繁。
也有一些 Skill 收录之后几乎没有再被我触发。
它们可能过于小众，可能和其他能力重复，也可能只是名字和触发方式不够清晰。
这不是坏事。
一个仓库需要定期删除或合并内容，而不是只会增加数字。
下一步不是继续堆到两百个
Dog-Skills 接下来最重要的方向，不是尽快把徽章改成两百。
我更想解决安装和维护问题。
首先是自动安装工具。
用户应该能够按分类或工作流选择 Skill，而不是手动复制一百多个目录。安装器需要处理版本、覆盖、卸载、更新和依赖检查。
其次是 Skill 市场的标准化。
一个 Skill 至少应该拥有统一的名称、描述、版本、许可证、来源、触发场景、工具权限和兼容范围。只有元数据足够稳定，搜索、推荐和自动更新才有可靠基础。
最后是贡献者指南。
我需要明确什么样的 Skill 值得加入，如何声明上游来源，如何避免触发冲突，提交前要运行哪些检查，以及元 Skill 应该怎样引用子 Skill。
从四十八到一百一十六，我学到的最大教训是，收集内容很快，维护体系很慢。
一个收藏夹只需要拥有者觉得有用。
一个开源项目还需要让陌生人看得懂、装得上、用得动、改得了，并且知道哪些部分值得信任。
Dog-Skills 真正需要构建的，已经不再是更多提示词。
而是一套让这些提示词可以长期共存的秩序。