Skill 进化发布流水线

> 把一个「已在 SkillHub 上的 Skill」根据评测反馈持续优化并重新上线的可复现闭环。
> 核心信念（承袭 SOUL）：证据驱动（评测/调研都要有据可查）+ 模型能力 > 框架复杂度（提示词工作流为主，脚本为辅）。

> 🎯 使命对齐 · 习惯即命运
> 我们创建 Skill，是为了帮人形成良好的习惯、改变自身的命运（思想→言辞→行动→习惯→性格→命运）。本 Skill 虽不直接"创建" Skill，但进化这一步，目标是让 Skill 更有效地改变用户习惯与命运——每轮优化先问"是否更利于好习惯形成"。评测扣分项若涉及"用户用不起来/习惯没养成"，应优先回流优化。

🔍 速查索引（先到这找答案）

• 我是新手，只想快速跑通 → 🚀 30秒上手
• 拿到评测了，第一步做什么 → 阶段① 取回评测基线
• 不知道改什么 → 阶段② 认知放大器反思（双通道） + 评测扣分点 → 改动映射
• 发布命令怎么写 → SkillHub 发布铁律
• 发布成功但下载还是旧版 → 关键排障：扫描门控
• 某个报错怎么一步步解 → 逐错排查（逐步指引）
• 想看真实经历 → 📓 真实案例：本 Skill 发自己
• 改完怎么沉淀经验、防止悄悄落分 → 阶段⑤ 反馈收集与自改进 + FEEDBACK_LEDGER.md
• 我用 macOS / Linux → 跨平台发布命令

何时用这个 Skill

• 你有一个已发布到 SkillHub 的 Skill，拿到了 AI 评测分数，想据此优化并重发。
• 你想系统性挖掘"这个 Skill 还能更好在哪"，而不是拍脑袋改。
• 你被"发布成功了但线上下载的还是旧版"卡住，需要排障。

不适用：从零创建全新 Skill（用 skill-designer / nuwa-skill）；纯发布无优化（用 skillhub-publisher）。

如何触发（A 维度优化）：上面任一口语都能调出本 Skill；即使措辞不同，只要表达了「已发布的 Skill + 想根据评测反馈优化并重新上线」的意图（例如"我那个 skill 拿到评测了，帮我改改再发"），也能命中。也可以在 Skill 列表里手动点开本 Skill 直接运行。

🚀 30秒上手（新手路径）

给一个最小可跑通的例子，让没有技术基础的人也能照做。

场景：你有个已发布的 Skill my-skill，拿到了 AI 评测（比如 4.5 分，reviewer 说"缺示例"），想据此优化重发。

1. 先把线上版拉到本地对比（确认基线，避免改错对象）：
   bash SH="$HOME/.workbuddy/bin/skillhub" "$SH" --skip-self-upgrade install my-skill --dir /tmp/my-skill-live
2. 按评测改本地文件 ~/.workbuddy/skills/my-skill/SKILL.md（每改一条对应一个扣分点）。
3. 升版本号（x.y.z → x.y.(z+1)），然后 dry-run + 发布：
   bash PY="$HOME/AppData/Local/Microsoft/WindowsApps/python3.exe" # Windows；mac/Linux 见跨平台节 CLI="$HOME/.workbuddy/skills/.skillhub-cli/skills_store_cli.py" DIR="$HOME/.workbuddy/skills/my-skill" MSYS_NO_PATHCONV=1 "$PY" "$CLI" --skip-self-upgrade publish "$DIR" --token skh_xxx --changelog "据评测补示例"
4. 发布后回拉验证；若下载仍是旧版 → 那是安全扫描门控，升一个补丁版本重传即可（详见关键排障）。

> 新手三条保命提示：① slug 必须和线上一致（否则会新建而非更新）；② 改完一定升版本号；③ Token 只进变量、绝不回显到对话里。

四阶段闭环

① 取回评测基线  →  ② 认知放大器反思（双通道：向内+向外望方向）  →  ③ GitHub 定向借鉴循环  →  ④ 优化重写 → 发布（含扫描门控）  →  ⑤ 反馈收集与自改进
     (证据)        (向内看 + 向外望方向)       (向外借借鉴)           (落地 + 上线验证)              (经验复利 · 自改进)
                                                                        │                                        │
                                                              回流 ▼ 更新两块看板                           ▼ 回评测 → collect_feedback.py
                                            REQUIREMENTS.md（需求）+ SOLUTIONS.md（方案）      FEEDBACK_LEDGER.md（改动→影响配方表，回流 ②/③）

> 看板是这条流水线的持久记忆。每个 skill 目录下应有 REQUIREMENTS.md（需求看板）和 SOLUTIONS.md（实现方案看板）——
> 由 skill-builder 创建时用模板打底，本流水线每轮进化都往里沉淀。若目标 skill 还没有这两块看板，
> 先从 ~/.workbuddy/skills/skill-builder/assets/ 复制模板补上，再开始进化。
>
> #### 自进化的三来源框架（守 / 借 / 望）
>
> 本流水线的进化动力来自三个互补来源，本质对应「守规范、借经验、望方向」：
>
> | 来源 | 本质 | 证据入口 | 现状 |
> |---|---|---|---|
> | ① 评测结果找自身弱点 | 守（规范底线） | 阶段①基线 + 阶段②向内反思 + 阶段⑤台账 | ✅ 已步入正轨 |
> | ② GitHub 同类产品借鉴 | 借（横向扩展） | 阶段③ 定向借鉴循环 | 🟡 在流程中 |
> | ③ OSINT+认知放大器找方向/泛化 | 望（向上突破） | 阶段②·Stream D（向外望方向） | 🔴 本期新增 |
>
> ①是「守」、②是「借」、③是「望」——三者缺一不可。来源③与②的区别：②=同行抄作业（同域横向，借具体实现）；③=跨域借范式 + 认知放大器验真伪 + 泛化落地（异域纵向，找「可迁移的元范式」）。
>
> 四个需求/方向源正好对应本流水线的证据入口：
> Stream A=用户本轮诉求，Stream B=阶段①评测扣分点 + 阶段③ GitHub 借鉴点，Stream C=conversation-miner 挖出的隐性需求，Stream D（方向源，来源③）= OSINT 外部信号 + 认知放大器泛化提炼的「可迁移范式 / 新需求 / 新实现方式」。

阶段① 取回评测基线（证据锚点）

目标：拿到「线上当前版本 = 本地版本?」「AI 评分」「安全报告」「slug/ownerId」作为优化的证据锚点。

1. 定位 SkillHub CLI 与本机 skillhub 命令：
   - CLI 脚本：~/.workbuddy/skills/.skillhub-cli/skills_store_cli.py
   - 便捷命令：~/.workbuddy/bin/skillhub
2. 确认真实 slug（用户给的展示名 ≠ slug）。用 skillhub search <关键词> 或直接用已知 slug 拉线上版对比：
   bash SH="$HOME/.workbuddy/bin/skillhub" "$SH" --skip-self-upgrade install <slug> --dir /tmp/sh_live # 拉线上版
3. 对比线上版与本地版（SKILL.md / scripts / _meta.json），确认基线是否一致。
4. 记录基线：AI 评分、安全报告结论、slug、ownerId、下载数。这些是"证据驱动优化"的起点。

> ⚠️ 若 SkillHub 页面直链 404，用 CLI install <slug> 才是可靠取回线上真实内容的方式（网页是 JS 渲染，工具抓不到；评测详情在个人中心，需作者从浏览器复制）。

阶段② 认知放大器反思（双通道）

本阶段是「自进化三来源」的反思中枢：Stream A/B/C 向内看（评测弱点、用户诉求、隐性需求，对应来源①守 + 来源②借的需求侧），Stream D 向外望方向（OSINT 信号 + 认知放大器泛化，对应来源③望）。两通道共用认知放大器、方向相反——一个收敛于「修己」、一个发散于「望野」。

调用 cognitive-amplifier（证据驱动模式），对目标 Skill 做结构化反思。固定追问四个问题：

1. 单对象漏挖：这个 Skill 当前只处理了哪部分价值？还有哪些价值没被捕获？（例：只看"文件产出"，漏了"纯对话表达的决策/知识"）
2. 视觉盲区（Negative space）：它只统计"成功/有产出"，是否忽略了"卡住/失败/未满足"？
3. 可自动化：哪些人工触发的步骤可以变成 automation（每日/每周定时）？
4. 被忽视需求 & 更好实现：用户真正想要但没被满足的是什么？现有实现有没有更优路径？

产出：一份独立反思文档（<workspace>/<skill>-vN-reflection.md），带 Seal 分级与置信度。这是交付物之一。

阶段②·摄入 Stream C（conversation-miner recurring 未满足需求）

> 对应跨 Skill 整合缺口③。阶段② 不能只"向内看"评测与自省——必须常态化把 conversation-miner 的隐性需求作为第 4 个需求源摄入，否则 Skill 永远只追评测、追不上用户没说出口的期待。

固定工序（每轮必做；不跑 miner 的轮次视为证据不全）：

1. 取 miner 最新输出：若本次会话已跑过 miner（用户说"挖掘对话看看新发现"），直接读其 transcripts/；否则跑一次（近 21 天）：
   bash PY="$HOME/.workbuddy/binaries/python/versions/3.13.12/python.exe" MINER="$HOME/.workbuddy/skills/workbuddy-conversation-miner/scripts/mine_conversations.py" OUT="$HOME/.workbuddy/skills/.miner-latest" "$PY" "$MINER" "$(date -d '21 days ago' +%Y-%m-%d)" "$(date +%Y-%m-%d)" --out "$OUT" --json
2. 提炼 recurring 未满足需求：优先消费 _RECURRING.json（类型化结构化清单，每条带 id/text/frequency/source_sessions/recency_weight/vfm_hint，可直接并入 VFM，省掉 AI 二次提炼）；若缺席则回退从 _DIGEST.json 的 themes（session_count 高者优先）+ 各 conversations.first_query 中反复出现、但目标 Skill 尚未覆盖的意图提炼。每条带来源会话 tag + 频次信号（例：flow 应自动衔接发布 | 07-07/07-09/本会话 | 跨会话≥4）。
3. 合并去重入 VFM：把 Stream C 清单与阶段②四个追问的结论、阶段①评测扣分点合并，统一进 VFM 评分（频率维度用 miner 频次信号加权）。优先级 ≥60 才值得改。
4. 闭环落点：这些 Stream C 需求在阶段④回流时写入目标 Skill 的 REQUIREMENTS.md Stream C 列（状态 💡/🟡），并追加变更日志——这就是缺口③的落点。

> 原则：miner 是与 A（用户诉求）、B（评测+GitHub）并列的第 4 需求源。目标 Skill 是全新的、无历史对话可挖时，可跳过本工序并说明理由。

阶段②·摄入 Stream D（OSINT+认知放大器找方向/泛化）

> 对应三来源框架的来源③（望方向）。阶段② 不能只会「修己」（向内看评测/自省/隐性需求）——必须常态化把外部信号作为「方向源」摄入：用 OSINT 扫外部有没有新的「可迁移范式 / 新需求 / 新实现方式」，用认知放大器辨真伪（不被 hype 带着走），再判定能否泛化到本 Skill。

方向信号采集（轻量约定，不写死自动化）：

1. OSINT 采信号：调用 osint-tracker，围绕目标 Skill 所属领域定向扫一轮外部信号，重点看四类：
   - 跨域可迁移范式：别的领域（软件工程 / 行为科学 / 产品方法论 / Agent 框架）的成功机制能否迁移（例：CI/CD→评测闭环、可证伪性→出口闸门、组织记忆→自进化台账）。
   - 竞品 / 同类新动态：SkillHub、GitHub、相关产品的新功能 / 新交互范式。
   - 用户真实痛点：目标领域相关的 issue / HN / Reddit / 论文里「反复出现但未解决」的诉求。
   - 学术 / 行业新结论：可能推翻现有假设或打开新实现路径的研究。
2. 认知放大器验真伪 + 提炼：对每条信号跑认知放大器（证据驱动模式）——辨 hype、分离事实与主张、给置信度。只保留 🥇/🥈 级且可迁移的信号，伪科学 / 未证实 / 纯营销直接淘汰。
3. 判定泛化：逐条问「这能泛化到本 Skill 吗？」——能迁移 → 写 SOLUTIONS.md 或 BORROW_INDEX.md（同阶段③的复利沉淀）；仅启发但不适用 → 记 REQUIREMENTS.md Stream D 列（状态 💡），下一轮再评估。
4. 闭环落点：采纳的跨域范式在阶段④回流时写入 SOLUTIONS.md；高频可复用范式沉淀进 BORROW_INDEX.md（与阶段③共用索引，统一复利）。

> 原则：Stream D 是与 A/B/C 并列的第 4 证据源，但性质是「方向源」而非「需求源」——它回答「这个 Skill 该往哪演化」，而非「用户现在要什么」。目标 Skill 全新、无外部信号可采时，可跳过本工序并说明理由。

评测扣分点 → 改动映射

把"评测里每个扣分点"直接对应到一次具体改动，保证优化可追溯（本 Skill 的 v1.1.0 就是这么来的）：

阶段③·定向借鉴循环（向外看，VFM 驱动）

> 对应跨 Skill 整合缺口④。阶段③ 不能"泛泛找高星项目"——必须由阶段②合并后的 VFM 排序需求驱动，对每个值得改的需求定向找"谁已经解决了这个问题"，把调研从"找灵感"升级为"借解法"。并沉淀「借鉴定向索引」做复利，避免每轮重搜。

固定工序（每轮必做；无 VFM 输入则视为证据不全）：

1. 取 VFM 排序需求：从阶段②合并后的 VFM 清单里，筛出 VFM ≥ 60 的需求/盲区（值得改的）。低于阈值不浪费搜索。
2. 抽「借用查询」：给每条需求提炼一个聚焦具体解法的查询（不是泛主题）。例：
   | 需求（VFM） | 借用查询 |
   |---|---|
   | 发布后下载包仍是旧版（88） | post-publish download verification / 回拉校验 |
   | miner 应直出 recurring 清单（70） | recurring need extraction from chat transcripts |
   | 建后 GitHub 对照成标准环节（84） | auto cross-check against sibling skills after build |
3. 双源扫描（先本地、后 GitHub）：
   - a. 本地兄弟 skill 扫描（免费、最相关）：在本机 ~/.workbuddy/skills/ 下找谁已经解决了该问题，直接读命中 SKILL.md/scripts 抽片段：
   bash SK="$HOME/.workbuddy/skills" # 例：查谁已经做了"发布后回拉校验" grep -rli "回拉验证\|下载包仍是旧版\|install.*--dir" "$SK" --include=SKILL.md 2>/dev/null | head
   - b. GitHub 定向搜索（本地无解时）：用 gh search repos 或 WebSearch 跑借用查询，找 3–6 个高星项目；让子代理返回 <700 字 brief（名称 + repo + 约 star 数 + 做什么 + 1–2 个可借鉴技术点）。子代理搜索不进主上下文，省 token。
4. 借鉴定向索引（复利）：先查 ~/.workbuddy/skills/skill-evolve-pipeline/BORROW_INDEX.md——若该借用查询已记录最佳模式，直接复用、跳过搜索；否则搜索后把「查询 → 最佳模式 → 来源」写回索引。索引随 skill 发布（自包含），兄弟 skill 大改时刷新。
5. 借鉴 → 改动映射：每条 VFM ≥ 60 的需求产出一条「借鉴候选」= 来源（兄弟 skill / GitHub repo）+ 具体模式/片段 + 对目标 skill 的提议改动。这就是阶段④ 重写的输入。
6. 闭环落点：借鉴候选在阶段④ 回流时写入目标 skill 的 REQUIREMENTS.md（Stream B，状态 💡/🟡）；采纳的写 SOLUTIONS.md；跨 skill 通用的模式沉淀进 BORROW_INDEX.md。

> 原则：GitHub 调研从"泛找灵感"升级为"按需借解法"，价值排序由 VFM 决定，不做无谓搜索。flow 的「建后 GitHub 对照」也复用本循环（见缺口④）。

阶段④ 优化重写 + 发布（落地 + 上线）

优化：综合 ①②③，重写 SKILL.md / 脚本 / 参考文档。原则：

• 每个改动对应一个「盲区」或「评测扣分点」，可追溯。
• 脚本尽量 stdlib，重依赖（如 sentence-transformers）做优雅降级。
• 改完用受管 Python 编译 + 无副作用子命令实测：
  bash PY="$HOME/.workbuddy/binaries/python/versions/3.13.12/python.exe" "$PY" -m py_compile <script.py> && echo COMPILE_OK

> 为什么用受管 Python 编译、用另一个 Python 发布？ 受管 Python 3.13 缺 requests，而 SkillHub CLI 发布需要 requests。所以：编译/测试用受管版（干净隔离），发布用带 requests 的 python3（Windows 上通常是 Windows Store 的 python3）。详见依赖与环境。

回流看板（发布前必做，是"循环改善"的落点）：把本轮的证据沉淀进目标 skill 的两块看板——

• REQUIREMENTS.md：
• 阶段①评测每个扣分点 → Stream B 需求入总表；已由本轮修复的把状态改 ✅/🟡。
• 阶段③ 定向借鉴候选里"值得做但本轮没做的" → Stream B 需求，状态 🔲。
• 若跑了 conversation-miner，把挖出的隐性需求写成 Stream C，状态 💡。
• SkillHub 平台方案（评分/评论/变现等我方未接入的）→ 🔶 区。
• 追加看板变更日志一行（日期/版本/变更/来源）。
• SOLUTIONS.md：
• 本轮落地的改动 → 更新对应方案状态与实现版本、验证证据。
• 关键选型补一条 ADR（含置信度）；被替换的旧做法进 ⚰️ 墓地。

> 两块看板只增改、不重写历史，变更日志 append-only。看板随 skill 目录一起发布，安装即自包含。

发布：见下方「SkillHub 发布铁律」。

> 为什么 dry-run 用假 token？ dry-run 不发任何网络请求、只校验本地 frontmatter/文件结构，所以任意 --token skh_dryrun 即可，不会真的发布。

阶段⑤ 反馈收集与自改进（经验复利 · 自改进闭环）

> 为什么必须有这一环？ 2026-07-18 盘点本机 37 个评测快照，发现一个扎心事实：我们「根据评测改了很多次 skill」，但绝大多数只留了单轮 latest、没有 before/after 配对，无法证明改动有效；而少数留存多轮的反而评分回落（cognitive-frontier C−0.42/R−0.27、loop-engineering R−0.74/C−0.64、health-records-guardian R−0.4）——「凭感觉改、无台账」可能悄悄把分改低了都没发现。
>
> 阶段⑤ 就是把这个漏洞堵上：每轮重发后强制回评测、自动算 delta、标红回落、沉淀成可归因的「改动→影响」配方表。每轮证据都让配方表更准 → 流水线自我改进。

核心工件（自包含，随 skill 发布）

固定工序（每轮必做，是「自改进」的落点）

1. 发布后回取新评测（同阶段①的 API/CLI 方式），存为 <slug>_eval_after.json，并保留上一轮 <slug>_eval_before.json。
2. 跑收集脚本，按要求用受控词表给改动打标（便于跨轮归因）：
   bash PY="$HOME/.workbuddy/binaries/python/versions/3.13.12/python.exe" SCRIPT="$HOME/.workbuddy/skills/skill-evolve-pipeline/scripts/collect_feedback.py" MSYS_NO_PATHCONV=1 "$PY" "$SCRIPT" --collect \ --slug <slug> --old <before_eval.json> --new <after_eval.json> \ --changes "FAQ章节:补6问FAQ;IO契约:加输入输出契约" \ --date 2026-07-18 --evidence 🥇 # 期望：✓ 已收集 <slug>：delta = T+0.0 R+0.3 A+0.0 C+1.0 E+0.2 # 若某维 < -0.1 → ⚠ 回落警告，强制复盘
   - 改动打标词表（用哪个写哪个，分号分隔 type:detail）：FAQ章节 / 稳定性兜底 / IO契约 / 能力边界 / 真实案例 / 新手路径 / auto_retry / 出口闸门 / 滑块声明 / 引用修正。
   - 不打标也能存（delta 照算），但只有打标 + 有前后配对的记录才会进入「改动→影响」配方表——所以打标是自我改进的关键投喂。
3. 看配方表决定下一轮优先级：FEEDBACK_LEDGER.md 第二节会自动聚合「哪类改动 → 哪维升降」（按样本数 n + 证据给置信度）。下一轮阶段②改造映射时，优先套用高置信配方（预期提分最高、最省力），低置信的当作「待验证假设」。
4. 回落必复盘：任何维度 delta < −0.1 标红，回到阶段②用出口闸门两问（会不会误导 / 何时失效）自检本轮改动。

> 自改进的本质：feedback_store.json 是滚雪球的事实底座，collect_feedback.py 是自动化的手。改得越多、打标越全，配方表越准，下一轮「该改什么」越不需要拍脑袋——这就是流水线的自我进化。

SkillHub 发布铁律（含扫描门控排障）

> 这些是真实踩坑总结，务必逐条遵守。

发布前

1. slug 必须锁定原值 —— frontmatter 的 slug 和 _meta.json 的 slug 都要等于线上已有 slug，否则会新建一个 listing 而非更新。
2. 双写 slug：SKILL.md frontmatter（name/slug/displayName/version/summary/license）+ 同目录 _meta.json（ownerId/slug/version）。CLI 从 frontmatter 读元数据，_meta.json 兜底带 slug/ownerId。
3. 版本号必须比线上高（语义化 x.y.z）。同 slug 下重复版本号会被平台去重拒绝（报 slug 冲突: 版本 x.y.z 已存在）。
4. dry-run 本地校验（不发请求，任意假 token 即可）：
   bash PY="$HOME/AppData/Local/Microsoft/WindowsApps/python3.exe" # 需带 requests 的 python CLI="$HOME/.workbuddy/skills/.skillhub-cli/skills_store_cli.py" DIR="$HOME/.workbuddy/skills/<skill>" MSYS_NO_PATHCONV=1 "$PY" "$CLI" --skip-self-upgrade publish "$DIR" --token skh_dryrun --dry-run # 期望：✓ Dry-run passed: <slug>@<version>
   - MSYS_NO_PATHCONV=1 必需（Git Bash 会把参数里的 Windows 路径乱转义）。
   - 受管 Python 3.13 常缺 requests；Windows Store 的 python3 通常自带，用它跑 CLI。

真实发布（含 auto-retry）

TOK="skh_xxx"   # 用户提供，或本机 "$SH" --skip-self-upgrade auth token 读取（只读、不回显）
publish_with_retry() {
  local n=0
  until MSYS_NO_PATHCONV=1 "$PY" "$CLI" --skip-self-upgrade publish "$DIR" --token "$TOK" --changelog "$1"; do
    n=$((n+1)); [ $n -ge 3 ] && { echo "发布失败超过3次，请检查网络/Token"; return 1; }
    echo "第 $n 次发布失败，$((n*3))秒后重试..."; sleep $((n*3))
  done
}
publish_with_retry "据评测优化：补示例+跨平台+自动重试"
# 期望：✓ Published: skillId=<id>  RC=0

> 为什么加 auto-retry？ 评测指出原版"缺少自动重试功能，遇到网络波动或临时失败可能需要手动重跑"。上面这个 shell 函数最多重试 3 次、退避时间递增（3s→6s→9s），覆盖临时网络抖动，不用你守着重跑。

⚠️ 关键排障：发布成功但下载包仍是旧版

现象：publish 返回 ✓ Published RC=0，但用 install <slug> 回拉的 zip 内容还是旧版（frontmatter 缺失、新特性标记为 0）。

根因：RC=0 只代表版本元数据注册成功，下载包要过安全扫描门控后才会替换。扫描期内下载到的是上一版内容。

判定：回拉后 grep 新版本独有关键词，计数为 0 → 内容未生效。

"$SH" --skip-self-upgrade install <slug> --dir /tmp/vl >/dev/null 2>&1
grep -c "<新版独有关键词>" /tmp/vl/<slug>/SKILL.md   # 0 = 还是旧版

解法：
- 若只是等扫描：过一段时间重拉即可，无需操作。
- 若急需内容上线、或怀疑卡死：升一个补丁版本号（x.y.z → x.y.(z+1)）强制一次全新内容上传，重新触发扫描。切勿重发同版本号（会被去重拒绝）。

跨平台（macOS / Linux）发布命令

Windows 教程里两处平台相关，跨平台时这样改：

1. MSYS_NO_PATHCONV=1 前缀 —— 仅 Git Bash on Windows 需要；macOS/Linux 的终端 / Zsh / Bash 直接去掉。
2. 带 requests 的 Python —— Windows 用 Windows Store python3；macOS/Linux 用系统 python3（通常自带，没有就 python3 -m pip install requests）。

跨平台等价发布命令（macOS / Linux）：

PY="python3"   # 需 import requests 成功
CLI="$HOME/.workbuddy/skills/.skillhub-cli/skills_store_cli.py"
DIR="$HOME/.workbuddy/skills/my-skill"
"$PY" "$CLI" --skip-self-upgrade publish "$DIR" --token "$TOK" --changelog "据评测优化"

> 路径说明：macOS/Linux 上 ~/.workbuddy 路径与小写 $HOME 一致；Windows 上 $HOME 在 Git Bash 里即 /c/Users/<你>，与本文档其余示例一致。

发布后

• 回拉线上版验证版本号与新特性关键词。
• 安全扫描通过后，回个人中心取回新评测分数，与旧基线对比 → 进入阶段⑤ 反馈收集与自改进：跑 collect_feedback.py --collect 录入，形成"评测 → 优化 → 再评测 → 经验沉淀"的自改进闭环。

一次完整跑通的检查清单

• [ ] ① 用 CLI install <slug> 拉线上版，记录 AI评分/安全结论/slug/ownerId 基线
• [ ] ② cognitive-amplifier 反思，产出反思文档（四问 + Seal 分级）
• [ ] ②b 把评测每个扣分点映射到一条具体改动（见映射表）
• [ ] ②c 跑/读 conversation-miner，把 recurring 未满足需求作为 Stream C 并入 VFM（见阶段②·Stream C）
• [ ] ②d 按需用 osint-tracker 采外部信号 + cognitive-amplifier 验真伪，把可迁移范式/新方向作为 Stream D 摄入（见上方「阶段②·摄入 Stream D」）
• [ ] ③ 阶段②·Stream C 已合并 VFM；对 VFM≥60 的需求抽借用查询 → 本地兄弟 skill 扫描 + GitHub 定向搜索 → 产出借鉴候选 → 查/写 BORROW_INDEX（见阶段③·定向借鉴循环）
• [ ] ④ 重写 SKILL.md/脚本/文档，每改动对应一个盲区/扣分点
• [ ] ④ 回流看板：REQUIREMENTS.md（三流增改+日志）+ SOLUTIONS.md（方案状态+ADR+墓地）
• [ ] ④ 脚本 py_compile 通过 + 无副作用子命令实测不崩
• [ ] 发布前：frontmatter + _meta.json 双写、slug 锁定、版本号+1
• [ ] dry-run 通过（✓ Dry-run passed）
• [ ] 真实发布 ✓ Published RC=0（建议用 auto-retry 包裹）
• [ ] 回拉验证；若仍旧版 → 判定为扫描门控 → 需要时升补丁版本重传
• [ ] ⑤ 回取新评测 → collect_feedback.py --collect 打标录入（强制，不可省）：自动算 delta、标红回落、刷新 FEEDBACK_LEDGER.md 配方表
• [ ] ⑤ 若某维 delta < −0.1 → 回落复盘（出口闸门两问自检）
• [ ] 写工作日志记忆

依赖与环境（Windows / Git Bash）

• SkillHub CLI：~/.workbuddy/skills/.skillhub-cli/skills_store_cli.py（真身）；~/.workbuddy/bin/skillhub（便捷命令）
• 跑 CLI 用带 requests 的 Python（Windows Store python3；mac/Linux 见跨平台节）；py_compile/脚本测试用受管 Python 3.13。
• 所有 CLI 调用在 Windows Git Bash 下前置 MSYS_NO_PATHCONV=1。

📓 真实案例：本 Skill 发自己

2026-07-10，本 Skill 用它自己描述的流程把自己发布到 SkillHub，完整复现了文档里的每一条铁律（也是 v1.1.0 评测优化前的基线经历）：

1. 用 skillhub search skill-evolve-pipeline 确认 slug 无冲突；检查 frontmatter + 补 _meta.json 双写。
2. dry-run 通过：✓ Dry-run passed: skill-evolve-pipeline@1.0.0。
3. 用 Token 真实发布：✓ Published: skillId=97348 RC=0。
4. 回拉验证触发扫描门控：install 拉到的 zip 为空（下载包卡安全扫描），正是文档「关键排障」预言的现象。
5. 按自己写的排障法收尾：升补丁版本 1.0.0 → 1.0.1 强制重传，重新发布同一 skillId=97348；扫描通过后 install 即返回完整 v1 内容。

> 这段经历证明：文档描述的流程自洽可用，从取 slug、双写、dry-run 到扫描门控排障全部命中。它现在既是方法论文档、也是已验证可运行的工具。后续任何 Skill 的评测驱动进化都能直接复用这条流水线。

逐错排查（逐步指引）

把"常见错误"升级为一步步操作（评测指出原表"答案笼统、不够一步一步教我操作"）：

错误 A：slug 冲突: 版本 x.y.z 已存在
1. 含义：你重发了和线上相同的版本号，被平台去重拒绝。
2. 解决：把 _meta.json 和 SKILL.md frontmatter 的 version 都升一号（如 1.0.1 → 1.0.2）。
3. 重新执行发布命令；成功应返回 ✓ Published skillId=<同一id>（更新而非新建）。

错误 B：发布成功（RC=0）但 install 拉到的还是旧版/空
1. 先确认：回拉后 grep -c "<新版独有关键词>" SKILL.md 计数为 0 → 内容未生效。
2. 这是安全扫描门控，不是失败。先等几分钟重拉；若急需 → 升一个补丁版本强制重传（见关键排障）。
3. 切勿用同版本号重发（会触发错误 A）。

错误 C：dry-run / 发布报路径错乱（如 C:\Users\... 被改成乱码）
1. 原因：Git Bash 自动把参数里的 Windows 路径做了 POSIX 转义。
2. 解决：在所有 CLI 调用前加 MSYS_NO_PATHCONV=1 前缀（macOS/Linux 不需要）。

错误 D：ModuleNotFoundError: No module named 'requests'
1. 原因：用来跑 CLI 的 Python 没装 requests。
2. Windows：改用 Windows Store 的 python3（$HOME/AppData/Local/Microsoft/WindowsApps/python3.exe），通常自带。
3. macOS/Linux：python3 -m pip install requests 后重试。

错误 E：发布后变成一个全新的 listing（不是更新）
1. 原因：frontmatter 或 _meta.json 里的 slug 没和线上一致，平台当成新 skill。
2. 解决：两个文件的 slug 都改回线上已有 slug，重新发布。

常见错误（速查表）

v1.6.0 — 2026-07-18 | 据用户提出「自进化三来源框架（守/借/望）」升级阶段②为双通道反思：显式三来源表（评测弱点/GitHub借鉴/OSINT+认知放大器找方向泛化），新增 Stream D（向外望方向——osint-tracker 采信号 + cognitive-amplifier 验真伪 + 泛化判定，轻量约定不写死自动化），与 Stream A/B/C 并列第4证据源；BORROW_INDEX 与阶段③共用复利。文档级改动，未动脚本。

_v1.5.1 — 2026-07-18 | bugfix 补丁版（带修复重发）：collect_feedback.py 智能补全占位记录（--collect 对同 slug 不再重复追加）、台账字段修正（单轮基线评测值归位 eval_before）；FEEDBACK_LEDGER.md 已用 reverse-inference 真实 before/after 配对（R+1.0/A+0.6，E−0.12 回落标红）与 skill-evolve-pipeline 当前基线（4.65）双验证，闭环已跑通。

v1.5.0 — 2026-07-18 | 新增阶段⑤ 反馈收集与自改进（自改进闭环）：新增 scripts/collect_feedback.py（自动算 delta、标红回落）+ feedback_store.json（事实底座）+ FEEDBACK_LEDGER.md（经验台账+改动→影响配方表聚合）。种子语料来自本机 37 个真实评测快照，如实记录多轮回落案例（cognitive-frontier/loop-engineering/health-records-guardian），把"评测驱动"从凭感觉变成有台账、可归因、会标红回落的证据闭环。四阶段闭环升级为五阶段。

v1.4.0 — 2026-07-10 | 阶段③升级为 VFM 驱动的「定向借鉴循环」（本地兄弟 skill 扫描+GitHub 定向搜+BORROW_INDEX 复利），缺口④闭合；据 SkillHub TRACE 评测（综合 4.5/优秀）优化：补新手路径+速查索引+真实案例+auto-retry+跨平台+逐步排障