蒸馏发布一条龙（skill-publish-pipeline）

一句话：当你说"把 XX 蒸成 skill 发上去"，本 skill 管的是整条流水线——先查重、再决定怎么发（新建/补充分量/修老的）、按质量红线写、用真实能跑的 CLI 发出去、最后记进清单。上游"怎么写得好"看 system-to-skill 的三红线，下游"发完怎么备料"看 skillhub-publish-prep，本 skill 是编排层，不重抄它们。

和另外两个的关系：
- system-to-skill：管"系统怎么变成合规 SKILL.md"（质量）。本 skill 调用它，但不替它写正文。
- skillhub-publish-prep：管"备料 + 发布通道"。本 skill 的发布步骤改用真实 CLI 命令（见 §2，那个 skill 里的 skillhub 命令在本机已失效）。

适用场景

• 你写完一篇方法论/复盘/蓝图文章，想顺手蒸成 skill 发社区
• 你有一套跑通的工作流，想"去重判断后发上去"
• 你说"把 XX 蒸成 skill 发上去"——一句话触发整条流水线

边界

• 不替你写系统、不替你判断内容质量（那归 system-to-skill）
• 不发无 API 的平台（小报童需手动）；只发 SkillHub（有 CLI）
• 不替你做最终"该不该发"的商业判断——重叠时给你建议，你拍板

前置（首次确认一次）

真实 CLI（本机验证过，2026-08-23）：

# 真实可用的发布命令是这个 Python 脚本，不是 skillhub 命令（本机无 skillhub）
CLI="C:/Users/40280/.skillhub/skills_store_cli.py"
PY="C:/Users/40280/.workbuddy/binaries/python/versions/3.13.12/python.exe"

# ① 确认登录态（返回 userId 即有效）
$PY $CLI auth whoami
# 未登录：去 SkillHub 网页→账号→API keys→创建 key，然后
#   $PY $CLI login --key skh_xxx

> ⚠️ 别用 skillhub publish——本机 which skillhub 返回空，那条命令会失败。真发只用上面的 Python 脚本。

§3 去重判断工作流（本 skill 的核心新方法）

> 来源：2026-08-23 把"知识库搭建蓝图文章"蒸成 skill 时实战沉淀。当时文章 70% 和 knowledge-base-starter 重叠，但有三块老 skill 完全没有（真实踩坑复盘 / qmd 真配置 / 验收清单）——于是做成补充分量 knowledge-base-ops，不重抄、不占重复名额。

步骤：
1. 列出 ~/.workbuddy/skills/ 下所有 skill，读每个的 SKILL.md 的 description + 适用场景 + 触发词。
2. 拿本次要发的内容做重叠度定性评估（不用精确百分比，看"范围是否撞车"）：
- 读候选 skill 的"适用场景/边界"段，判断本次内容是否被它覆盖。
3. 三分支决策：

4. 不管哪支，顺手查冲突：扫老 skill 里有没有错误/过时信息（如失效的 CLI 命令、被证伪的数据结论）。有 → 当场用 Edit 修掉（诚实计量红线，见 §8）。本次若修了老 skill，在 changelog/清单里记一笔。

§4 蒸馏写 SKILL.md（质量归 system-to-skill，不重抄）

只给本 skill 增补的"编排动作"，正文质量请遵循 system-to-skill 的三红线：
1. 去人设化：账号/客户/机器绝对路径 → 首次配置项变量。
2. 工具栈中立：最小依赖 vs 完整版两条路。
3. 从0可复现：明说"零基础到产出要多久"+ 诚实标变量。

frontmatter 用本机验证过能过审的格式（照搬 knowledge-base-ops）：

---
name: <english-slug>
slug: <english-slug>            # 必须，kebab-case，同 name
description: <一句话，含触发词>   # 必须
version: 1.0.0                  # 必须，每次真发须 > 平台已有
updated: 'YYYY-MM-DD'
metadata:
  author: <作者名>
  platforms: [workbuddy]
  license: MIT
displayName: "<中文名>"          # 必须，驼峰
display_name_en: "<English>"
visibility: "public"
agent_created: true
---

§5 修冲突（发现老 skill 错/过时 → 当场修）

常见两类必须修：
- 失效命令：如老 skill 写 skillhub publish（本机无此命令）→ 改成 skills_store_cli.py publish。
- 被证伪的数据：如老 skill 写"覆盖率 100% 已全量"（实测跨表 hash 误比，真实仅 26.56%）→ 改成真实值 + 解释。

修完在发布清单/回复里点明"修了哪个老 skill 的什么"。

§6 真发（用真实 CLI）

CLI="C:/Users/40280/.skillhub/skills_store_cli.py"
PY="C:/Users/40280/.workbuddy/binaries/python/versions/3.13.12/python.exe"
SKILL_DIR="C:/Users/40280/.workbuddy/skills/<name>"

# ① 预检（缺 slug/displayName/version 会当场报错）
$PY $CLI publish --dry-run "$SKILL_DIR"

# ② 真发
$PY $CLI publish "$SKILL_DIR" --changelog "一句话说明本次发了什么/补了什么"
# 成功 → 返回 skillId=xxxxxx
# 版本冲突 → "版本 X 已存在"，把 frontmatter version 升一版再发

> Windows 路径用正斜杠或 C:/ 形式，避免 Git Bash 二次转义。

§7 收尾（审核状态 + 写回清单）

1. 审核状态说清：发上去后 SkillHub 自动跑 内容合规 + 漏洞扫描 + AI 安全评估，过审才公开/进搜索（正常机制，非秒可见）。发完立刻搜不到 = 审核中，不是失败。
2. 更新发布清单 D:\skillhub发布\发布清单.md：加一行 | <序号> | <中文名> | <name> | <version> | <skillId> | 🟡 审核中 | <备注> |。

§8 诚实计量红线（本流水线的根）

1. 数字来自实跑，不来自记忆：覆盖率/数量/状态结论，必须对自己跑实查（含自己旧输出、工具警告字面、对话摘要里的旧结论），不得直接当真理。
   - ⚠️ 真实案例：qmd 覆盖率曾长期误报 100%，真实仅 26.56%（1482/5580 内容块有可用向量）。根因是 documents 表(000d)与 content_vectors 表(000a)是两套不同编码 hash，旧脚本跨表硬比数值巧合接近就假收摊。唯一可信 = qmd 自己报的 need embeddings。
2. 去重必须真做：别硬发一份和老 skill 重叠的去占名额；重叠就走 B 分支做补充分量。
3. 修冲突必须真改文件：发现老 skill 错/失效，当场 Edit，不只在回复里提。
4. 第一人称只用于亲身经历：他人案例只能署名转述。

§9 避坑清单（实战）

• 坑1：本地 skillhub 命令不存在 → 真发只用 C:/Users/40280/.skillhub/skills_store_cli.py（Python）。skillhub-publish-prep 旧版写的 skillhub publish 在本机跑不通。
• 坑2：覆盖率误报 → 见 §8 红线1。任何带"覆盖率"声明的系统，必须实查不抄工具警告。
• 坑3：重叠硬发占名额 → 走 §3 去重三分支，B 分支做补充分量是正解（如 knowledge-base-ops 补 knowledge-base-starter）。
• 坑4：版本冲突 → 真发报"版本 X 已存在"就把 frontmatter version 升一版（如 1.0.0→1.0.1）。
• 坑5：dry-run 不过就别发 → 通常缺 slug/displayName/version，先补齐再发。
• 坑6：发完搜不到以为失败 → 那是审核中，过审才公开。

依赖

• 本机 Python CLI：C:/Users/40280/.skillhub/skills_store_cli.py + Python C:/Users/40280/.workbuddy/binaries/python/versions/3.13.12/python.exe
• 已登录的 SkillHub key（存在 CLI 本地 config，不进记忆/笔记）
• 上游：system-to-skill（写质量）、skillhub-publish-prep（备料参考）

最小可跑

你说"把 XX 蒸成 skill 发上去"→ §3 去重判断 → §4/§5 写+修 → §6 真发 → §7 收尾。一条命令触发整条，无需你逐步跟。

实战范例：知识库搭建蓝图文章 → skill-publish-pipeline 的种子

• 输入：一篇"回顾搭知识库过程 + WorkBuddy 可执行蓝图"文章
• 去重（§3）：发现 70% 和 knowledge-base-starter 撞车 → B 分支 → 做补充分量 knowledge-base-ops（只 Own 真实踩坑/qmd真配置/验收）。
• 修冲突（§5）：顺手把 knowledge-base-starter 里"实查后 100% 已全量"的误报改成真实 26.56%。
• 真发（§6）：skills_store_cli.py publish → skillId=169647（审核中）。
• 这正是本 skill 的来历。