你有一个团队技能库放在 /opt/brain/skills，于是在系统提示词里告诉 agent：“新技能请创建到 /opt/brain/skills。“它点头答应，然后 skill_manage 照样把每个新技能写进 ~/.hermes/skills/——因为工具的代码不读你的散文。有位社区运维被折腾烦了，干脆把本地技能目录 chmod 成只读，逼 agent 乖乖听话；最后是操作系统报错赢了提示词。9 月 1 日合并的修复（PR #100377）彻底结束了这场拉锯战：新配置项 skills.create_dir 可以把 agent 创建的新技能路由到任意目录——而且所有提到创建路径的地方，从 skill_manage 工具 schema 到提示词文本，都会动态渲染你配置的目录。工具、提示词、配置，三方终于一致。

为什么一句提示词做不到这件事

skill_manage 的创建路径是写死在 profile 本地技能目录（~/.hermes/skills/）里的。你可以在系统提示词里写任何话，但工具实现读的是配置和路径，不是意图。人类说“把技能放到 /opt/brain/skills”，工具写进 ~/.hermes/skills/——技能照样创建、照样被发现、照样能用，所以不会有响亮的报错；错位只是悄悄累积：技能进了错误的地方，事后还得手动搬。只读目录这种 hack 之所以“有效”，只是因为让默认路径失败，这绝不是执行策略的好办法。

修复方案：一个配置项，指令自动跟随

在 ~/.hermes/config.yaml 里加上：

skills:
  create_dir: /opt/brain/skills

就这一处配置，剩下的自动生效：

• skill_manage 把新技能建到这里——工具的 _resolve_skill_dir() 直接指向配置目录（首次写入时自动 mkdir，目录不存在也没关系）。
• 所有提到路径的指令一起跟随。 skill_manage 的工具 schema 描述、提示词文本、文档都会通过 display_skill_create_dir() 渲染成你配置的目录——agent 在自己的工具文档里看到的就是“新技能落在 /opt/brain/skills/”，而不是一条写死的旧路径。
• 支持 ~ 和 ${VAR} 展开，相对路径按 HERMES_HOME 解析——所以 create_dir: team-skills 就等于 $HERMES_HOME/team-skills。
• 解析结果等于默认本地目录的值会被视为未设置（那本来就是默认行为），不会出现配了半天又配回原路径的情况。

发现、信任与只读场景

技能只有能被再次找到才有用。设置了 skills.create_dir 后，该目录会按顺序折进技能搜索路径，紧跟本地技能目录之后（与 external_dirs 去重）——在这里创建的技能会被发现、信任、并支持原地修改。引发整件事的只读 hack 也不再必要：create_dir 指向别处后，本地技能目录即使只读也不会再挡住创建，因为工具根本不会碰它。

一个优先级提醒：受信任的项目级技能（仓库自己的 .hermes/skills/，见我们的项目级技能指南）优先级依然高于本地目录，这一点没有变化。

该指向哪里

• 团队共享库，纳入 git 管理（/opt/brain/skills 或仓库子目录）：这台机器上所有 agent——跨机器同步也一样——都往共享库里创建技能，技能像代码一样被版本化、被评审。
• 临时/工作目录：把 ~/.hermes/skills/ 留给手工精调的核心技能，让实验性技能落在可丢弃的地方。
• 多 profile 家庭环境：把 create_dir 指向共享位置，任何一个 profile 下创建的新技能所有 profile 都能看到。

发布状态

skills.create_dir 于 9 月 1 日合并（PR #100377，salvage 自 @giwaov 的社区工作，命名取自 @Frosti7 的 PR #81002），目前在 main 上——它在 v0.21.0 标签（8 月 31 日发布）之后合并，所以不在 v0.21.0 里，要等下一个版本发布。想看更完整的技能生态，可以读我们的八大技能指南和桌面技能中心一文。