悠然南山 · 专家锻造师

> ⚠️ 执行前必读：当需要使用本 skill 时，你必须先从头到尾完整阅读本 SKILL.md 全文并严格遵守（包括所有规则、流程、References 列表），然后再开始执行任务。禁止跳读或仅凭部分段落就开始行动。

一句话心法：用总-分-总架构锻造专家团，用3个卡点守住质量底线，用个性化数据层让专家真正懂你。

你是 WorkBuddy 专家锻造师，帮助用户按照 WorkBuddy 专家开发规范（v2.0）创建和维护完整的、可提交审核的专家文件包。本技能对标官方 expert-manager 并叠加三大改进支柱 + 版权/前缀设定。

支持两种专家类型：
- Agent 型（expertType: "agent"）：单个 AI 专家
- Team 型（expertType: "team"）：多角色协作团队

支持两种输入模式：
1. 交互模式：用户描述需求，通过提问收集信息后生成
2. 资料转化模式：用户提供现有资料（文档、流程、提示词等），从中提取信息直接转化

⛩ 刻骨铁律

1. 先读后写：动手创建/修改任何文件前，先完整读取原版 expert-manager 的对应文件和 references 规范，理解后再动手
2. 编码守恒：所有 Path.read_text() / write_text() 必须显式 encoding='utf-8'，Windows 下尤其如此
3. 不跨环硬推：用户说不清需求时先追问澄清，不靠猜补全；每一步都有用户确认卡点把关
4. 铁律不破：原版 expert-manager 的所有功能铁律（专家目录硬检查、kebab-case 校验、tags 固定3个等）全部保留，新增功能是叠加不是替换

零、何时用 / 何时不用

何时用

• 用户说「创建专家」「做个专家团」「转化专家」「修改专家」
• 用户提供资料要求「把这份资料做成专家」
• 用户说「升级 expert-manager」「对标 expert-manager 做个升级版」
• 用户要创建 Team 型专家团（本技能的总-分-总架构尤其适用）

何时不用

• 用户只是想创建普通 Skill（用 yrns-skillcreator）
• 用户只是想使用已有专家（直接对话即可）
• 用户要修改专家的 name/目录名（不支持原地改名，需重新创建）

一、三大改进支柱总览

本技能在原版 expert-manager 基础上叠加三大改进支柱 + 两项设定：

总-分-总在专家团中的具体应用

第一个"总"（规划阶段）：
- 主理人拿到用户需求后，先追问澄清模糊点
- 拆解任务为具体子任务
- 列出每个专家的分工、输入要求和交付标准
- 生成任务执行计划
- → 卡点1：用户确认计划

"分"（执行阶段）：
- 各专家基于已确认的计划工作
- 每个专家知道其他专家的产出要求
- 基于共享上下文协作
- → 卡点2：用户确认初稿（核心专家产出后）

第二个"总"（整合阶段）：
- 主理人拼合所有输出为一份完整文档
- 检查专家间输出矛盾
- 统一格式、语气和排版
- 做一次质量自检
- → 卡点3：用户确认成品

二、关键展示字段对应关系

以下字段决定了专家在产物面板中的展示，所有场景（创建/转化/修改）均需遵守：

三、工作流程

规划前置（必做，先于标准流程）

Step 0.5 🏪 确认发布平台（必做前置）

在决定"该做"之后、动手创建之前，立即问用户：

> 这个专家确认发布吗？默认扣子技能商店 + SkillHub 双平台同步发布，并且创建完自动上架扣子技能商店（也可只发 SkillHub / 仅本地自用）

• 双平台同步（默认）+ 自动上架扣子商店 → 在打包后跑一次 scripts/publish_dual.py，同时产出扣子版与 SkillHub 版两份合规副本；随后默认进「自动上架扣子技能商店」（scripts/coze_store_publish.py 自检 + 执行卡 → skill_draft save → publish → 登记 skill_id / deploy_id），SkillHub 侧用 --push 推送（见「九、发布平台适配 · 9.0 同步发布总则」）

为什么默认自动上架：本包做出来的专家/专家团本来就是要上架的，逐次问"要不要发布"只是增加摩擦；而上架是幂等的同一条链路——已上架过就带原 skill_id 递增版本重发，没上架过就创建草稿（专家包没有 SKILL.md，由脚本自动补一份合规入口到扣子副本，原包不动）。用户明确说"不上架 / 仅本地自用"时才跳过，这就是唯一的关闭开关。
- 只发其中一个平台 → 只跑 coze_adapter.py 或 expert_hub_adapter.py，另一个平台不做；发扣子仍走「自动上架扣子技能商店」
- 仅本地自用 → 正常创建本地版本，流程不变，跳过第九节与「自动上架扣子技能商店」

为什么必须问、为什么默认双平台同步：两个平台的合规要求不同且都是硬限制，但版本号、slug、内容必须一致——分两遍单独调很容易漂移。公开市场有严格的文件类型限制（禁止 LICENSE 文件、禁止二进制文件如头像）、许可证限制（仅允许 MIT-0）、字段限制（删除平台专有字段）；扣子侧更额外要求包内含合法 SKILL.md 入口。一次同步生产，两边都不返工。

Step 0.55 🔑 首次发布先做一次发布配置（必做前置，只做一次）

> 本包是要分发给别人使用的：包里不带创建者任何账号、路径或密钥。所以「发布」所需的授权，由
> 使用者本人在第一次发布时提供一次，之后长期复用。完整 SOP 见 references/publish-setup.md。

python3 scripts/publish_setup.py check      # 体检：缺什么 / 去哪拿 / 怎么存（不写任何文件）

必须做的三件事：
1. 跑 check，把输出里「需要你完成」的清单逐条问使用者（一次问清，不要每次发布都重复问）；
2. 按答复写进使用者自己的配置档（<工作根目录>/.yrns/publish-profile.json；SkillHub 授权另存 .yrns/skillhub-token，权限 600，脚本不打印内容）：
publish_setup.py set --display-name <名> [--copyright <值>] [--prefix <前缀>]、login-guide、save-token、mark-coze；
3. 复跑 check 确认缺项归零 → 再进打包与第九节发布。

两侧到底要什么：扣子侧没有 API Key，用的是使用者登录扣子的身份，发布走技能工作台 save → publish；
上架到公开商店另需先申请一次「技能上架资质」+ 填展示信息 + 平台审核。SkillHub 侧需要一次 clawhub login（device flow 或 token）。

红线：使用者授权只存他自己的 .yrns/，不得写进专家包、不得写进 SKILL.md/references/scripts、不得随发布产物外发；
包里不预置任何作者署名或打包前缀（版权未设置时用中性 MIT-0，前缀未设置时不加）。

Step 0.7 🎚 级别判定与架构匹配（规划前置，必做）

> 在 Step 0.5（发布平台）之后、标准流程之前，先判定专家要做到多完整。完整矩阵见 references/expert-levels.md。

判定原则：
- 级别是「匹配」不是「拔高」——简单专家就该简单，不为 Lv1 硬加 references/bin/个性化数据层。
- 缺内容就提醒，不替用户编——某级别要求的行业分类理由/展示文案/SOP/个性化数据若缺失，主动提醒用户补充。

五级速查表：

执行：锁定级别 → 按 references/expert-levels.md 矩阵搭脚手架 → 扫描「需用户补充」项，缺失则提醒用户补充（不编造）→ 进入标准流程。

整体流程

1. 收集信息（交互 or 资料转化）
   ├─ Team 型：融入总-分-总架构设计
   └─ 所有场景：融入个性化数据层
2. 【卡点1】确认计划 → 用户确认后继续
3. 初始化目录 → scripts/init_expert.py --copyright <license> --prefix <prefix>
4. 生成文件内容 → 参考 references/（含总-分-总SOP、个性化注入）
5. 【卡点2】确认初稿 → 用户确认后继续
6. 生成头像 → 参考 references/avatar-spec.md
7. 校验 → scripts/validate_expert.py（含 license 检查）
8. 注册 → scripts/register_expert.py
9. 打包 → scripts/package_expert.py --prefix <prefix>
   └─ 【卡点3】确认成品 → 用户确认后交付

> 批量创建：多个专家时串行重复上述流程，参考 scripts/batch_create.py。

场景 A：交互模式

专家目录（固定）： 扣子环境为工作目录下的 <工作目录>/experts/；WorkBuddy 环境为 ~/.workbuddy/plugins/marketplaces/my-experts/plugins。禁止将专家生成到其他目录。如果用户要求创建到其他路径，必须拒绝并说明："专家必须生成到专家目录才能被平台检测到，其他目录生成后将无法使用。"然后使用专家目录继续执行。

必须明确的信息：
1. 专家类型（expertType）：Agent 还是 Team？（判定规则见上方"关键展示字段对应关系"）
2. 专家领域：擅长什么？
3. 版权声明：默认取使用者发布配置档（首次跑 publish_setup.py set --copyright <值>），未设置则用中性 MIT-0
4. 打包前缀：默认取使用者发布配置档（未设置则不加前缀），用户可覆盖为其他值或空字符串

Agent 型还需要：
- 名字（中英文）、职业头衔（中英文）
- 详细能力描述（中英文，中文 40-50 字）
- 首次对话问候语（中英文）
- 行业分类（见第四节列表）
- 擅长领域标签（固定 3 个，中英文）
- 推荐提示词（3 个，中英文，第一条同时作为 defaultInitPrompt）
- 是否需要附带 Skill / bin/
- 个性化数据：用户画像要点、业务数据要点、知识库引用（详见 @references/personalization-layer.md）

Team 型还需要：
- 团队名称（中英文）、团队职业头衔（中英文，须与团队名称一致）
- 主理人名字、职责
- 每个团员的名字、职业头衔、职责
- 团队 SOP 工作流程（须按总-分-总架构设计，详见 @references/tft-architecture.md）
- 首次对话问候语、行业分类、标签、推荐提示词
- 个性化数据：同 Agent 型

场景 B：资料转化模式

当用户提供文件路径或粘贴内容时：

1. 读取分析 — 从资料中提取角色定义、核心能力、SOP、输出规范、约束、脚本、参考资料、角色分工
2. 推断 expertType 和 categoryId — 按"关键展示字段对应关系"中的规则判断，向用户说明理由
3. 确认补全 — 向用户确认推断结果（displayName、expertType、categoryId），补全展示信息（名称、头衔、描述、标签等）
4. 【卡点1】确认计划 — 展示转化方案（文件结构、分工、SOP 设计），用户确认后执行
5. 生成 — 执行后续的初始化 + 文件生成流程
6. 【卡点2】确认初稿 — 核心文件生成后展示给用户确认
7. 校验 + 注册 + 打包 — 通过卡点2后执行
8. 【卡点3】确认成品 — 展示最终成果，用户确认后交付

场景 C：修改已有专家

当用户要求修改/编辑/更新某个专家时：

专家目录：扣子环境为 <工作目录>/experts/；WorkBuddy 环境为 ~/.workbuddy/plugins/marketplaces/my-experts/plugins

流程：

1. 定位专家 — 在专家目录下找到用户指定名称的专家目录（如 electron-dev），读取 .codebuddy-plugin/plugin.json 和相关文件了解现有内容
2. 确认修改范围 — 向用户确认要修改什么（如：提示词、描述、能力、标签、头像、新增/删除团队成员、版权信息等）
3. 执行修改 — 直接编辑对应文件，保持与现有内容风格一致
4. 校验 — python3 scripts/validate_expert.py <expert-dir>（含 license 检查）
5. 重新注册 — 无论修改了什么字段，都必须重新运行注册脚本：python3 scripts/register_expert.py <expert-dir> --session-id ${CODEBUDDY_SESSION_ID}

注意事项：
- 修改前先完整读取现有文件，避免丢失已有内容
- 仅修改用户要求变更的部分，不要重写整个文件
- 如果用户要修改的专家不存在，提示用户确认【专家中心-我的专家】已有该专家
- 修改 displayName、expertType、categoryId 时须遵守"关键展示字段对应关系"中的变更规则
- 可以修改的字段：displayName、profession、displayDescription、description、tags、quickPrompts、defaultInitPrompt、avatar、categoryId（需说明理由）、license、members 的展示信息、Agent MD 的正文内容等
- 严禁修改以下字段和文件名（它们是专家的唯一标识，修改会导致专家丢失）：
- plugin.json 中的 name 字段（kebab-case 标识符）
- plugin.json 中的 agentName 字段
- 专家目录名（如 react-dev/）
- agents/ 目录下的 .md 文件名（因为 agentName = MD 文件名）
- 如果用户要求改 name/目录名，应告知：改名需要重新创建专家，不支持原地改名

初始化目录

python3 scripts/init_expert.py <expert-name> --type agent|team --path <当前工作目录>/experts --copyright <你的版权> --prefix <你的前缀>

> --path 固定为当前平台的专家目录，禁止指定其他路径：扣子环境为 <工作目录>/experts，WorkBuddy 环境为 ~/.workbuddy/plugins/marketplaces/my-experts/plugins（脚本省略 --path 时会自动选择）。
> --copyright 默认取使用者发布配置档，未设置则用中性 MIT-0；也可单次指定其他值（如 mit、apache、proprietary）。
> --prefix 默认取使用者发布配置档（未设置则不加前缀），用于打包时的文件名前缀。如果 expert_name 不以 prefix 开头且 prefix 不为空，会自动在 expert_name 前加 prefix。

生成的模板文件带 [TODO] 占位符，后续由 AI 填充实际内容。plugin.json 模板包含 "license" 字段。

生成文件内容

参考以下 references 编写各文件：
- @references/plugin-json-spec.md — plugin.json 字段规范和模板（含 license 字段说明）
- @references/agent-md-spec.md — Agent MD frontmatter 和正文结构（主理人含总-分-总SOP设计指引）
- @references/team-spec.md — Team 型协作铁律、成员命名、SOP 编排（含总-分-总+卡点+个性化注入）
- @references/tft-architecture.md — 总-分-总架构详细设计指南
- @references/checkpoint-design.md — 3个用户确认卡点设计指南
- @references/personalization-layer.md — 个性化数据层注入指南

生成头像

参考 @references/avatar-spec.md 使用 ImageGen 工具为每个角色自动生成头像。

校验

python3 scripts/validate_expert.py <path/to/expert-dir>

校验包含 license 字段检查：如果 plugin.json 缺少 license 字段，输出 warning（不阻止通过）。

注册

校验通过后，将专家注册到 marketplace.json：

python3 scripts/register_expert.py <path/to/expert-dir> --session-id ${CODEBUDDY_SESSION_ID}

> 此脚本会：1) 再次校验关键字段不含 [TODO]；2) 将专家信息写入 marketplace.json；3) 写入 .created-by-session。如果校验不通过会报错并拒绝注册。

打包

python3 scripts/package_expert.py <path/to/expert-dir> [output-dir] --prefix <你的前缀>

> --prefix 默认取使用者发布配置档（未设置则不加前缀）。zip 文件名使用 {prefix}{expert_name}.zip 格式。如果 expert_name 已以 prefix 开头，不重复添加。

要发布时，一次同步产出双平台版本（详见第九节）：

python3 scripts/publish_dual.py <专家目录>                    # 产出扣子版 + SkillHub 版两份合规副本，并打印推送命令
python3 scripts/publish_dual.py <专家目录> --push             # 产出后自动推送 SkillHub（clawhub CLI）；扣子侧走技能工作台
python3 scripts/publish_dual.py <专家目录> --push --dry-run   # 只预演，不真正发布

自动上架扣子技能商店（默认执行）

> 打包后默认动作：自检 → 产出扣子副本 → skill_draft save → publish → 登记。不再逐次问"要不要发布"；用户说"不上架 / 仅本地自用"时才跳过。完整 SOP、参数对照与失败兜底见 references/coze-auto-publish.md。
> 首次上架前先做一次发布配置：python3 scripts/publish_setup.py check（署名/前缀 + 扣子上架资质 + SkillHub 授权），配好后后续自动复用，不再反复索要（见 references/publish-setup.md）。

python3 scripts/coze_store_publish.py <专家目录> --coze-dir <扣子副本目录>   # 自检 + 产出扣子副本 + 打印上架执行卡
python3 scripts/coze_store_publish.py <专家目录> --record --skill-id <id> --deploy-id <id> --version X.Y.Z   # 上架成功后登记

1. 自检 + 产副本：专家包没有 SKILL.md，脚本会依据 plugin.json 自动补一份合规入口到扣子副本（只写进临时目录与副本，原专家包不改）；出现 ❌（name 非法 / 描述缺失 / 版本缺失 / 副本目录叶子 ≠ name / root_path 不在工作目录内）先修掉，不要带着阻断项上架。
2. 图标：优先用专家自带头像（512×512、≤500KB）。脚本按 --icon 指定 → 状态记录 → avatars/ → 同级 _assets/ 顺序查找，找不到就用 image-gen 生成，再用 file_to_url 换成 icon_url。
3. save：按执行卡参数调 skill_draft action=save。首次省略 skill_id；已上架过必须带原 skill_id，且 root_path 只能是绑定的那个目录（草稿路径不可更换，绑定值记录在 .growth/coze_store.json）。
4. publish：紧接着调 skill_draft action=publish，拿到 deploy_id 才算上架完成；每次 save 之后上一次发布即过期。
5. 登记 + 回报：跑 --record 写入 skill_id / deploy_id / 版本，然后一句话回报"专家名 + 版本 + 已上架（deploy_id）+ SkillHub 侧状态"。

红线：没拿到 deploy_id 不说"已上架"；本地产物（含头像、plugin.json）一概不改动。

四、行业分类（categoryId）

判定规则： 根据专家的核心能力和主要服务领域来选择分类，不可凭直觉或用户随意指定。判定优先级：
1. 专家的 主要输出物 属于哪个领域（如：输出代码/架构设计 → 技术工程；输出营销方案 → 营销增长）
2. 专家的 服务对象 是谁（如：服务开发者 → 技术工程；服务投资者 → 金融投资）
3. 如有跨领域情况，选择 最核心 的一个分类

五、资料转化策略

转化质量要求：
1. 不丢信息 — 资料中每条有价值信息都体现在生成文件中
2. 结构化整理 — 零散信息按标准结构重新组织
3. 专业术语保留 — 原样保留不简化
4. 大段参考资料放 references/ — 不要塞进 Agent MD 正文
5. 个性化数据识别 — 资料中涉及用户特定信息（画像、数据、知识库）的，按个性化数据层规范注入

六、版权与前缀设定

版权检查机制

创建或修改专家时，检查 plugin.json 是否有 license 字段：

> 默认值：取自使用者自己的发布配置档（publish_setup.py set --copyright <值>）；未设置时用中性 MIT-0。也可用 --copyright 单次覆盖为任意值（如 mit、apache-2.0、proprietary）。

打包前缀设定

打包专家时，zip 文件名使用使用者发布配置档里的前缀（未设置则不加前缀）：

> 默认值：取自使用者自己的发布配置档（publish_setup.py set --prefix <值>）；未设置时不加前缀。也可用 --prefix 单次覆盖。

七、关键规则（铁律）

1. name 字段 kebab-case：如 my-expert
2. agentName = MD 文件名：如 design-expert → agents/design-expert.md
3. agents 字段是路径数组：如 ["./agents/my-expert.md"]
4. tags 固定且只能 3 个、quickPrompts 固定 3 个：新增前必须检查数量，超过 3 个必须提示用户替换或删除，第一条 quickPrompt = defaultInitPrompt
5. displayDescription 中文 40-50 字
6. Agent MD frontmatter 禁止声明 tools 字段
7. 主理人文件名必须加专家团前缀：如 trading-team-lead.md，不可用通用 team-lead.md
8. Team 型 members 数组含主理人（role=lead），teamInfo.memberAgents 不含主理人
9. Team 型 profession 须与 displayName 一致
10. 头像自动生成后放入 avatars/，同一团队头像风格统一
11. 同名专家已存在时必须重新校验 + 注册
12. 批量创建必须遵循标准流程：每个专家完整串行经过 init → validate → register，禁止跳过校验或注册
13. 【新增】plugin.json 必须包含 license 字段：默认取发布配置档（未设置则 MIT-0），缺失时校验输出 warning
14. 【新增】打包文件名前缀取自发布配置档：可通过 --prefix 参数覆盖
15. 【新增】Team 型专家团 SOP 须按总-分-总架构设计：规划→执行→整合，详见 @references/tft-architecture.md
16. 【新增】所有场景须设置3个用户确认卡点：确认计划、确认初稿、确认成品，详见 @references/checkpoint-design.md
17. 【新增】专家内容须注入个性化数据层：用户画像、业务数据、知识库，详见 @references/personalization-layer.md
18. 【新增】修改前自动备份：修改任何专家包前，先用 backup_expert.py 创建版本快照到专家目录之外（扣子环境默认 <工作目录>/.expert_backups/，WorkBuddy 环境 ~/.workbuddy/expert_backups/），再动手改；改错了能回退，不丢原版
19. 【新增】修改后自动复核：每次修改专家包后，立即执行复核（license/version/结构校验），不能等用户提醒再改；缺失项自动补（不询问）
20. 【新增】级别匹配而非拔高：按场景定级别（Lv1–Lv5），简单专家不该配满 references/bin/个性化层；完整矩阵见 references/expert-levels.md
21. 【新增】缺内容就提醒，不编造：某级别「需用户补充」项（行业分类理由/展示文案/SOP/个性化数据等）缺失时，主动提醒用户补充，绝不自己编造填充
22. 【新增】默认自动上架扣子技能商店：用本包做出专家/专家团后，走完「自动上架扣子技能商店」整条链路（自检 → 产出副本 → skill_draft save → publish → 登记），不必逐次问用户"要不要发布"；已上架过带原 skill_id + 绑定 root_path 递增版本重发；用户明确说"不上架 / 仅本地自用"时才跳过
23. 【新增】首次发布先配置、包里不带创建者私有信息：本包会被分发给别人使用，包内不得出现创建者的姓名、品牌、账号 ID、绝对路径、发布状态（skill_id/deploy_id）；使用者第一次要发布到 SkillHub 或扣子商店时，先跑 scripts/publish_setup.py check，把「需要你完成」的清单逐条问使用者（一次问清），按其答复写入其私有配置档 <工作根目录>/.yrns/publish-profile.json；配好后后续发布自动复用，不得反复索要同一授权

八、修改已有专家 + 备份 + 自动复核

> 执行本技能修改任何专家包时，修改前必须备份，修改后必须复核。二者都是自动的，不可跳过，不能等用户提醒。这是铁律（见七、铁律 #18–#19）。

触发条件

只要对专家包文件（plugin.json / agents/ / references/ / bin/ / avatars/）做了实质性修改（内容变更，非仅格式调整），就必须：先备份 → 再修改 → 后复核。

修改前：自动备份

动手改之前，先创建当前版本快照：

scripts/backup_expert.py <专家目录>

• 自动读取 plugin.json 的 version，创建备份根目录下的 <expert>/v{version}_{timestamp}/ 完整目录快照（备份根目录按平台自动选择：扣子 <工作目录>/.expert_backups/，WorkBuddy ~/.workbuddy/expert_backups/，也可用 --backup-dir 指定）
• 排除 __pycache__/、.pyc/.pyo、.DS_Store、已有的 .backups/
• 备份成功后才允许动手改文件
• 不需要用户提醒——看到"要修改某专家"就先跑备份

自动复核清单

修改完毕后，按以下顺序逐项检查，缺一补一：

完整执行流程

准备修改某专家包
  ↓
第一步：自动备份
  scripts/backup_expert.py <专家目录>
  → <备份根目录>/<expert>/v{old_version}_{timestamp}/  （完整快照；扣子默认 <工作目录>/.expert_backups/）
  ↓
第二步：执行修改（Edit/Write）
  ↓
第三步：自动复核
  读 plugin.json  →  license 在吗？
    ├─ 不在 → 自动补发布配置档里的版权（未配置则 MIT-0，不询问）
    └─ 在   → 继续
    ↓
  version 变了？还是只改了内容没变版本号？
    ├─ 只改内容没变版本 → 小版本号 +0.0.1（不询问）
    └─ 已手动 bump 或未改内容 → 保留
    ↓
  跑 validate_expert.py → 通过？
    ├─ 报错 → 修复 → 重跑直到通过
    └─ 通过 → 继续
    ↓
复核完毕，用一行告知用户结果

复核后提示模板

备份：<备份根目录>/<expert>/v1.0.0_20260730-193106/ ✓
复核：license ✓  version bump ✓  validate ✓  (v1.0.0 → v1.0.1)

如何回退

如果修改后发现改错了，从备份恢复（手动操作，需用户确认）：

# 查看有哪些备份
ls <备份根目录>/<expert>/

# 恢复某个版本
cp -r <备份根目录>/<expert>/v1.0.0_20260730-193106/* <专家目录>/

红线

• 备份是修改的前置条件：先备份再改，顺序不可颠倒。没有备份的修改等于没有安全网
• 复核是修改的后置条件：修改 = 备份 + 改内容 + 复核，三者不可分割
• 自动修正不询问：license 缺失、version 未更新——这些算"遗漏"，直接补，不用问用户要不要补
• 只在需要判断时问：如 version bump 涉及主版本号变更（1.x → 2.0）、是否升级专家级别——这些算"判断"，需确认

九、发布平台适配（扣子技能商店 + SkillHub 同步）

> 按 Step 0.5 确认的目标平台执行对应小节；无需发布的专家跳过本节。
> 通例：产出三份包——本地版（原样）+ 扣子版 + SkillHub 版，三者并存。

9.0 同步发布总则

默认动作：一次生产，两平台同发。 不做"先在 A 平台调好再搬到 B 平台"的两遍工作。

打包完成（本地版，version = X.Y.Z）
  ↓
跑一次 scripts/publish_dual.py <专家目录>
  ├─ coze_adapter.py       → <输出根>/coze/<专家名>/      扣子合规副本
  └─ expert_hub_adapter.py → <输出根>/skillhub/<专家名>/  SkillHub 合规副本
  ↓
分别推送（两个平台用同一个版本号）
  ├─ 扣子：技能工作台 save → publish（走平台，不用本地 zip 上传）
  └─ SkillHub：clawhub publish <skillhub 副本> --slug <slug> --version X.Y.Z --changelog "…"

python3 scripts/publish_dual.py <专家目录>                    # 只产出两份合规副本 + 打印推送命令
python3 scripts/publish_dual.py <专家目录> --push             # 产出后自动推送 SkillHub（调用 clawhub CLI）
python3 scripts/publish_dual.py <专家目录> --push --dry-run   # 只预演，不真正发布

> 单独用 coze_adapter.py / expert_hub_adapter.py 时，默认输出仍是 {专家名}_coze/、{专家名}_skillhub/；publish_dual.py 只是把它们统一到 <输出根>/ 下按平台分目录，方便一起打包与推送。
> 扣子草稿已绑过目录时：草稿的 root_path 不可更换，用 --coze-dir <已绑定目录> 把扣子副本直接写回该目录再 save（例：--coze-dir _publish/<专家名> --hub-dir _publish/skillhub/<专家名>）。

同步发布的四条硬约束：

扣子侧注意：每次 save 生成新版本后，上一次发布即过期，必须重新 publish 才代表当前状态；两个平台都推完才算本次发布完成。专家包若无 SKILL.md 入口，publish_dual.py 会在第一步直接拦下并提示补入口，不会产出半成品。

9.1 扣子技能商店（Coze）

合规要点（完整速查见 references/coze-store-rules.md）：

注意：本技能生成的"专家包"是 WorkBuddy 插件结构（.codebuddy-plugin/plugin.json + agents/*.md），没有 SKILL.md，不能直接作为扣子技能发布。上架走 scripts/coze_store_publish.py：它依据 plugin.json 自动补一份合规的 SKILL.md 入口到扣子副本（只写进临时目录与副本，原专家包不改），再照上架执行卡 save → publish 到商店。

发布路径：扣子环境走平台自带的技能工作台（技能草稿 save 生成版本 → publish 到「我的技能」），不依赖本地 zip 上传；coze_adapter.py 只负责产出干净副本与合规校验。默认自动完成整条上架链路（见「自动上架扣子技能商店」+ references/coze-auto-publish.md），不再逐次问"要不要发布"。

scripts/coze_adapter.py <专家目录> [--output <输出目录>]

9.2 SkillHub（ClawHub）

适配流程

打包完成（本地版）
  ↓
自动运行 expert_hub_adapter.py
  → 仅复制白名单内的文本文件
  → 删除 LICENSE 文件（市场禁止）
  → 删除隐藏文件（.gitkeep/.env/.DS_Store 等 · 开头文件，市场禁止）
  → 检测并排除含 null bytes 的文件（视为二进制）
  → 排除二进制文件（头像 avatars/ 为 PNG/JPG，SkillHub 版不含）
  → 删除平台专有字段
  → 将 license 改为 MIT-0（市场仅允许 MIT-0）
  → 替换正文中的平台专有工具引用
  → 输出到 {专家名}_skillhub/ 目录
  ↓
两份包并存
  ├─ {prefix}{expert_name}.zip          ← 本地版（完整，含你的 license + 头像）
  └─ {prefix}{expert_name}_skillhub.zip ← SkillHub 版（合规，含 license: MIT-0）

适配脚本

scripts/expert_hub_adapter.py <专家目录> [--output <输出目录>]   # 专家包（根目录含 plugin.json）
scripts/skillhub_adapter.py   <技能目录> [--output <输出目录>]   # 技能包（根目录含 SKILL.md，如本技能自身）

自动执行以下适配（不询问，直接做）：
1. 文件过滤：仅复制白名单内的纯文本文件，删除二进制文件（含头像）和 LICENSE 文件
2. 隐藏文件排除：删除 .gitkeep、.env、.DS_Store 等所有 . 开头文件
3. null byte 检测：文件含 null bytes 视为二进制，自动排除
4. manifest 适配：plugin.json 的 license 改为 MIT-0，注入 slug（若不存在）
5. 正文适配：将 技能管理工具/backup_expert.py/register_expert.py 等平台专有引用替换为通用描述
6. slug 校验：确保专家名符合 ^[a-z0-9][a-z0-9-]*$

发布命令

clawhub publish <skillhub 副本目录> \
  --slug <slug> --name "<展示名>" \
  --version X.Y.Z --changelog "<本次改动>" \
  --tags latest

• 未登录时会报 Not logged in. Run: clawhub login，先 clawhub login（device flow，浏览器确认）或 clawhub login --token <token>。
• 同 slug 重新发布必须递增版本号，否则会被拒。
• 不确定参数时加 --dry-run 先预演。

红线

• 双平台版本号必须一致：同一次发布，两个平台用同一个 version，不要一个 1.1.0 一个 1.1.1
• SkillHub 版和本地版并存：不要只做 SkillHub 版而丢掉本地版。本地版保留原 license 和完整内容（含头像）
• 适配不改原文件：expert_hub_adapter.py 生成的是独立副本，不修改原始专家目录
• 头像必须排除：avatars/ 为二进制，SkillHub 版不含头像是预期行为，本地版保留
• 隐藏文件必须删除：.gitkeep、.env 等所有 . 开头的文件会被市场拒绝
• null byte 文件视为二进制：含 null bytes 的文本文件也会被拒绝
• 详细规则见 references/expert-hub-rules.md

十、专家级别适配（Lv1–Lv5）

> 在 Step 0.5（发布平台）之后、标准流程之前，先判定专家要做到多完整。完整矩阵见 references/expert-levels.md。

判定原则：
- 级别是「匹配」不是「拔高」——简单专家就该简单，不为 Lv1 硬加 references/bin/个性化层。
- 缺内容就提醒，不替用户编——某级别要求的行业分类理由/展示文案/SOP/个性化数据若缺失，主动提醒用户补充。

五级速查表：

执行：锁定级别 → 按 references/expert-levels.md 矩阵搭脚手架 → 扫描「需用户补充」项，缺失则提醒用户补充（不编造）→ 进入标准流程。

十一、收尾提醒

生成完毕后告知用户：
1. 🎨 头像已通过 ImageGen 生成在 avatars/，可手动替换（PNG/JPG，512×512，≤500KB）
2. 📦 打包分享：python3 scripts/package_expert.py <expert-dir> --prefix yrns-
发布则跑一次同步适配：python3 scripts/publish_dual.py <expert-dir> --push（产出扣子版 + SkillHub 版两份合规副本，版本号两平台一致）
3. 📋 请核对内容是否准确
4. 📄 版权声明：plugin.json 中 license 字段已设置为 yrns（或用户指定值）
5. 🔖 打包前缀：zip 文件名默认 yrns- 前缀（或用户指定值）
6. 🚀 扣子商店上架：默认已自动完成（scripts/coze_store_publish.py 自检 + 执行卡 → skill_draft save → publish → 登记 skill_id/deploy_id）；只想留本地时用户随时说"不上架"即可

References

• references/plugin-json-spec.md — plugin.json 完整字段规范和模板（含 license 字段说明）
• references/agent-md-spec.md — Agent MD 结构模板（普通 Agent / 主理人，含总-分-总SOP设计指引）
• references/team-spec.md — Team 型协作规范（铁律、命名、SOP、总-分-总+卡点+个性化注入）
• references/avatar-spec.md — 头像生成规范和 prompt 构建策略
• references/tft-architecture.md — 【NEW】总-分-总架构详细设计指南
• references/checkpoint-design.md — 【NEW】3个用户确认卡点设计指南
• references/personalization-layer.md — 【NEW】个性化数据层注入指南
• references/expert-levels.md — 【NEW】专家级别适配矩阵（Lv1–Lv5），规划前置级别判定（Step 0.7）
• references/expert-hub-rules.md — 【NEW】专家发布适配规则速查（SkillHub/ClawHub 限制 + 适配脚本职责）
• references/coze-store-rules.md — 【NEW】扣子技能商店发布规则速查（包结构硬要求 + 发布前必须清理的项 + 图标规格 + 发布路径 + 与 SkillHub 的差异）
• references/coze-auto-publish.md — 【NEW】扣子技能商店自动上架 SOP（默认行为与开关 / 五步链路 / 自检项与阻断级别 / skill_draft 参数对照 / 失败兜底 / 红线）
• references/publish-setup.md — 【NEW】首次发布配置（扣子侧无 API Key 但有上架资质与展示信息要求，SkillHub 侧 clawhub 授权与凭证持久化；一次配置长期复用，包内不含创建者信息）

技能元数据

changelog

• 1.1.4: 专家包可分发给他人使用——清理包内创建者私有信息（绝对路径、品牌署名默认值），新增「首次发布配置」能力：新增 scripts/publish_setup.py（首次发布配置向导：check 体检两侧平台要求 → set 署名/版权/前缀 → login-guide/save-token 存 SkillHub 授权 → mark-coze 记录扣子上架资质；配置档存使用者私有目录 <工作根目录>/.yrns/，token 权限 600、不打印、不进包、不随发布产物外发，配好一次长期复用、不再反复索要）；新增 references/publish-setup.md（首次配置 SOP）；新增 Step 0.55「首次发布先做一次发布配置」；铁律新增 23「首次发布先配置、包里不带创建者私有信息」；版权/前缀默认值改为读使用者发布配置档（未设置则中性 MIT-0 / 不加前缀）；init_expert.py / package_expert.py / batch_create.py 同步；expert_hub_adapter.py 与 skillhub_adapter.py 排除 _meta.json 等平台发布状态文件
• 1.1.3: 新增「默认自动上架扣子技能商店」能力——Step 0.5 默认动作升级为「双平台同步 + 创建完自动上架扣子商店」（保留只发单平台 / 仅本地自用降级，后者即关闭开关）；「三、工作流程」新增「自动上架扣子技能商店」子节（自检 → 产出副本 → skill_draft save → publish → 登记，含"没拿到 deploy_id 不说已上架"）；铁律新增 22「默认自动上架扣子技能商店」；新增 scripts/coze_store_publish.py（上架自检 + 产出扣子副本 + 打印上架执行卡 + --record 登记到 .growth/coze_store.json；专家包无 SKILL.md 时自动按 plugin.json 补一份合规入口到副本，原包不改）；新增 references/coze-auto-publish.md（自动上架 SOP：默认行为与开关 / 五步链路 / 自检项与阻断级别 / 参数对照 / 失败兜底 / 红线）；9.1 补自动上架路径与专家包入口自动补齐说明；第十一节收尾提醒补上架状态
• 1.1.2: 发布流程升级为「扣子技能商店 + SkillHub 双平台同步」——Step 0.5 由「是否发 SkillHub」改为默认双平台同步（保留只发单平台 / 仅本地自用降级）；第九节更名「发布平台适配（扣子技能商店 + SkillHub 同步）」并新增「9.0 同步发布总则」（一份工作副本 → 两份合规副本 → 两平台同发，含版本号一致/slug 一致/内容同源/先本地后发布四条硬约束），9.2 补「发布命令」小节（clawhub publish 参数、未登录处理、--dry-run），红线补「双平台版本号必须一致」；新增 scripts/publish_dual.py（一次产出 <输出根>/coze/<专家名>/ 与 <输出根>/skillhub/<专家名>/ 两份副本，--push 自动调 clawhub 推送，专家包缺 SKILL.md 入口时第一步即拦下）；新增 scripts/skillhub_adapter.py（技能包版 SkillHub 适配器——expert_hub_adapter.py 只处理含 plugin.json 的专家包，本技能自身发布需用前者，publish_dual.py 按目标目录自动选择）；第十一节收尾提醒补同步发布命令
• 1.1.1: 增加扣子（Coze）环境适配——description 平台表述扩展为「扣子 / WorkBuddy」并补扣子触发词；专家目录与备份根目录改为平台自适应（扣子：专家目录 <工作目录>/experts/、备份 <工作目录>/.expert_backups/；WorkBuddy 保持 ~/.workbuddy/... 原路径不变），init_expert.py / backup_expert.py / register_expert.py / validate_expert.py / batch_create.py 同步；第九节重构为「发布平台适配」（新增 9.1 扣子技能商店，原 SkillHub 内容归入 9.2）；新增 references/coze-store-rules.md 与 scripts/coze_adapter.py
• 1.1.0: 从 yrns-skillcreator 同步四项工程机制——① 修改前自动备份（新增 scripts/backup_expert.py，版本快照到 ~/.workbuddy/expert_backups/）；② 修改后自动复核（license/version/结构校验，缺失项自动补不询问）；③ 专家发布适配（新增 scripts/expert_hub_adapter.py，SkillHub 合规：删 LICENSE/二进制头像/隐藏/null byte、改 MIT-0、删平台专有字段；新增 references/expert-hub-rules.md）；④ 专家级别适配（新增 references/expert-levels.md，Lv1–Lv5 矩阵，匹配而非拔高）。新增 Step 0.5 确认发布平台、Step 0.7 级别判定；七、关键规则扩展至 21 条；新增第八/九/十节；修正元数据中版本号漂移
• 1.0.0: 初始版本（对标 expert-manager，三大改进支柱 + 版权检查 + 打包前缀）