技能介绍

要解决的问题

改一个技能的名字，远不止改目录。SKILL.md 的 frontmatter、_skillhub_meta.json、_meta.json、VERSION、CHANGELOG 行都要跟着动，目录名本身也要换。少同步一处，发布出去的就是一份自相矛盾的包：数字版本全对、name 还是旧名，门禁照样拦下来。更麻烦的是身份问题——SkillHub 靠 slug 认技能，换 slug 等于新建条目、旧版原地不动；想更新已有版本却误改 slug，旧技能就再也收不到新版本。

核心能力

scripts/rename_publish.py 把「改名 → 五源同步 → 清理 → 门禁 → 发布」固化成一条流水线，默认 dry-run，只有显式加 --apply 才真正写盘或发布。

--new-slug X：换身份。同步改五处 slug、重命名目录、替换正文里的路径引用。
--display-name：只动面板显示名，不动 slug。
--bump / --version：版本号进位，同样走五源同步。
--clean：清理运行产物，dry-run 下先列清单再执行。
--publish：五源校验 FAIL 直接中止，绝不带病发布。

复用而非重造：发布调用 zfl-skill-factory 的脚本，五源校验调用 five_source_check.py，显示名调用 zfl-skill-display-name。本技能只负责 slug 跨源同步与流程编排这层胶水。

依赖缺失时降级

两个私有工具启动即自检，任一缺失都不会崩溃：

缺发布器：打印「改名就绪 + 手动发布指引」；
缺五源门禁：退回内联最小三轴校验（version / slug / displayName==meta.name）；
缺显示名工具：内联直改 frontmatter 与 _skillhub_meta.json。

对内用户仍全自动复用；外部用户没有 zfl 工具链也能跑完本地改名与校验。

发布后端的三层解析

发布是带凭据的动作，本技能不持有任何 token。--publish 按优先级解析后端：--publish-cmd 或 ZFL_PUBLISH_CMD 显式指定（支持 {dir} {changelog} {dry} 占位符）；否则探测 publish_to_skillhub.py；都没有则给出手动指引。复用他人通道，只调对方已预授权的命令。

几个必须知道的坑

.skillignore 对 SkillHub 发布无效，正解是让脚本把日志写到系统临时目录；
发布前会把无扩展名根文件临时改名（LICENSE → LICENSE.md），发布后严格恢复；
先本地验证再发布，确认包内无运行产物；
退出码 0 / 1 可直接接入 CI 做阻断。

适用边界

适合已发布技能的改名重发、版本更新、显示名中文化与发布前清理校验。不适合从零首次发布（请走 factory 原流程），也不管跨账号的 token 与凭据管理。

截图预览

使用场景

技能改名后要保证 SKILL.md、_skillhub_meta.json、_meta.json、VERSION 五处 slug 一致再重发，避免发布出门禁。
更新已发布技能的新版本时保持 slug 不变，仅 bump 版本号并五源同步，让旧 skillId 收到新版本。
外部用户没有 zfl 工具链时，用 L1 发布命令复用自己已预授权的发布脚本，完成改名后走自己的通道发布。
发布前清理运行产物并跑一次只读诊断，确认包内没有 __pycache__、日志等不该进包的文件。

适合人员

在 SkillHub 发布并维护多个技能的维护者，需要一个统一流程把改名、五源校验、发布串起来，而不是手工改五处文件。
已安装 zfl-skill-factory 的内部用户，希望改名发布全自动复用既有工具链，保持 DRY 不重复造轮子。
没有私有工具链的外部贡献者，改技能名后要用自己已预授权的发布命令安全发布，且不希望任何技能接触发布凭据。
把技能发布接入 CI 流水线的工程团队，需要靠退出码 0/1 在门禁失败时阻断发布。

改名发布编排器