OpenClaw技能包推荐：成本要从哪几项算起
内置 Skills、本地技能和社区包不是同一种东西。OpenClaw技能包推荐如果只问“哪个更强”，很容易选错。更实用的问法是：这个能力是不是通用能力，是否包含团队私有规则，需不需要外部服务，出了问题谁来维护。
内置 Skills 适合做基础盘
内置 Skills 的优势是随环境提供，加载和兼容性相对稳定。浏览器、基础工具、常见工作流说明这类能力，适合优先使用内置版本。它们通常不需要你维护一套额外文件，升级时也更容易跟主程序保持一致。
内置能力的边界也清楚：它不会天然懂你的团队流程、命名规范、审批规则和项目目录。拿内置 Skills 做基础盘没问题，别指望它替代项目知识库和团队约定。
本地技能写给自己的流程
本地技能适合承载私有流程，比如“发布前必须跑哪些检查”“客服工单如何分类”“某个项目目录怎么生成周报”。这类内容不适合发到公共技能库，也不该散在聊天记录里。写成 SKILL.md 后，agent 更容易在合适场景触发。
判断本地技能是否写得好，看它能否让新人复现同一套流程。触发条件、输入文件、输出格式、失败处理、审批要求都要清楚。只写一段“按团队规范处理”，agent 仍然不知道该看哪个文件、跑哪个命令、找谁确认。
社区包用来补工具缺口
社区包的价值在于覆盖面广，很多外部工具、特定软件和小众流程已经有人做过。它适合补齐你不想从零写的能力。取舍标准要更严格：维护记录、依赖来源、权限说明、安装命令、是否能在测试环境复现。
- 通用且稳定：优先内置。
- 团队私有规则：写本地技能。
- 外部工具集成：考虑社区包。
- 高权限操作：优先自己写或 fork 后审查。
迁移时别只复制文件
从其他工具迁移 Skills 时，目录复制成功不等于 OpenClaw 能识别。要检查 SKILL.md 的元数据、描述和依赖声明，也要看 agent allowlist 是否允许它出现。迁移后跑一次 list 和 check，比直接让它处理真实任务更稳。
我的选择顺序是：能用内置就不装第三方，流程有团队差异就写本地，确实需要外部工具再找社区包。三类来源分清后，维护成本会低很多，权限边界也更容易向团队解释。
本地技能还有一个好处：可以把“不要做什么”写进去。比如不要直接发送客户消息，不要读取某些目录，不要在未通过测试时生成发布建议。这些负面规则放在团队约定里容易被忽略，写进本地 Skill 后，agent 每次进入相关任务都能看到边界。
社区包经过审查后也可以 fork 成本地版本。这样做适合高频流程：保留原能力，删掉不需要的权限，补上团队自己的失败处理和审批口径。
取舍不是一次完成的。项目变了，本地技能要改；外部服务变了，社区包要复测；基础能力变了，内置包也要重新熟悉。
当一个社区包只用到少量能力时，删掉多余部分再本地化，往往比长期保留整包更清楚。
如果本地技能只服务一个项目，就放在项目 workspace；跨项目复用的流程，再考虑放进共享目录。