Metadata

name: skill-publish-pipeline
slug: skill-publish-pipeline
description: 把一段内容/方法论「一键蒸成 SkillHub skill 并发上去」的编排层：先做去重判断（避免重复占名额）→ 决定新建 / 补充分量 / 修老 skill → 按蒸馏三红线写 SKILL.md → 用本机真实可用的 Python CLI 真发 → 写回发布清单。包含去重三分支决策表、真实 CLI 命令（非失效的 skillhub 命令）、审核状态说明、诚实计量红线。触发词：把XX蒸成skill发上去、蒸馏文章发skillhub、把这篇做成skill、内容变skill一键发、去重后发skill。
version: 1.0.0
updated: 2026-08-23
metadata: {"author":"老刘（实体老板转型+AI协作）","platforms":["workbuddy"],"license":"MIT"}
displayName: 蒸馏发布一条龙
display_name_en: Distill-to-Skill Publish Pipeline
visibility: public
agent_created: true

蒸馏发布一条龙（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，不重抄、不占重复名额。

步骤：

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

分支	判定	动作
A 纯重复	候选 skill 已覆盖本次内容 ≥80%，无新增值	不发新 skill。告诉用户"已有 X 覆盖，建议直接改进 X（升 version）"。除非用户坚持，否则不占重复名额。
B 重叠有增量	撞车 30%~80%，但本次有老 skill 完全没有的独有层	做补充分量 skill：新 skill 只 Own 那块"缺口"，重叠部分用"见 X"指向、不重抄。命名体现"补/运维/进阶"（如 `knowledge-base-ops` 补 `knowledge-base-starter`）。
C 无重叠	撞车 <30%	直接新建，按 `system-to-skill` 三红线写。

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

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

只给本 skill 增补的"编排动作"，正文质量请遵循 system-to-skill 的三红线：

去人设化：账号/客户/机器绝对路径 → 首次配置项变量。
工具栈中立：最小依赖 vs 完整版两条路。
从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 收尾（审核状态 + 写回清单）

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

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

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

§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 的来历。

Skill 发布与 GitHub 托管

安装技能