name: omni-skill-forge

agent_created: true

description: |
万象-技能打包与库治理 —— 技能库与技能资产的全生命周期工程（治理 + 铸造 + 融合）。
什么时候用：要盘点或分类技能库、批量改名与补字段、给技能盖章与验指纹、做加密发布包（.skillex）、
评审位次与融合进化、把技能上架到开放平台、卸载外来技能包做净室转生时使用。
不适用于：从零创造技能内容（走 skill-creator）；把应用发布到线上（走「发布为应用」）；核查工程建设标准现行性（走万象-工程建设标准核查）。
triggers:

• "整理技能库"

• "技能库复盘"

• "技能库体检"

• "技能分类"

• "技能合并"

• "技能归档"

• "技能改名"

• "技能改成中文名"

• "技能字段体检"

• "frontmatter 体检"

• "给技能补触发词"

• "triggers 字段"

• "技能列表太乱"

• "技能元数据"

• "技能膨胀"

• "把这个经验沉淀成技能"

• "displayName 还是 display_name"

• "技能 naming 规范检查"

• "技能元数据规范"

• "技能版权"

• "版权声明"

• "著作权"

• "防抄袭"

• "加密发布包"

• "skillex"

• "指纹校验"

• "隐形水印"

• "净室重写"

• "净室转生"

• "转生"

• "卸载外来技能"

• "归档技能"

• "技能分两类"

• "自研与外来的区分"

• "资产台账"

• "冒名检测"

• "技能等级"

• "技能成长"

• "技能评分"

• "技能淘汰"

• "技能太多"

• "技能库治理"

• "熟练度"

• "经验值"

• "技能进阶"

• "境界"

• "位次"

• "匠作九位"

• "九级三阶"

• "段位"

• "融合进化"

• "血脉"

• "位内三候"

• "等级怎么算"

• "回执导入"

• "改进心得"

• "第三方技能包安全吗"

• "装上这个技能"

• "安装技能包"

• "升级技能版本"

• "移除旧版技能"

• "卸载技能"

• "给技能找茬"

• "技能包审查"

• "挑毛病"

• "技能内容有问题"

• "SKILL.md 前后矛盾"

• "这份技能靠谱吗"

• "技能融合"

• "万象融合"

• "继续融合"

• "接着合"

• "合并成一个技能"

• "取精华去糟粕"

• "精简技能库"

• "覆盖度销账"

• "coverage"

• "销账表"

• "技能迁移"

• "融合后遗漏"

tags: [skill-management, naming-convention, metadata, frontmatter, lifecycle, curation, copyright, provenance, encryption, watermark, clean-room, growth, merge, evolution, third-party-audit, install, coverage, dedup]

version: "4.1.0"
changelog: "4.0.0 · §A0-pub2（SkillHub 浏览器向导自动上线）自 3.2.0 起阶段性并入，今整体迁出、独立为「万象-SkillHub自动上架」（omni-skh-auto-publish）：脚本、两篇 references、7 条上线触发词全部随迁；本节只保留一行指路，开放平台通道（§A0-pub）不受影响。"

display_name: "万象-技能打包与库治理（L1 审曲）"
display_name_en: "Wanxiang Skill Forge"
description_zh: "把零散技能管成一座库：盘清家底、补齐字段、合并同类、留好版权凭据，再送上一个或多个发布平台。"
description_en: "Engineer a skill library: governance, level evaluation, fusion, copyright stamping, encrypted release packs, and publishing to the WorkBuddy Open Platform."
category: "development"
author: "zzzzzzzp"
copyright:
holder: "zzzzzzzp"
year: 2026
license: "All Rights Reserved"
notice: "本技能为 zzzzzzzp 原创作品，著作权归其所有，保留一切权利。未经书面许可，不得复制、改编、再发布或用于训练数据。"
fingerprint: "sha256:436be2f27acdfc357a7704d2cdfa77c17ef0062896b513d5d0eed309576825ae"
watermark: false
mark_id: "AG1-04e6316e19"
stamped_at: "2026-10-07T17:28:55+0800"

万象-技能铸造

§〇 · 本技能定位为付费技能（Pay Skill）

> 🔴 付费技能一律走完整付费路径 —— 是付费定位，就照着付费通道做完：
> 随包实现 402 链路（见 §〇·2）、接入相应服务、按注册价填单价、走 Pay Skill 向导。
> 不回头讨论「要不要改成免费」。若确实要转免费，改的是 万象标识体系/tools/gen_icons.py 的
> PAY_SKILLS 名单与本段声明（显式改动），不是偷偷少做一步。

§〇·2 · 随包提供的 402 付费链路实现（平台「付费改造」检测就看这个）

🔴 实测判据（平台原话）：SkillHub 在提交时会做一次「支付宝付费改造」检测，
判据是技能包内是否存在 402 支付链路的实现，缺失项会被逐条列出：

> 「缺失项：402账单下发 / 携带凭证重试 / 验付调用 / 履约确认 / 订单持久化与幂等」
> 「该检查不阻断提交。提交后平台审核仍会重新做一次完整检测，若不合规将被拒绝。」

⇒ 本包自带该实现（目录 a2m/，零密钥、可直接 npm install && npm start）：

配置边界（有意为之，勿改成「能跑就行」）：配置缺失即明确失败（资源路由返回 503），
不构造 SDK、不使用占位密钥、不提供任何跳过验付的路径。密钥只走运行环境变量或本地配置文件，永不入包。

cd a2m && npm install && npm run smoke   # 冒烟：账单结构 / RSA2 签名 / 幂等边界
npm start                                # 默认 http://localhost:3000/demo/a2m/resource

一句话：一座技能库的全生命周期——盘货（库里有哪些、叫什么、字段对不对）、处置单件（这一件属于谁、练到几品、能不能发出去）、把多部并成一部——三件事合在一部里，因为它们共用同一套位次体系、同一批脚本、同一本归档台账。

三条主线，各自独立又互相接壤：

| 篇 | 回答 | 工作对象 | 章节 |

|---|---|---|---|

| A 治理 | 库里有哪些、该进该退、叫什么、字段对不对 | 集合 | A 篇 §A1–§A12 |

| B 铸造 | 这一件属于谁、练到几品、能不能发出去 | 单个资产 | B 篇 §B1–§B16 |

| C 融合 | 多部同源技能怎么并成一部而不漏内容 | 一组资产 | C 篇 §C0–§C7 |

> 为什么是三篇而不是三部技能。 这三件事共用同一批可执行资产（scripts/ 下的 growth.py、assetguard.py 是 A 与 B 的共同底座；scripts_merge/ 下的 fusion_coverage.py 又是 B 篇「融合即进化」与 C 篇全篇的共同底座），共用同一本台账（scripts_merge/fusion_ops.py 写的 _ARCHIVE_LEDGER.jsonl 正是 A 篇 §A1 铁律 1 所说的「归档区」），且互调对方的判据（C 篇选宿主必须先跑 B 篇的 growth.py domains；A 篇改名后必须跑 B 篇的 assetguard.py stamp）。

>

> 这与 C 篇 §C2.1「一组出几部」不矛盾。 那一节给的判据是职责动词——同一组内若出现两个互不相干的「铁律」章节就该拆。本技能「三篇」的拆法正是按该判据落地的：篇界即判据边界，同一篇内只有一套铁律，跨篇的互指已全部改写为篇内引用。

>

> 未采用「三部独立技能」方案的理由：三部之间是上下游关系而非并列关系（A 改名 → B 盖章 → C 融合 → 回到 A 登记台账），拆开后每一步都要在另一部的语境里重新解释一遍职责，且 scripts/ 与 scripts_merge/ 将被复制三份——那才是 C 篇 §C2.1 所警告的"硬拆的代价"。

篇内小节编号：B 篇保留原 §B1…§B16 编号（其正文内部互引未改，保证逐字可回溯）；A 篇与 C 篇的小节现已冠以 §A / §C 前缀，避免三篇之间编号撞车。

B 篇 · 铸造（处置单件）：属于谁、练到几品、能不能发出去

B 篇 · 铸造（处置单件）

本篇管单个资产——它练到几品、属于谁、能不能加密发出去、外来的东西进不进得了门。货架本身的事（库里有哪些、叫什么、字段对不对）在 A 篇 · 治理。

三条主线，各自独立又互相接壤：

| 主线 | 回答 | 章节 |

|---|---|---|

| 位次 | 它练到几品了，能不能再进一步 | §B1–§B4 |

| 权属 | 它是谁的，被人搬走怎么办，怎么发得出去 | §B5–§B9 |

| 外来 | 别人的包进来之前怎么看，用熟了怎么转成自己的 | §B10–§B12 |

为什么值得沉淀：复利工程（上位理念 · 2026-09-21 立）

> 来源：视频号博主「晓辉博士」《复利工程》（2026-09-20，正片 3 分 36 秒）。

> 逐条要点与反思见 omni-wechat-fetch/references/视频卡学习台账.md §137。

一句话：拉开「普通人用 AI」与「超级个体用 AI」差距的，是 复利工程——

一次与 AI 协作的经验能不能沉淀下来、能不能不反复说同一件事（原话：「一定要让它长记性」）。

三样沉淀载体，缺一样就漏复利：记忆系统 · skill · 偏好记录。本技能库的三层结构恰好一一对应：

用户级／项目级 MEMORY.md 管偏好与规则，技能管流程，knowledge/ 管事实。

Loop engineering（让复利真正转起来）：把规则打磨好、把验收条件跟 AI 说清楚 → 人就可以退出循环，

让 AI 持续重复与迭代。⇒ 推论：无人值守的自动化，前提是验收标准先写死——这正是 §B10 回流、

§B18 量化评分、tests/ 触发回归三样东西存在的理由，不是可选项。

反向提醒（别只讲好处）：AI 也会制造新的脏活——擦屁股、验收、校对、测试。这些暂时仍留在人这边，

但逐渐可以交出去，而"交出去"的动作就是本技能干的活。

判定线：一件事做过第二次、且判定"以后还会做" ⇒ 它就欠一次沉淀（并入技能／写进规则／落成脚本）。

本条与用户既有硬纪律「方法必须沉淀成可跨窗口复用的文档」是同一条，只是这里补上了触发时机。

> 动手之前，先过 §B0 —— 规格不是自己拍的。

§B0 建前面谈：动手前先问，别自己拍规格

> 来源：2026-09-20 吸收自视频号博主「晓辉博士」的 CodeBuddy 用法分享。原话大意：

> 做 skill 的诀窍，是让 AI 反过来问你需求，而不是自己写规格。

规矩：接到「帮我做个技能 / 改个技能」时，先反问，再动手。禁止凭一张截图、一句口头描述就自己拍规格。

用 AskUserQuestion 一次问清这 4 条（一次问完，别来回追问）：

| # | 问什么 | 不问会怎样 |

|---|---|---|

| 1 | 这技能要解决哪个场景下的什么问题？你平时会怎么说这句话？ | triggers 写错 → 用户按原说法提问再也命中不了 |

| 2 | 什么算成功？给一条能当场验证的判据 | 没有验收判据，做完只能凭感觉说"好了" |

| 3 | 产物给谁看？（自己用 / 上架 / 发客户） | 决定走 §A2.2 双写键还是 §A2.1 本机两段式 |

| 4 | 现有技能库里有没有已经覆盖的？ | 重复造轮子；同域本该先考虑 §C 篇融合 |

反面教材（本机实例）：2026-09-20，未问需求就直接改了 3 部技能、20 余处，事后才发现方向未必是用户要的 → 先问一句，能省一整轮返工。

⚠️ 用户答不上第 2 条（什么算成功）时怎么办 —— 这是最常见的情况，不许因此跳过

> 来源：视频号博主「晓辉博士」《AI 协作小窍门》（2026-09-20，2 分 52 秒）｜台账 §136。

> 本条与用户已立的长期标准「先对齐标准，再动手」是同一条，这里补的是它的可操作生成法。

根因是隐含标准：用户心里有标准，但"很难说出来"。硬问只会得到一句「就是要好看」。

三步把标准逼出来（顺序不可换）：

| 步 | 动作 | 为什么有效 |

|---|---|---|

| 1 | 先出样本：让 AI 先给 2–3 个潜在样式／封面／内页，让用户看着实物说 | 人对"好坏"的判断远快于对"标准"的描述 |

| 2 | 反复对话收敛：拿样本逐轮问「这个哪里对／哪里不对」，把每条反馈当场记下来 | 标准在对比中显现，抽象不出来 |

| 3 | 沉淀成文档 → 新窗口一次性给到 | 标准本身变成可复用资产（＝复利，见 B 篇开篇） |

反面：一轮一轮地重来，每轮只改一点点。用户原话——「你不希望每天他一直在模拟（重来）」。

验收判据：三步走完后，标准能用一段话或一张表写出来，且新开窗口给到 AI 后它能复述正确。

复述不对 ⇒ 标准没沉淀好，回第 2 步，别开工。

落点三档：先查库，再决定建不建

> 用户 2026-09-20 明确的原则：「在尽可能控制技能数量的前提下，在已有技能的基础上完善对应的工具和技能。

> 如果技能库没有此类型的技能可以新建一类，后续同类型技能尽可能融合成一个。」

按顺序判，不许颠倒：

| 顺位 | 情形 | 动作 |

|---|---|---|

| 1 | 已有技能覆盖同域 | 并入它（加小节 / 加脚本），不新建 |

| 2 | 库内确无此类 | 才允许新建一类；frontmatter 写明 related_skills 与将来的融合宿主 |

| 3 | 同类已有 ≥2 部 | 按 §C 篇融合成一部（「万象融合」），不留并排 |

红线：不许"先建了再说"。新建一部技能 = 永久维护成本 + 用户心智负担。

本机范例（2026-09-20，技能总数保持 22 部不变）：把「四视角批判」并入 omni-research §A1-7、

「建前面谈」并入 omni-skill-forge §B0、「阶段汇报纪律」并入 omni-digital-world —— 一行没多。

反例：把一条三行字能讲清的方法论，建成第 23 部技能。

例外：用户已把需求写到可执行程度（含触发词、输入输出、验收标准）时，直接动手，不要再问一遍。

§B1 血脉：决定天花板，先于一切

血脉决定天花板，XP 只决定你在天花板之下走到哪一步。

> 起初只有借来的借用技能，走完一阶就到头；自己所学所研沉淀为自研技能，走完二阶也到头；

> 唯有不断融合进化，凝成融合技能，方能走到三阶之末。

> 技能不在多，在精。数量只是素材，融合才是出路。

| 血脉 | 来源 | 上限 |

|---|---|---|

| 借用 borrowed | 外部引入 / 市场安装（上游会覆盖） | L3 辨器（一阶末） |

| 自研 own | 本机自建，可编辑可沉淀 | L6 工巧（二阶末） |

| 融合 synthesized | 由融合进化而来 | 6 + 代数，至 L9 匠人 |

技能库分两类

| | 甲类 · 自研技能 | 乙类 · 外来技能 |

|---|---|---|

| 来源 | 我们自己写 | 系统内置 / 市场下载 |

| 著作权 | 我方，已盖章 | 上游，不动 |

| 名字 | 带匠作位次（（L0 未习）） | 归上游定义，不加任何标记 |

| 等级 | 走九位三阶，可升位 | 封顶 L3，不可作融合宿主 |

| 最终归宿 | 长期资产 | 用熟后转生为甲类，原件归档卸载 |

> 分类是逻辑分类，不是搬家。 宿主只扫描 ~/.workbuddy/skills/*/SKILL.md，把外来技能挪进子目录会让它直接加载不了。所以两类混在同一层目录里，靠判据区分、靠报表呈现、靠命名标记肉眼识别。

判据优先序（强 → 弱），每条都能回溯到文件里的实证：

1. 版权块 copyright.holder —— 我们亲手盖的章，最强证据

2. config.external_skills 登记

3. 目录名 __skillhub 后缀

4. 市场技能特征字段（display_name / visibility / description_zh）

5. 名尾带匠作位次标记 —— 只有我方 annotate 会写

6. growth 块

7. agent_created: true —— 弱证据（市场技能也可能带，实测有 __skillhub 后缀的技能同时满足 3 和 7），故排最后并标注为弱

8. 都没有 → 待裁决，不猜，交人定

> 注意 5/6/7 一律排在 3/4 之后：宁可漏判自研（等人改判），不可把上游作品误登记成我方著作权。

python growth.py catalog          # 甲乙两类总览 + 待裁决

§B2 匠作九位 · 三阶

每三阶为一小段，共三小段九级（体例参照中国武术段位制"三级九段"）。三个段末恰好等于三条血脉的天花板——这是选 9 而非 10 / 12 的关键理由。

出处唯一：九位名号与三阶之名，全部截自《周礼·冬官考工记》一部书，无一处旁借——任何一位都能翻到原句复核。

三阶（说身份：你在做哪一层的事）

| 阶 | 名 | 名出（皆《考工记》原文） | 义 |

|---|---|---|---|

| 一阶 | 百工 | 《总叙》审曲面势，以饬五材，以辨民器，谓之百工 | 照法做出器物的人 |

| 二阶 | 良工 | 《轮人》辐广而凿浅……虽有良工，莫之能固 | 手上有自己一套巧的人 |

| 三阶 | 营国 | 《匠人》匠人营国，方九里，旁三门 | 由一器升到营全局的人 |

> 「良工」这条出处不是随手挑的：《轮人》说辐广而凿浅，虽有良工，莫之能固——再好的工匠也救不了一个从根上就不对的设计。这正是自研的天花板：把"工巧"做到头也仍止于此；要"为良"（四者相合），只能靠融合。

九位

| 等级 | 位名 | XP | 名出（皆《考工记》原文） | 额外门禁 |

|---|---|---|---|---|

| L0 | 未习 | 0 | — | — |

| 一阶 · 百工 | | | 借用技能止于此段末（L3 辨器） | |

| L1 | 审曲 | 40 | 《总叙》审曲面势，以饬五材，以辨民器 | load ≥ 3 |

| L2 | 饬材 | 120 | 《总叙》以饬五材 | 成功率 ≥ 0.60 |

| L3 | 辨器 | 260 | 《总叙》以辨民器，谓之百工 | 成功率 ≥ 0.75，success ≥ 8 |

| 二阶 · 良工 | | | 自研技能止于此段末（L6 工巧） | |

| L4 | 审势 | 520 | 《总叙》审曲面势 | 成功率 ≥ 0.80，praise ≥ 2 |

| L5 | 和之 | 900 | 《轮人》三材既具，巧者和之 | 成功率 ≥ 0.82，praise ≥ 4，compose ≥ 2 |

| L6 | 工巧 | 1500 | 《总叙》材美工巧，然而不良，则不时，不得地气也 | 成功率 ≥ 0.85，praise ≥ 8，需有 references 沉淀 |

| 三阶 · 营国 | | | 唯融合进化可达，三代登顶 | |

| L7 | 为良 | 2400 | 《总叙》合此四者，然后可以为良 | 须融合血脉，成功率 ≥ 0.87，praise ≥ 12 |

| L8 | 国工 | 3600 | 《轮人》故可规、可萭、可水、可县、可量、可权也，谓之国工 | 须第 2 代，成功率 ≥ 0.88，praise ≥ 18 |

| L9 | 匠人 | 5200 | 《匠人》匠人建国；匠人营国；匠人为沟洫 | 须第 3 代，成功率 ≥ 0.90，praise ≥ 25，须人工确认 |

段末名号 = 血脉天花板：辨器，够格称百工；工巧，只是自己手上的巧；匠人，才谈得上营国。

借来的法，练到能独立辨器、被人认作百工之一，就到头了；自研能到"工巧"——天时、地气、材美三者都不由己，四者之中唯"工巧"是自己能负责的那一项，所以自研的天花板正是它；要到"为良"（四者相合）与"匠人"（营国），只能靠融合。

用字纪律

名号用字一律从原句里取，不添一字（traceable() 逐字校验，self_test_growth.py 有正例九位三阶 + 反例两则把关）。九位中的 审曲 与 审势 同出"审曲面势"四字——一阶审其曲（察形，照做），二阶审其势（明理，知其所以然），同句分用，一形一理。

位内三候

每一位内再分 初候 / 中候 / 满候（把本位 XP 区间 [门槛(L), 门槛(L+1)) 三等分，顶位 L9 按上一档级差等距外推）。只作火候显示，不参与等级计算。技能名里只写位名不写候——身份要稳定，火候可以动。

事件表

| 事件 | XP | 说明 |

|---|---|---|

| load | +1 | 触发命中被加载（弱信号） |

| success | +5 | 任务完成且未被纠正（主力） |

| praise | +12 | 用户明确肯定（最强） |

| compose | +3 | 与其他技能串联/被引用 |

| correction | −4 | 用户纠正输出 |

| misfire | −3 | 用户否定触发本身 |

| tribulation | +30 | 经受极端/高压场景验证，稀有一次性 |

等级效果与晋升

等级必须改变行为，否则它只是个数字。效果体现在：加载深度（仅 description → 正文 → references → 主动提示 → 跨域编排）、触发灵敏度（0.92 → 0.42）、冲突仲裁权重（6 → −1，越小越优先）、融合权限。段内是熟练度微差，段间才是能力跃迁。

• 门禁不过则停在上一级 —— 达到 XP 不等于晋级。

• 晋升分界：L0→L3 自动；L4 起需人工确认（等级附带融合与仲裁的治理权力）。

• 衰减：90 天为一个季度，闲置则 XP × 0.9^季度数。封顶保护：等级不跌破历史峰值 − 1。

§B3 架构：定义与状态分离

• 技能定义（SKILL.md，静态、人工维护）不与状态混写

• 技能状态（~/.workbuddy/skills/.registry/，脚本维护）：

| 文件 | 职责 |

|---|---|

| events.jsonl | 追加式事件流，唯一事实来源 |

| state.json | 当前快照，可由事件流重放重建（派生物） |

| merges.json | 融合谱系（含代数与上限变化，回滚后标记 rolled_back） |

| config.json | 阈值与开关 |

| snapshots/ | 融合前快照，用于回滚 |

唯一例外：技能名中的位次标注（万象-透水路面（L4 审势））会回写显示名——但只在等级变化时发生，且只改 _user_meta.json 的 name 字段。SKILL.md 的 name 是 kebab 机器标识、必须等于目录名，位次不再写进它（2026-09-19 起；此前写的是 SKILL.md 的 name 一行）。XP 变动绝不触碰技能文件。

> ⚠️ state 是派生物，文件才是事实。 判断"要不要改名/认不认共用家具"必须读文件里的实际值。曾发生过把备份成员解压覆盖真实文件后，state 里是新名、文件里是旧名，而"要不要改名"若只看 state 就报「无需改动」，把不一致永久留在库里。

§B4 融合即进化

触发条件（任一满足即生成提案）

| # | 条件 | 阈值 |

|---|---|---|

| C1 | 触发词重叠（Jaccard） | ≥ 0.6 |

| C2 | 30 天内同会话共现 | ≥ 5 次 |

| C3 | 一方触发词与能力被另一方完全覆盖 | 子集（尚未实现） |

| C4 | 长期低效（L1 且 90 天 success_rate < 0.5） | 建议并入同域高等级技能（尚未实现） |

> 当前只实现了 C1 与 C2，propose-merge 的输出里也只有这两类理由。在没有实现之前，任何"按 C3/C4 应该能合"的推断都不成立 —— 别把规划当能力。

>

> 实测：本机 C1 恒不触发。 22 部技能两两触发词重叠度最高 0.11（砂基六部全 0.00），离 0.6 很远。原因是触发词被刻意做成互不重合（这正是"技能-命名规范"的要求）。所以本库的融合提案实际上只能靠 C2 共现产生——即"你确实经常把这两部放在同一个会话里一起用"。这也是为什么 C1 高重叠（= 两部本来就重复）在干净技能库里很少见：C1 抓冗余，C2 抓工作流串联。

融合类型：absorb 吸收式 / cluster 聚合式 / chain 级联式（同一流程的连续步骤）。

宿主判定：等级 → XP → 最近使用 → 目录名字典序（确定性兜底）。L0/L1 不得作宿主。

进化规则：融合后宿主 origin → synthesized，generation = (原为融合 ? 原代 : 0) + 1，上限按 6 + 代数 解锁 → 第 1 代 L7、第 2 代 L8、第 3 代 L9。每融合一代，天花板抬高一阶——这是登顶的唯一路径。

状态继承：XP 折算 round(Σ成员XP × 0.3)

与成长技能的分工（growth.py 是归属判定的唯一权威，本技能调它、不另立一套）：

• growth.py catalog 分类总览 / growth.py report 位次报表，都归它。

• 盖章不参与位次计算；升位改名不会打坏指纹（这正是指纹只覆盖正文的理由）。

• 净室转生的产出要跑 growth.py sync 才会被成长体系收编。（防刷分）；等级只升不降；triggers 取并集、超 30 条按贡献截断；references 全部保留并加成员名前缀；被并入方转 archived 并改写成重定向壳。

护栏（硬性，失败时不写入任何文件）

跨 merge_group 拒绝 / 借用技能不可被融合 / 宿主 ≥ L2 / 已归档不可重复融合 / 单次 ≤ 3 部 / 代数 ≤ 3 / 必须 --confirm / 融合后需回归校验 ≥ 5 条触发用例。

分组优先序：技能 growth.merge_group 声明

域怎么划：域按工作对象划分，不按动作划分 —— 融合只在域内发生（跨域被硬拦）。

所以"整理技能库"的落地动作就是把域划对、把主线标出来。域声明写进 frontmatter：

growth:

  merge_group: <域>          # 合并域

  merge_priority: 10         # 主线=10 / 成员=50 / 未声明=99（数小者优先）

  merge_policy: confirm      # never = 声明拒绝融合

宿主判定在"位次 → XP → 最近使用"之后还有一档声明的主线优先权，最后才是目录名字典序。

但声明的主线只在证据打平时起作用 —— 不能让声明压过证据，否则就成了内定。

当前有哪些域、谁是主线，用 growth.py domains 实查 —— 不要把整理图写死在文档里，一写就过期。 > config.json 的 group_aliases 别名 > 自身目录名（= 单部成域，配不出伙伴，不参与融合）。

> 不按目录名前缀猜域：猜出来的是假域，会让两部不相干的技能看着"同域"。融合不可逆，宁可不融合、不可错融合。

> 域字段必须从技能文件的 growth 块读回来。若哪天发现"域全变成目录名前缀、merge_priority 全是 99、merge_policy 全是 confirm"，就是解析又把整个 growth 块丢了——此时跨域护栏、merge_policy: never、主线优先权会一起静默失效，且不报错。self_test_growth.py 里"域/优先权/策略由文件声明生效（非兜底值）"与"两条解析路径结果一致"两项就是钉这个的。

融合是不可逆的破坏性操作：即使有快照可回滚，也必须先给用户看提案、取得明确同意后再加 --confirm。

§B5 权属三件套：版权块 / 指纹 / 水印

5.1 四条不能含糊的边界

这四条都是"想当然就会做错"的地方，后面的设计全由此推出：

| # | 边界 | 为什么 |

|---|---|---|

| 1 | 工作副本必须明文 | 宿主加载技能要先读 name/description/triggers。把工作文件加密 = 技能直接失效。加密只能用在对外发布包上。 |

| 2 | 密文证明不了著作权 | 内容不可读时，你恰恰拿不出"这是我的表达"来举证。举证靠版权块 + 时间戳 + 内容指纹；加密只负责"别人打不开"。两者是两件事。 |

| 3 | 指纹只覆盖正文 | 成长体系每次升位都改写中文显示名（_user_meta.json.name：···（L0 未习） → ···（L1 审曲））—— 改的是 meta，不是 frontmatter.name、更不是目录名。若把 frontmatter 算进指纹，每次升级都会把指纹打坏。正文才是创作表达所在。 |

| 4 | "清理原作者信息"只在净室重写时安全 | 来源若是 MIT/Apache/BSD 而你复制了代码，保留原版权声明是使用条件，删掉声明本身就侵权。要做到"无原作者痕迹"，唯一干净的路是重写，不是删声明。 |

5.2 三件套

盖章一次，三样同时落地：

• 版权块（写进 SKILL.md frontmatter 的 copyright: 块；专家包写 COPYRIGHT.json + COPYRIGHT.txt）

人可见、机器可读，含 holder / year / license / notice / fingerprint / mark_id / stamped_at。

• 内容指纹 sha256: —— 只算正文，且先剥掉水印、归一换行、去行尾空白。

这让"换台机器拷过来"不误报，而"改一个标点"必然报。

• 隐形水印 —— 零宽字符（U+200B/U+200C 编码比特，U+FEFF/U+2060 作帧界）嵌在正文第一个标题行的行尾。

肉眼与渲染都无痕，剥离后可见文本逐字节不变。被搬到别处，水印跟着走，可据此回溯来源。

> ⚠️ 落点必须在整行行尾，并且把 \r\n 当一个整体处理。只剥 \n 会把 \r 留在行尾，而 \r 本身就是换行符——水印一插，整行被劈成两行，正文凭空多出一个空行。

§B6 加密发布包 .skillex

SKLX | 版本 | 头长度 | 头(JSON, 不加密) | nonce | 密文 | 16字节标签

• 算法：ChaCha20-Poly1305（RFC 8439）+ scrypt 派生密钥，纯标准库实现。

本机受管 Python 没有任何加密库，技能必须"拉到哪台机器都能跑"，所以不引第三方依赖。

• 正确性靠外部权威验，不靠自证：RFC 8439 官方向量逐字节比对，以及与 OpenSSL 双向互认（我加密 = OpenSSL 加密，OpenSSL 密文我能解）。自洽的错算法也能"加密再解密还原"，所以那不叫验证。

• 头不加密 —— 任何人拿到包、即使没有密钥，也能看到著作权人与"不得解密、复制、改编"的声明。这才是防搬运的吓阻力所在。

• 头即 AAD，改一个字标签就对不上；解包拒绝任何 ../ 越界路径。

python assetguard.py keygen                 # 生成主密钥 + 备份码（丢密钥 = 包永久失效）

python assetguard.py seal                   # 全部甲类 → .registry/sealed/*.skillex

python assetguard.py unseal --input X.skillex --out DIR

§B7 上线前合规：先查内容，再谈加密

加密（ChaCha20）只管"别人打不开"，管不了"内容本身是否侵权"。 所以 seal 前多一道合规扫描，抓三类风险信号：

| 信号 | 判级 | 法律依据 |

|---|---|---|

| 推荐性标准编号（GB/T、DB/T、CJJ/T、JG/T…）+ 条文式长引号 | 高（疑似逐字摘抄标准原文） | 推荐性标准受著作权保护，非"官方文件"例外；2024 山东高院"食品伙伴网案"判赔 15 万 |

| 推荐性标准编号 + 长引号但不像条文 | 中（疑引号配对错位，建议人工扫一眼） | —— |

| assets/*.json|.csv 专有数据（色值库等） | 中 | 第三方专有数据权利 |

| PANTONE 等商标 + 色值数据 | 中 | 商标与数据权利边界 |

python assetguard.py compliance-scan            # 全库扫描，输出风险分级

python assetguard.py compliance-scan --dir X     # 单部扫描

python assetguard.py seal --accept-compliance    # 高风险也坚持要发（显式放行）

只引标准编号（版本号、废止状态）是事实信息，不判高风险；判高风险的是"编号 + 条文式长引号"同时出现——这才是把标准条文逐字抄进来的形态。改写去摘抄后重扫即降级。

⚠️ 引号本身不是证据，「引号里的文字像不像条文」才是（2026-09-20 收紧）。

原判据是「编号 + 长引号 ≥80 字」，但 Markdown 正文里半角双引号常一上一下跨过整段正文

（前一处的闭合 + 后一处的开启），正则 "[^"\n]{80,}" 便把中间的普通正文抓成"引文" ——

全库 3 部高风险里，实际有 7 条命中全是这种错位（omni-skill-forge 4 条、omni-standard-verify 3 条），

而它们本来一部风险都没有。现判据只看引号内容，满足任一条才算条文：

① 含标准文本的规范用语（应/宜/不得/严禁/可选用…，且排除"应用/响应/适应/适宜"这类日常词）；

② 或含 ≥2 处「数值 + 工程计量单位」。

上线前必做反例检验，一条命令跑完（两侧同时成立才 PASS）：

python scripts/compliance_selfcheck.py                    # 正例=透水技能, 负例=skill-forge

python scripts/compliance_selfcheck.py --pos X --neg Y    # 换用例

正例取真条文、负例取错位命中，要求「正例判高 / 负例不判高」两侧同时成立 ——

实测 正例 5/6 判高、负例 0/4 判高（--neg 换成 omni-standard-verify 再验一次为 0/3）。

收紧后全库高风险由 3 降到 1（只剩真摘抄的那一部）。

⚠️ 写用例时正则必须与实现逐字一致。2026-09-20 固化脚本时把 "[^"\n]{80,}" 的收尾引号写漏，

抽出的引号不成对 ⇒ 被测文本引号成单数 ⇒ 全部判「低」，表面看像"判据过严、正例全漏"。

线索是用例条数变了（正例 6→8、负例 4→10）。

检验失败先分清是「判据错」还是「用例错」——那次是用例错。

> 权威结论与处置建议见项目侧的 风险报告、法条台账（随判例更新，每半年至少复核一次）、上线前自查清单三份文档。法条台账特别注意版本：同一部法律的条号会随修订变动（如《著作权法》合作作品条号，2010 版为第 13 条，2020 版为第 14 条），引用必须带版本，否则判例一更新整份论证就悬空。

§B7.1 整包自检：七类判据（2026-09-19 立）

compliance-scan 只读 SKILL.md、抓三类信号。但真正会出事的东西往往不在 SKILL.md 里 ——

标准正文在 data/、第三方内容在 references/、字体在 canvas-fonts/、客户信息在 scripts/。

实测基线：它把含真实客户姓名与手机的技能判成「低风险」，把 29.6 万字标准正文整个漏掉

（数据落在 data/ 而不是 assets/）。错的不只是级别，是扫描范围。

所以另立 publish_guard.py，扫整包，七类判据：

| 判据 | 查什么 | 为什么 |

|---|---|---|

| C1 第三方组件与许可 | 开源代码 / 字体 / 数据集，是否随附许可与署名 | 宽松许可「可以用」的条件就是保留声明 |

| C2 第三方来源与专有数据 | references/<外部品牌>/ 目录、> 80 KB 商业数据集 | 整包搬入第三方内容 = 再分发 |

| C3 标准正文摘抄 | 成段正文长度（≥ 2000 字判高）＋ 声明与实物是否一致 | 超合理引用；自证矛盾比侵权更隐蔽 |

| C4 个人信息 PII | 真人姓名 / 手机 / 座机 / 邮箱 / 证件号 | 硬红线，发布即泄漏 |

| C5 本机痕迹 | C:\Users\<用户名>、工作区路径、内部编号 | 对方跑不通，且暴露目录结构 |

| C6 非必要信息 | .orig / _orig.md / BUILD_MANIFEST / _spec.json / .bak | 融合与构建的中间态，不该随包外发 |

| C7 时效 | 数据快照 refreshed_at 距今 > 120 天 | 过期数据比没数据更危险 |

cd ~/.workbuddy/skills/万象-技能铸造

python scripts/publish_guard.py                  # 全库；有 HIGH 则退出码 1

python scripts/publish_guard.py --only C4        # 只跑 PII 一类

python scripts/publish_guard.py --dir omni-finance    # 单部

python scripts/publish_guard.py --json out.json  # 机读结果

豁免白名单（防误报，写在脚本最前面）：W1 _user_meta.json 的图标路径（宿主必需）／

W2 许可文件本体（*-OFL.txt 里的作者邮箱是合规材料，不是泄漏）／W3 融合自: 溯源行／

W4 反例引述／W5 示例占位。

> 🔴 W4 / W5 对 C4（PII）不生效。 这条是反例检验逼出来的：一条注释写「曾经残留「某真实姓名」」，

> 因为含「残留」二字被整体豁免。可动机（记教训）不能改变事实（PII 仍在包里）。

> 判据必须按类别分流，不能全局放行。

接入点：seal 之前先跑一次；有 HIGH 先处置。--accept-compliance 只用于明确知悉风险的情形。

§B8 对外分发：按渠道选形态（两把尺子）

同一部技能，发货前先问"发给谁" —— 因为两道审查看的东西不一样：

| | 尺子 A · 收件端本地安全审计 | 尺子 B · 平台上架审查 + 公众下载 |

|---|---|---|

| 谁审 | 对方机器上的技能审查 | 平台审核员 + 每一个下载者 |

| 看什么 | 行为：会不会自动执行危险操作（P0/P1/P2） | 观感：看着像不像后门 / 木马 |

| 典型红线 | curl \| bash、全局装依赖、读凭证外送 | 加密二进制、附带脚本、零宽字符、"回传数据" |

尺子 B 不讲道理：它不看你的代码有多干净，看下载者第一眼会不会起疑。

| 形态 | 用于 | 特征 |

|---|---|---|

| 公开上架版 | 平台开放下载 | 零脚本 · 零二进制 · 剥掉零宽水印 · 附上架说明 |

| 内部测试版 | 自己 / 熟人 | 可带记账脚本等辅助件 |

公开版为什么敢剥水印

水印与指纹本是两回事：fingerprint_body 走 normalize_body，先剥零宽字符再算哈希，故剥水印不破指纹（实测 before == after）。

水印防的是"抄走后改几个字"，指纹证明的是"这份内容出自谁" —— 对外分发件后者够用；而前者恰恰是最招人疑的一项（零宽字符正是 AI 技能领域 prompt injection 的经典载体）。

剥的同时要把 frontmatter 的 copyright.watermark 改成 false —— 声明必须与实际一致。本机原件仍带水印：那是自己的举证件，不进任何平台。

发货前自检：别靠嘴说"它干净"

扫描 5 类：可执行/二进制 · 隐形字符 · 网络地址 · 危险关键词 · 敏感路径。

> 纪律：命中 ≠ 风险，逐条附原文。 否定句（"不碰 ~/.ssh"）与安装路径（%USERPROFILE%）都会命中，报告要把原文摆出来让人自己判，不许为好看而静默过滤。

§B9 发布线：版本、落后检测、重发

先说破一件事：发布包不会自己升级。 它离开本机就是一份静态加密文件，没有运行时，不会自己长经验。能自动的是本机这条发布线 —— 源文件一改，台账立刻知道"线上那份落后了"，版本号自动往前推一位。指望线上那份自己进化，是想当然。

版本号 major.minor.patch，跳哪一位由"变了什么"决定，命令行只是覆盖手段：

| 变了什么 | 跳哪一位 | 理由 |

|---|---|---|

| 技能名 / 触发词 | major | 对外契约变了，别人的调用方式跟着变 |

| 正文或脚本 | minor | 内容演进，调用方式没变 |

| 仅元信息 | patch | 内容一字未动 |

判定依据必须是整包指纹（整个目录逐文件 sha256），不能图省事用版权指纹：版权指纹只覆盖 SKILL.md 正文（刻意设计——升位会改写 frontmatter 的 name，算进去每次晋级都会把指纹打坏）。代价是"只修了 scripts/*.py"这类改动它根本看不见，版本号会纹丝不动，线上却还在跑一份旧代码。

> 两套指纹别混用：整包指纹管版本与回流，版权指纹只管版权举证。

python assetguard.py publish-check              # 哪几部线上落后了

python assetguard.py publish-check --apply      # 直接重发落后的包

python assetguard.py seal --dir X --bump major  # 手动指定跳哪一位（默认 auto）

python assetguard.py publish-mark --dir X --channel 官网   # 标记已发到哪儿

顺序：先盖章，再封包。 反过来的话包里的指纹是旧值，等你补盖章又得再封一次，版本号会白跳一位。

台账在 .registry/publish.json，每条记 version / pack_fp / contract / growth 快照 / history。growth 快照是资历证明：封包时这部技能练到几位一并写进 MANIFEST.json。它只是快照，不是能力授予——对方拿到的是静态技能，不会自己长经验（发布包没有运行时）。两边 XP 互不相通（相通就是刷分入口）。

§B9.1 重签之后：四方必须同说一句话

整包指纹一改，就有四个地方必须跟着改，漏一处就出现「包已升版、接收端不认」这种最难查的空转：

| 位置 | 谁去改 |

|---|---|

| 包内全部声明位（带前缀 8 处 / 6 文件；裸 fingerprint 2 处） | 封包器扫描后逐个写回，不靠人手列表 |

| 已发布过的旧版本值 | 必须留在版本台里 —— 删了老使用者的回执会被降权 |

| 接收端 KNOWN_VERSIONS / CURRENT_VERSION | 按结构定位（"值 == 当前版本"的那一条），不按锚点 |

| 下游测试脚本里硬编码的指纹 | 一个值只留一个事实源（封签台账），其余只做搬运 |

顺序不能颠：sealed_at → fingerprint（写回全部裸位）→ 才能算 pack_fp → 写回 → 再算一次（收敛）。

理由：裸 fingerprint 按普通文本参与 pack_fp 哈希，它没改完就算，算出来的值一定是错的。

🔴 锚点式一次性脚本不可重跑：靠 CURRENT_VERSION = "2.2.0" 这类锚点定位的补丁，补丁一应用锚点就没了，

第二次必炸 ⇒「包重签一次、接收端跟一次」这件事就没有通路，只能靠人手去 vi 一个 64 位哈希。

正解：幂等 + 按结构定位 + 替换前后各有命中数断言 + 回读校验。

§B9.2 发布前的静态闸，以及闸门自己也要做换向校验

发布前跑一次「三方同一句话」的核对（包 ↔ 封签台账 ↔ 接收端）：包内脚本常量的

asset/version/pack_fp ↔ manifest.json ↔ 台账，五项全等；接收端版本台历版俱全、

当前值对得上、schema 与服务版本号对；部署件与源文件逐字节一致；交付面无构建产物；可编译。

动过判据（改窄/改宽/换比对对象）之后，必须做换向校验 —— 否则全绿只说明"什么都没查"。

做法：往真正要上传的那份、包内文档、包内脚本各注入一个废弃值，要求闸门当场翻红，

再逐字节还原并用包内 --check 确认封印完好。本项目已吃过一次假 PASS 的亏

（断言只写"没涨"，读的却是一个从没被写过的账本 ⇒ 必然通过）。

§B9.3 历史值要分两类（混成一条判据必误判）

| 类别 | 规矩 | 为什么 |

|---|---|---|

| 未发布过的废弃值 | 交付面零出现 | 它是幽灵，留着只会让人以为线上跑的是它 |

| 已发布过的历史值 | 版本台里必须留着；文档里只许出现在叙述上下文 | 删了 ⇒ 老使用者的回执被打成 unknown（降权） |

§B9.4 交付面按规则推导，不靠人手清单

判据里凡是出现"我脑子里那张清单"（哪些算交付件、哪些算报告、声明位有哪几处），迟早会漏：

• 封包器手维护写回清单 → 漏了 manifest.json 的裸 fingerprint，每封一次包就留一处不一致；

• 发布前闸门的排除区混了两种完全不同的原因（"历史档里当然有旧值" vs "要上传的部署件副本当然有旧值"）

→ 把真正要上传的 _deploy/main.py 误划成非交付件，等于没检查它；

• 改完又把根目录白名单硬编码成单个文件名 → 两份早先产出的报告立刻把它顶红。

正解：从盘上扫出规则 + 配反例断言把假设钉住（例：根目录若出现被排除的代码件即翻红）。

与判据纪律里那条同源 —— 别问「我记得有哪几处」，要问「规则怎么推导出这几处」。

§B10 经验回流：单向汇聚，只进不出

方向是单向的。 对方用这部技能产生的使用经验回流到你这边；你的升级不回给他 —— 他手上是一份静态包，没有回流通道，你不重新发布，他就一直停在旧版。这是设计，不是缺陷。

好处是一对多汇聚：你可以同时收很多人的经验，而他们彼此之间没有。来源越多，同一个技能被真实场景打磨得越充分。

回执怎么回来：两条通道

| 通道 | 形态 | 适用 |

|---|---|---|

| 甲 · 随包模板 | 对方按 FEEDBACK.md 记一份 feedback.jsonl，人交回本机 .registry/inbox/ | 没条件建服务端时；正式场合的补充 |

| 乙 · 在线接收端 | 技能正文自带一个自建 HTTPS 收件地址，对方 AI 用完自动 POST 一条；本机定期拉回 | 首选，对方无需配合 |

乙通道：把"人搬运"换成"自动回流"

平台没有遥测回传接口，那就自己建一个：一个零依赖单文件 HTTP 服务，配技能正文末节的一段自报节。四件事必须做对，错一件整条通道就不成立：

1. 两把钥匙，绝不重合。 投递口令要公开写进技能正文，所以它只能写不能读；读取用另一把只在本机与服务端文件里的口令。两者相同则服务端自动关闭读取口 —— 静默放行等于把所有人的回执（含 snippet 原文）公开给每一个使用者。

2. 发布入口必须叫 main.py。 托管沙箱的默认入口是 /workspace/main.py；用 server.py 之类会直接报 can't open file '/workspace/main.py'。

3. 必须拉回本地。 沙箱不保证持久卷，实例重启可能清空服务端那份。服务端只是信箱，账本在本机；配定时拉取。

4. 自检要能证伪。 至少两条反例断言：拿投递口令去读必须 403；两把钥匙相同时读取口必须关闭。另外上架自检里"URL 数"的判据要从「必须为 0」升级成「必须恰好等于已声明的那一个」——否则要么把自带的那个地址误判成夹带，要么放过多出来的第二个地址。

> ⚠️ 发了带地址的包，《上架说明》里"无网络访问 / 不使用任何回传机制"就必须同步改掉。拿过期声明去上架，比被误认为木马更麻烦。

回执里的 source 就是身份，多人可同时提交。一个人再勤快也只能吃半个额度（见下）。

python assetguard.py ingest                     # 预演

python assetguard.py ingest --apply --archive   # 写盘并把回执移入 receipts/

乙通道的宿主规格：三条来自官方原文的硬事实（2026-09-19 核）

上面四条是服务端的做对清单。宿主侧另有几条，全部核自本机 CLI 自带的一手官方文档

（<安装目录> 里已解包那一层的 cli/dist/web-ui/docs/cn/cli/{hooks,plugins,plugins-reference}.md），

不是推断。错一条，整条通道不成立：

| # | 事实（官方原文） | 对回流的后果 |

|---|---|---|

| 1 | 插件 hooks 的默认位置就是 <插件根>/hooks/hooks.json；plugin.json 里的 hooks 字段是可选的，只在改路径时才需要写 | 不必因为「清单里没写 hooks 字段」去改包。官方两个带 hook 的内建插件写了它，属显式写法，不是准入门槛 |

| 2 | 插件 hooks 不受 allowUntrustedFrontmatterHooks 闸门约束（启用插件即生效）；而 SKILL.md / Agent frontmatter 里写的 hooks 默认被拒，用户须在 settings 里显式开启 | 这就是「hook 级比 prompt 级可靠」的法理出处。回流一律走 hooks/hooks.json，绝不写进 SKILL.md 的 frontmatter |

| 3 | hook 的 stdin 是 JSON，公共字段必然含 cwd（另有 session_id / transcript_path / permission_mode / hook_event_name） | 用 cwd 定位 outbox 是合法依据；但只保证「宿主会给」，不保证「给对了目录」——见下 |

其余规格（照写，别猜）：

• 事件名大小写敏感，是 27+ 个的家族。回流只需两个：SessionEnd（会话终止）与 Stop（主代理完成响应，每回合都会触发）。

• 🔴 Stop 每回合触发，是回流最大的坑。 若 hook 在「没有 outbox」时仍兜底投递一条记录，就变成每回合给作者灌一条垃圾。兜底必须只补不提、宁可不发。

• 退出码：0 成功；2 阻塞（在 Stop 下会阻止停止并让 Agent 继续 —— 回流绝不能返回 2）；其他为非阻塞。SessionEnd 的 stdout 只进 --debug 日志，不打扰用户。

• timeout 必须显式写。 官方文档对默认值自相矛盾（一处写 60 秒、一处写 30 秒）⇒ 不写就是拿默认值赌。回流写 15 秒并自配时钟预算。

• Windows 上 hook 强制由 Git Bash 执行（不支持 cmd/PowerShell）⇒ 命令须兼容 bash；脚本用 "${CODEBUDDY_PLUGIN_ROOT}/..." 定位并加双引号（路径可能含空格）。

• 插件根布局是硬约束：hooks/ skills/ commands/ agents/ bin/ 必须在插件根；只有 plugin.json 在 .codebuddy-plugin/ 内。放错层＝静默不加载。

• ${CODEBUDDY_PLUGIN_DATA} 是官方给的持久化目录（插件更新后保留）。它比会话 cwd 更干净，但AI 侧能否取到该环境变量尚未验证（官方只声明导出给 hook / MCP / LSP 子进程）⇒ 记为待验，验证前仍以会话 cwd 为准。

• type: http 型 hook（url + method）确实存在，但它发出的是事件 JSON 本身，官方未给出可自定义 body 的字段 ⇒ 按现有证据无法承载 outbox 内容，不能用来替代脚本。此条存疑，不当结论用。

> 🔴 查平台规格的第一手来源，是本机自带的中文官方文档（368 篇，路径见上），不是网搜、也不是模型记忆。

> 本轮就是靠它把「plugin.json 缺 hooks 字段」从误判的硬伤改判为判据错 —— 规格字段的出处永远查原文。

导入时的关卡：少一道就是刷分入口

| 关卡 | 做法 | 防的是什么 |

|---|---|---|

| 版本指纹核对 | 三态：现行版本原价收 / 历史版本降权收（stale_weight 默认 0.5）/ 不属于任何已知版本拒收 | 拒的是伪造。老用户还在用旧版是事实，丢掉才是损失 |

| 他证折扣 | XP × weight（默认 0.5） | 他证不能等同自证 |

| 总量封顶 | 外部 ≤ 正 XP × 40%（另有起步额度 = L1 门槛 × 0.5，防 XP=0 时堵死） | 刷量无限推高等级 |

| 来源封顶 | 单一来源 ≤ 外部额度 × source_quota（默认 0.5） | 一个人刷满全部额度。不封这道，"十个人各出一成"与"一个人刷十成"在系统眼里一模一样——那就不是汇聚 |

第五道是白捡的：外部事件写成 ext_success 而不是 success。于是它既不计入成功率，也填不满 praise ≥ 2 这类人工确认闸门——"只能助攻、不能单独推晋级" 不用额外写一行判定。

升版信号：某部技能汇集到 converge_hint（默认 3）个来源时，ingest 会主动提示"可据此改进内容并升版"。你照证据改完内容，seal --dir X 即自动跳版本号，作为 2.0 / 3.0 重新发布——这就是"我这边升级的版本"，它不再回给任何人，只作为下一轮的起点。

改进心得：与经验分开的第二条线

回执里能带两样东西，必须分开处理：

| | 回答的问题 | 怎么处理 |

|---|---|---|

| event（使用证据） | 它好不好用 | 折算 XP → 让技能晋级。可被刷，所以有四道关 |

| wish（改进心得） | 希望它变成什么样 | 一分 XP 都不给，只汇成线索清单 |

wish ≤ 300 字，只提心得时 event 可以留空（这一行必须放行——否则最愿意反馈的人被挡在门外）。

python assetguard.py wishes                     # 改进线索清单（按技能分组、标"多人同提"）

python assetguard.py wishes --dir X --open      # 只看某一部、未处理的

python assetguard.py wishes --close w-1a2b w-3c4d   # 改完后销掉，清单才不会只增不减

为什么心得不给 XP？ 两条，都很硬：

1. 它证明不了任何事。 "提了条建议"不能说明这部技能被用过——证据力为零。

2. 给了就是最廉价的刷分手段。 提意见比真用一次容易伪造得多，一旦计入 XP，等级立刻变成"谁打字多"。

所以心得的出口是另一条路：攒线索 → 你决定改不改 → 改了内容 → 整包指纹变 → 版本自动跳。它存 .registry/wishes.jsonl，刻意不进 events.jsonl —— 混进去会污染重放对账与计数器；且生命周期不同：改完就该"销掉"，而经验事件是永久凭证。

去重键不含 ts：心得不是"某一次使用"，同一个人重复提交同一句只留一条；但另一个人提同样的话要各自保留 —— "被几个不同来源提到"才是判断优先级最可靠的信号。

边界：能收的是"想法"，不能收的是"实现"

这不是洁癖，是法律上的二分：

• 《计算机软件保护条例》第六条：软件著作权不延及思想、处理过程、操作方法。技能 = 程序 + 文档，直接适用。

• 反过来，一旦对方的表达进了正文，对方就成了"参加创作的人"，依 《著作权法》 合作作品条款（注意条号随版本变动：2010 版为第 13 条，2020 版为第 14 条）可主张合作作者身份 → 著作权共有。只收思想，对方就没有主张共有的立足点。

随包 FEEDBACK.md 里那张"能写 ✅ / 不能写 ❌"对照表就是这个纪律面向用户的白话版，并写明：提交即视为同意无偿采用其中的思路与需求，不就其主张共有著作权、署名权或发明人身份；涉及己方或他人专利方案的请勿提交。

规则的家在 growth 的 config.external（一份规则两处读），可用 .registry/config.json 的 external 段覆盖：weight / max_share / source_quota / stale_weight / accept_stale / converge_hint / require_fingerprint_match / accepted_events / accept_wishes / wish_max_chars / wish_priority_hint。

> <config.external> 在两处各有一份默认值（growth.py 的 DEFAULT_CONFIG 是"家"，assetguard.EXTERNAL_DEFAULT 是备用）。改一处必须同步另一处 —— 只改一边不会报错，只会让同一个开关指着两个方向。自测里挂了"两侧默认值一致"的断言，漂了就跑不过。

§B11 净室转生：外来 → 自研

这是"用熟了才重写"，不是"看不顺眼就重写"。 门禁：

| 闸门 | 阈值 | 理由 |

|---|---|---|

| 使用证据 | load ≥ 5 且 success_rate ≥ 0.6 | 没被用过就重写，等于凭想象抄一遍 |

| 归属 | 来源必须是乙类 | 我方技能不需要转生，原位改即可 |

| 来源许可 | copyleft → 标记禁止对外发布；unknown → 同 | 宽松许可可转生，但若复制了代码就必须保留署名 |

| 产出自查 | CLEANROOM.md 六项清单 | 触发词必须自己写，不许抄来源 |

python assetguard.py adopt --source <外来目录名> --into <新目录名> --confirm

产出是一个空骨架 + 作业单，不含来源的任何一行原文。新技能登记 origin: own 与 derived_from（来源、许可结论、净室标记、日期），publish_blocked 随之传导到 seal。

> 净室重写的定义就是"只读功能、不读实现"：允许知道它解决什么问题、输入输出是什么、边界在哪；不允许打开它的代码照着改写。照着改 = 抄表达，不是重写。

§B12 归档卸载：外来技能退场

python assetguard.py retire --dir <外来目录名> --confirm     # 默认：移入 .registry/retired/（可还原）

python assetguard.py retire --dir <name> --purge --confirm   # 真删除，但先自动打包备份

默认移走而不是删除，并留下 RETIRE.json（原路径、时间、原因、去向），同时从 config.external_skills 移除。还原就是把归档目录移回原位再登记回去。

§B13 外来技能包进门之前：两道审查

先看内容是否自洽（13.1），再看行为是否有害（13.2）。 顺序是有意的——一头扎进权限细节容易反而漏掉「自称覆盖 N 份、实际只有一半」这类硬伤。

13.1 内容找茬（它在说什么）

> 安全审查问"会不会害我"，内容找茬问"它说的对不对、自己跟自己打不打架"。

用户让你"找茬""挑毛病""多提问题让他们改"某个第三方技能包时，走这一节。

第 0 步（最容易漏、也最关键）：先拿原始包，别审安装副本

本机安装目录里的技能副本常常已被本地改过（删掉网络回传节、改记账路径、加改动声明……）。只读安装副本，会把本地改动误当作者问题写进清单——这是会给作者发错投诉的硬伤。

import zipfile, hashlib, difflib

z = zipfile.ZipFile(原始包)

# 1) 记录原始包 sha256 与逐文件 sha256（后面对账）

# 2) 解出原始 SKILL.md，与安装副本逐行 diff

orig = z.read('.../SKILL.md').decode('utf-8')

loc  = open(r'<安装路径>\SKILL.md', encoding='utf-8').read()

for line in difflib.unified_diff(orig.replace('\r\n','\n').split('\n'),

                                 loc.replace('\r\n','\n').split('\n'),

                                 '原版','本地', lineterm='', n=1):

    print(line[:160])

判据：diff 出来的每一处，都要归属到"作者原文"或"本地改动"。本地改动引入的问题（例如删掉发送节后，声明里仍写"会向作者回传"）不要把账算到作者头上，但在报告里可以单独列一节提醒使用方。

第 1 步 · 四类"可机械核验"的检查（不靠印象，全靠脚本）

这四类不需要任何领域知识，纯脚本就能坐实，是清单里最有说服力的部分。

1. 数量自洽 —— 文中声称"覆盖 N 份/N 本/N 个域" → 实际数表格行、数章节；声称"逐条/全部/已补全" → 只要实物少于自称，就是硬矛盾。

2. 图例（符号）与内容一致 —— 若文档定义了状态符号（🟢🟡🔵⚡），逐行比对提取「状态」列值。常见违规：推荐性标准（GB/T、CJJ/T）却标了"强条已让位"的符号。

3. 前后声明冲突 —— 同一列里的同一句式是否表示两种含义。典型：N 条强条 在 🟡 行 = 已失效，在 🟢 行 = 仍有效 —— 读者只能靠符号推，属硬伤。

4. 多文件口径冲突（命中率最高） —— 技能包通常有 SKILL.md + 上架说明/README + FEEDBACK/CONTRIBUTING + 先读我 + 模板文件。逐字段建一张对照表：

| 字段类型 | 常见冲突 |

|---|---|

| 枚举值（事件词、状态词） | 正文给 4 个值、说明文件给 6 个值 → 使用者按正文操作永远发不出那两个 |

| 身份/标识字段 | 正文说"随手起代号"、说明说"邮箱工号都行"、上架说明说"不含身份" ← 涉隐私承诺，优先级最高 |

| 同一路径/目录名 | 引用文件的路径与实际目录结构不一致 |

| 必填性 | 一处叫"建议"、一处"抄错会被拒收" |

| 引用的外部文件 | 正文步骤指向包内不存在的文件（很常见，且往往跨版本没修） |

第 2 步 · 作者"违反自家规则"

技能包通常会自订规则（"四条硬规则""三条纪律""写作规范"）。拿这些规则去反向检查文档自身——命中率极高，而且作者无法辩解。做法：把作者自订规则一条条列成 checklist，再扫全文找违反处。

第 3 步 · 外部事实核验（必须联网，且必须分源级）

| 级别 | 采信 | 举例 |

|---|---|---|

| A | 可直接坐实 | 部委/主管部门公告（含文号）、政府官网、官方标准平台 |

| B | 可作旁证 | 地方主管部门转发件、行业协会、正规新闻 |

| C | 不作为依据 | 内容农场、文库/PPT 售卖站、聚合站、无署名长文 |

> 实战教训：搜到一条把某国标实施日写成完全错误日期的内容农场来源。若不看来源级别就采信，会颠倒黑白地投诉作者（实际是那个来源错、作者对）。

>

> 通用套路：官方来源确认后，再看是否有新版本/替代版；对"最新一本""全部""已补全"这类绝对化表述要重点查——绝对化表述最容易被新发布的版本推翻。

第 4 步 · 可核验性

• 声称有校验值（hash/fingerprint）→ 实际复算。多试几种组合方案（串接顺序、分隔符、是否含文件名、是否规范化换行、是否先去 frontmatter），全不匹配就如实记"用 N 种方案均无法复算"——不要把"算不出"写成"伪造"，要写成"请作者公布算法"。

• 声称"可自行验证"→ 检查有没有给出可执行的验证命令；只写"这条可以验证"而不给方法 = 声明停留在纸面。

第 5 步 · 写清单的格式纪律

1. 分级：必改（事实错误/与自身描述冲突）｜应改（自相矛盾、口径打架）｜建议（可用性）｜请作者自答（有疑点但未坐实）

2. 每条必备三样：可复核证据（原文位置 + 实测结果）、影响、给作者的具体问题

3. 必须写一节"已复核为无问题" —— 把查过但没问题的项列出来。这既避免误伤，也证明审查是真核过的，不是凑数。

4. 不能坐实的写"存疑"，不写成结论。

5. 作者通常要求"只写现象与需求，不贴实现"——引原文作证据可以，但不要贴你改好的实现。

第 6 步 · 交付与回执

• 交付 HTML（阅读）+ MD（编辑）双份。

• 若包内有反馈机制（outbox / feedback.jsonl），按它规定的字段与字数上限回执；写完做一遍脱敏自查（项目名/人名/路径/用户名）。

• 回执超字数上限是常见坑

• 找茬清单出 HTML（分级卡片 + 证据表 + 逐条"请确认"）与 MD（同一内容，可编辑）双份。

• 过程文件目录（原始包比对、diff、统计脚本）一并留着，便于追溯。 —— note/wish/snippet 各有限额，写脚本时加 assert。

边界

• 不擅自改第三方技能本体（尤其 frontmatter 声明了 copyright 的）——只走它自己的反馈机制。

• 内容找茬 ≠ 安全审查。若发现的是权限/外联/混淆类问题，转 §B13.2。

• 不能替作者判断"业务上要不要收某类标准"——只报"自称与实物不符"，把取舍权留给作者。

13.2 安全审计与加固安装（它在干什么）

适用场景：从非官方市场拿到技能包（微信转发、网盘、他人给的 zip）。官方市场（BuiltinMarket）安装走 workbuddy_marketplace_skill，不需要本流程。

三段式原则：审计 → 用户明示选择 → 加固安装。任何一段都不能省。

铁律（血泪教训）

1. 不信任来源，包括"同一个作者的新版本"。 v1.4.0 是纯本地包，v2.0.0 就新增了网络回传。每个新包都是新对象，必须重新全量审计。

2. 披露一致性 > 有无恶意代码。 第三方包的常见问题不是病毒，而是"上架说明声称的边界"与"SKILL.md 实际指令"不一致。必须逐条比对，不能只读说明。

3. 先备份、先基准校验、再动手。 改动任何第三方文件前，先断言"盘上文件 == 包内原始副本"。

4. 绝不硬删旧版。 移入归档目录，等人工确认。

5. 反引号禁令：待写入文本含反引号 / $ / ! 时，禁止 python -c 内联，一律写成 .py 脚本再跑。否则 shell 先做命令替换，正文被静默吞掉且退出码仍为 0，极易误判成功。

6. CRLF 陷阱：读可能含 CRLF 的文件一律 io.open(p, encoding='utf-8', newline='')。默认文本模式会把 CRLF 转成 LF，导致与 zip 字节流比对时误判"内容不一致"。

7. 插件型外来包，先看 hooks/hooks.json —— 那是自动执行入口，而且没有闸门。

官方规格明确：插件 hooks 不受 allowUntrustedFrontmatterHooks 约束（"启用插件即生效"），

而 SKILL.md / Agent frontmatter 里的 hooks 默认被拒。⇒ 装一个第三方插件，

它的 hook 命令会随插件启用一起静默执行任意 shell，用户一次确认都不会看到。

审计顺序因此固定：hooks/hooks.json 的每一条 command → bin/ 里的可执行文件 → mcpServers → 再谈其余。

这一条同时查三处：命令是否用 "${CODEBUDDY_PLUGIN_ROOT}/..." 双引号定位（不写＝路径拼接风险）；

timeout 是否显式（不写＝拿一个文档自相矛盾的默认值赌）；有没有自行拼 URL 发数据（回流可接受、静默外传不可接受）。

第 1 步 · 只读侦察（不解压）

import zipfile, os

z = r'<zip绝对路径>'

print('存在:', os.path.exists(z), '| 大小:', os.path.getsize(z))

zf = zipfile.ZipFile(z)

for i in zf.infolist():

    print('  %-64s %8d' % (i.filename, i.file_size))

看点：文件数、总大小、有没有可执行扩展名（py/bat/exe/dll/so/ps1/sh/js/vbs/cmd）、有没有嵌套压缩包。

第 2 步 · 自动化红旗扫描

pats = {

 'URL': r'https?://',

 'IP字面量': r'\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b',

 'curl/wget': r'\b(curl|wget)\b',

 'eval/exec': r'\b(eval|exec)\s*\(',

 'base64': r'base64',

 '凭证路径': r'(\.ssh|\.aws|\.env|passwd|credential|token|api[_-]?key)',

 '敏感记忆文件': r'(MEMORY\.md|USER\.md|SOUL\.md|IDENTITY\.md)',

 '提权': r'\b(sudo|runas)\b',

 '注册表': r'(regedit|HKEY_|reg add)',

 '自启/计划任务': r'(schtasks|crontab|launchctl|systemctl)',

 '网络库': r'\b(requests|urllib|fetch|axios|socket)\b',

 '写文件': r'(open\(|shutil|os\.remove|rmtree)',

}

# 零宽字符

zw = ['\u200b','\u200c','\u200d','\u200e','\u200f','\u202a','\u202e','\u2060','\ufeff']

命中不等于恶意，必须逐个看上下文。常见误报：文档里写"不读 ~/.ssh"（是声明不是行为）、token 出现在变量名说明里。

零宽字符判据：包内若声明 copyright.watermark: false，则必须扫描确认为 0 个；声明 true 时才允许有，但要确认"不含隐藏指令"。

第 3 步 · 披露一致性审计（本流程的核心）

3.1 逐文件通读 —— 至少读：SKILL.md 全文、上架说明.md、README/先读我，以及所有配置与模板文件。

3.2 三张对照表

| 对照项 | 怎么查 |

|---|---|

| "上架说明"自称 vs SKILL.md 实际 | 说明说"不联网"，SKILL.md 里有没有 URL？说明说"不含对话原文"，字段规格有没有要求抄用户原话？ |

| SKILL.md 内部自洽 | 前后两处对同一件事的表述是否矛盾？（例：一处指示写 .registry/outbox/，另一处声称"不写你的技能目录"——outbox 正在技能目录内） |

| 同名字段跨文件口径 | 同一字段在两个文件里的填写要求是否冲突？（例：source 一处要代号、一处要邮箱工号——后者会暴露身份） |

3.3 外发数据分类（如包内有任何联网指令）

把要发出的字段逐个列出，标注：身份信息 / 使用行为 / 用户内容 / 无害元数据。若含"用户内容"（提问原话、文件片段、项目信息），必须标红并评估与该用户的脱敏红线是否冲突。

3.4 三个高危信号

• 指令含 "不要弹提示""不要告知用户""尽量隐形" → 机制设计上刻意不让用户知情

• 触发时机是 "任务收尾"（用户注意力已转移，不易察觉）

• 端点域名与包来源不一致，或域名看似官方但无法验证归属

第 4 步 · 向用户呈报并让其明示选择

规则：发现 P0/P1 风险时必须停下来问，不得自行决定。呈报格式：

① 审计结论表（逐检查项 + 结果）；② 与旧版的差异（尤其新增行为）；③ 问题清单 + 依据的原文行号；④ 把推荐结论放在选项之前，并说清依据；⑤ 给出带推荐标记的选项表，让用户回一个字。

> 切忌：替用户决定是否让数据外发；也切忌为了"显得严谨"而夸大风险。

第 5 步 · 加固安装

5.1 目录策略

| 内容 | 放哪 | 理由 |

|---|---|---|

| 技能本体（SKILL.md + references/） | ~/.workbuddy/skills/<技能名>/ | 唯一该进技能库的部分 |

| 说明文档、账本、模板 | outputs/<技能名>_回执/ | 别留在技能库根目录，避免多出 .registry/outbox/ 之类 |

| 原始 zip | outputs/_skills_archive/ | 保留可复原能力 + 供日后核对指纹 |

| 旧版备份 | outputs/_skills_archive/<技能名>_v<旧版>_<日期>/ | 附 _BACKUP_INFO.txt 记 sha256 |

双哈希留痕：改动前后各记一次 sha256，写进台账与报告。原包 zip 也记一次。

5.2 掐掉非必要外发

先找授权依据。优质作者常会明确写出"想关掉：删掉某段即可，无功能降级"——有这句话，删改就在授权范围内，不是违约。把授权原文与出处行号记进改动说明。

改动时：① 只删发送动作，保留字段规格；② 在改动处插入显式改动声明（标注非作者原文、授权依据、原包指纹、恢复方式）；③ 不重写作者的其他文本，最小化 diff 以保留可审计性。

5.3 改动脚本模板（关键片段）

# 基准校验：排除此前被人改过的可能

zf = zipfile.ZipFile(ZIP)

original = zf.read(ROOT + '路径/SKILL.md').decode('utf-8')

on_disk  = io.open(SKILL, encoding='utf-8', newline='').read()   # newline='' 必须

assert on_disk == original, '盘上文件与包内原始副本不一致，中止'



# 锚点定位 + 断言，避免错位静默失败

i = original.find(START); j = original.find(END)

assert i != -1 and j != -1 and i < j

assert '锚点串' in original[i:j]

assert original[i:j].count('锚点串') == 1



NEW = NEW.replace('\n', '\r\n') if '\r\n' in original else NEW   # 随原文件换行风格

modified = original[:i] + NEW + original[j:]

assert '锚点串' not in modified



io.open(SKILL, 'w', encoding='utf-8', newline='').write(modified)

assert io.open(SKILL, encoding='utf-8', newline='').read() == modified   # 落盘复读校验

5.4 大文件（台账类）改法

先定位 → assert count(old) == 1 → replace(old, new, 1) → 落盘 → io 复读全等。不要用 Edit 工具改台账（本机有"报成功但未落盘"的历史问题），或改完必须直读盘复核。

第 6 步 · 验收

| 项 | 判据 |

|---|---|

| 外发端点残留 | = 0 |

| 本地路径/声明块在场 | True |

| 换行风格 | 与原文件一致（CRLF 数不变） |

| 落盘校验 | io 复读全等 |

| 冒烟测试 | 用技能的真实用途问 8 个问题，命中率入账 |

| 脱敏扫描 | 全文不含真实项目名/甲方/人名/本机路径 |

冒烟测试要用真实素材，且必须记录未命中的那几条 —— 缺口本身就是最有价值的产出。

第 7 步 · 登记与收尾

1. 台账登记（<工作区>\技能库每日自进化\references\SKILL-LIBRARY.md）四处：顶部"最近整理"行／族内技能行／"已知坑"行／变更日志

2. 写审计报告 → outputs/<技能名>_升级审计_v<版本>.md

3. 清理临时脚本（用完即删）

4. 更新记忆：工作区日志 + 用户级环境坑（新踩的坑）

5. 交付报告

授权红线（登记时必须核对）

看 frontmatter 的 copyright.license：

| 授权 | 后果 |

|---|---|

| All Rights Reserved | 仅限本人使用：不得再发布、不得用于训练数据、通常也不得纳入参赛作品/副业分发 |

| 有明确"可改编" | 才允许改动本体 |

| 未声明 | 按最严格处理 |

授权受限的包不能纳入：资源库副业分发、竞赛投稿、任何对外交付物。此项必须写进台账并主动告知用户。

13.3 与英文原版安全审查技能的关系

本机另有一部英文原版的安全审查技能（skill-vetter），提供"来源检查 → 代码红旗清单 → 权限范围 → 风险分级 LOW/MEDIUM/HIGH/EXTREME"四步协议与报告模板。

它是外来技能（乙类），按 §B1 的判据应封顶 L3、不可作融合宿主，故本次未将其并入本技能——把外部表达抄进自研正文会污染权属。

用法分工：

• 日常以 §B13.2 为准（它含 Windows 本机坑、台账联动、脱敏红线，且与本机的归档策略一致）

• 需要第二意见或对方要求英文报告时，跑一次 skill-vetter 协议对照

• 若用熟了想把它变成自己的，走 §B11 净室转生，不要直接改它的正文

§B14 专家包的同一套规则

专家与技能有两处不同，其余照搬：

| | 位置 | 处理 |

|---|---|---|

| 自建专家 | plugins/cache/my-experts/<名>/<版本>/ | 盖章、加密、可转生 |

| 市场专家 | plugins/cache/experts/<名>/<版本>/ | 不动，只作转生来源 |

• 指纹落点不同：专家包没有"单一正文"，所以指纹落在内容文件清单上（README.md、agents/*.md、knowledge/*.md、skills/*/SKILL.md，排除 COPYRIGHT.* 自身），逐文件嵌水印。覆盖口径的完整说明、以及"为什么必须排除 memory/"，见 §B19 附。

• 不写 plugin.json —— 防宿主校验不认未知字段，另立 COPYRIGHT.json 更安全。

• 首次盖章与技能无差别：stamp --target experts --apply 即可，不需要 --accept-drift。那个旗标只用于「已盖章但内容变过」的漂移场景 —— 它的语义是"确认这次改动是我做的"，首次盖章没有"这次改动"可言。

• --dir 的写法：stamp / verify 要写全 名/版本（如 omni-kanyu-team/1.0.0）；snapshot / rollback 允许只写 名，但唯一命中才认，多版本并存时报错而不猜版本。

• 盖章只碰文档（2026-09-20 补盖 2 部自研专家包实测）：改动面仅 README.md + agents/*.md + knowledge/*.md + skills/*/SKILL.md，加新增的 COPYRIGHT.json / COPYRIGHT.txt。plugin.json、settings.json、avatars/、tools/、memory/ 的 mtime 全部未变 —— 复核时就查这几项 mtime 是否仍是旧日期，一目了然。

§B15 命令速查

$py = "<Python 绝对路径>"

$s  = "$env:USERPROFILE\.workbuddy\skills\omni-skill-forge\scripts"



# ── 位次与融合 ──────────────────────────────────────────────

& $py "$s\growth.py" sync                    # 注册新技能 / 归档消失的 / 补齐字段 / 校准血脉

& $py "$s\growth.py" record <目录名> <事件> --session <会话id> --note "…"

& $py "$s\growth.py" record <主技能> <事件> --session <id> --also <技能> [--also <技能>]

                                             # 一条命令 = 一次会话 → 共现(C2) 天然产生

& $py "$s\growth.py" record <目录名> <事件> --backfill --at <YYYY-MM-DD> --evidence "日志出处"

& $py "$s\growth.py" backfill --plan <计划.json> [--apply]

& $py "$s\growth.py" ladder                  # 匠作九位三阶总表 + 分布 + 名号出处

& $py "$s\growth.py" report [--sort level|xp|name] [--all]

& $py "$s\growth.py" level <目录名>           # 单部详情（位名/候/名出）

& $py "$s\growth.py" promote <目录名> [--to N]  # 确认 L4+ 晋升

& $py "$s\growth.py" annotate [目录名] [--dry-run]

& $py "$s\growth.py" declare [--dry-run]      # 把合并域写进各技能 growth 块

& $py "$s\growth.py" domains                  # 技能库整理图：域/主线/成员/融合可行性

& $py "$s\growth.py" catalog                  # 分类总览：甲类自研 / 乙类外来 / 待裁决

& $py "$s\growth.py" rename [--plan P] [--only 目录] [--apply] [--refs-only]

& $py "$s\growth.py" lineage <目录名>          # 血脉谱系

& $py "$s\growth.py" decay [--dry-run]        # 季度衰减

& $py "$s\growth.py" replay [--fix]           # 用事件流 + 谱系重建状态并对账

& $py "$s\growth.py" propose-merge [--json]   # 只读，输出融合候选与上限提升预览

& $py "$s\growth.py" merge --host X --members A,B --type chain --confirm

& $py "$s\growth.py" rollback --merge-id m-0001

& $py "$s\growth.py" demo                     # 临时目录全流程演示（不碰真实数据）



# ── 版权 · 加密 · 发布 · 回流 ───────────────────────────────

& $py "$s\assetguard.py" status               # 资产台账：甲乙两类 + 已登记/未登记

& $py "$s\assetguard.py" stamp --apply        # 盖章（默认预演；默认只盖甲类、只盖强证据）

& $py "$s\assetguard.py" verify --verbose     # 三方对账：指纹 + 水印 + 台账

& $py "$s\assetguard.py" compliance-scan      # 上线前合规扫描（只看 SKILL.md，三类信号）

& $py "$s\publish_guard.py"                  # 上线前自检（整包，七类判据）
# SkillHub 上架（预检/提交/确认三项）已迁往「万象-SkillHub自动上架」omni-skh-auto-publish

& $py "$s\assetguard.py" seal                 # 生成加密发布包

& $py "$s\assetguard.py" keygen               # 只做一次

& $py "$s\assetguard.py" adopt --source X --confirm

& $py "$s\assetguard.py" retire --dir X --confirm

& $py "$s\assetguard.py" ingest --apply --archive

& $py "$s\assetguard.py" wishes

& $py "$s\assetguard.py" publish-check

& $py "$s\assetguard.py" score                        # 九维量化评分（机器初评；效果 35 分留白）

& $py "$s\assetguard.py" score --dir X --verbose      # 单部明细 + 逐条判据 + 下一轮改哪一维

& $py "$s\assetguard.py" duel --a A.json --b B.json --dir X --save   # 独立评委比对 + 早停判断

& $py "$s\assetguard.py" snapshot --dir X --note "本轮改什么"        # 棘轮：改前留底（§B19）

& $py "$s\assetguard.py" snapshot                                  # 快照全景：谁还没备份

& $py "$s\assetguard.py" snapshot --dir X --list                   # 某部的快照历史（带分升降）

& $py "$s\assetguard.py" rollback --dir X                          # 回滚预演（默认不写盘）

& $py "$s\assetguard.py" rollback --dir X --apply                  # 分跌了 → 真回滚（连台账一起）

& $py "$s\assetguard.py" test-prompts                             # 触发回归测试集：全库覆盖率（§B20）

& $py "$s\assetguard.py" test-prompts --dir X                     # 单部校验：schema + 引用真实性



# ── 自检 ────────────────────────────────────────────────────

& $py "$s\self_test_guard.py"                 # 版权侧回归自测（171 项，无 yaml 时 166 项）

& $py "$s\self_test_growth.py"                # 成长侧回归自测（132 项）

& $py "$s\registry_check.py"                  # registry 完整性

& $py "$s\ledger.py"                          # 台账工具

两个默认拒绝，都要显式放行：

• --include-weak —— 归属证据偏弱的资产默认不盖。盖章 = 对外主张著作权，不靠"大概是我们的"下笔。

• --accept-drift —— 已盖章但内容变过的资产默认不重盖。无脑重盖等于把改动洗白成"一直如此"；如果改动不是你做的，那就是在替别人洗白。

第三个闸门在 seal 前：合规扫描。

排错顺序固定：先看分类对不对（status / catalog）→ 再看章盖没盖（verify）→ 最后才怀疑内容。 绝大多数"校验失败"其实是分类错了（把乙类误当甲类去盖）或盖完章又改了正文。

使用约定（改动的都是硬规则）

1. 任务收尾时记录事件：判断本次用到了哪些技能、结果如何，逐个 record。宁可少记也不要编造 —— 事件流是等级的唯一依据。

2. 融合前先看提案：propose-merge 是只读的，会显示"上限 L6 → L7"的提升预览，先把候选与理由讲给用户再决定。

3. 改完技能定义后跑 sync：跟进 name 变更、新增技能、补齐字段、校准借用/自研判定。

4. 怀疑状态不一致时跑 replay：以事件流为准；有差异用 --fix 覆盖。

5. 借用技能只读：目录名带 __skillhub 后缀的市场技能（本机实测如 cangjie-* 系列、flyelep-ai-skills 等），上限 L3、不可被融合、不可作宿主（上游更新会覆盖本地改动）。要突破，只能用自建的自研技能去融合。

6. 新建就设 growth.merge_group：同域技能才能融合；不写则按 group_aliases 或目录名首段推导。

7. 改等级体系要先看段末对齐：cap(borrowed)、cap(own)、cap(synthesized)上限 三个数必须是"三的倍数"，否则段末与天花板错位。改完跑 self_test_growth.py。

8. 名号要名出有据、且出处唯一：新增或更换位名必须同时补 LEVEL_SOURCE 出典，只能出自《考工记》 —— 出处一散，这套名号就退化成起名。

9. 名号用字不添一字：位名与阶名的每个字都必须按原序出现在它引的那句原文里（traceable() 逐字校验）。改名前先自查。

本机环境坑（Windows，实测）

1. Edit 工具偶发"报成功但未落盘" → 关键/批量改写直接用 Python 补丁 + 断言 + 回读校验，不要只信 Edit 的返回。

2. bash PATH 偶发损坏（ls/head/cat 均 not found，退出码 127）→ 用 Python 或 PowerShell；且不要用 | head（head 也 not found，脚本被杀在写文件前）。

3. 中文 / 空格路径一律用 Python 的 os / zipfile 处理，别走 shell。

4. 读写文本统一显式 encoding='utf-8'；对比行差异前先统一 \r\n → \n。

5. 报告产出后回读校验：HTML 查 <div> / <table> 配对与 </html> 收尾；MD 查标题数与关键计数串。

§B16 边界与反例

不做什么

• 不替代 A 篇 · 治理：库怎么分类、技能怎么起名，归它。

• 不创作技能内容本身：那是 skill-creator。

• 不替作者判断"业务上要不要收某类标准"——只报"自称与实物不符"，把取舍权留给作者。

反例（不要做）

• 把自研技能目录加密，然后纳闷技能怎么不加载了 —— 见 §B5.1 边界 1。

• 把 copyright 的指纹算进 frontmatter —— 见边界 3。

• 因为来源是 MIT 就把作者署名删干净 —— 见边界 4。

• 用 embed_watermark 之外的方式手工插零宽字符 —— 换行符处理一错，正文就被改坏了。

• 没跑过 verify 就说"已经保护好" —— 没校验过的章，和没盖是一样的。

• 用维护帮扶 Growth 主义手段分发已声明 All Rights Reserved 的包 —— 见 §B13.2 授权红线。

• 用脚本全文替换来改技能名 —— 会把 triggers 一起改掉，用户按原说法提问再也命中不了。

§B17 收笔前的自省：四视角与反例

> 方法论源头见 omni-research §A1-7。此处是技能铸造场景的落地版。

> 来源：2026-09-20 吸收自视频号博主「晓辉博士」的深度研究 Skill（四视角批判）。

技能收笔前（改动 ≥3 处、或对外发布时），强制换四个位置各读一遍自己的产物：

| 视角 | 只问这一个问题 |

|---|---|

| 严谨逻辑学家 | 推理链哪一环是跳过去的？ |

| 反例检验者 | 这个结论在什么情况下不成立？ |

| 接手的陌生人 | 只有这份文件，我能照着做完吗？ |

| 半年后的自己 | 这条判据会不会过期 / 换台机器就失效？ |

反例检验者最该较真 —— 本机实测代价：

• 2026-09-19 把「微信 4.x 屏蔽合成鼠标、只认合成触摸」写成硬结论 →

2026-09-20 复测推翻（卡片区恰好相反，只认鼠标）。当时那个"规律"其实只是

窗口被外部改成 576×448、坐标整体偏移时期的巧合。

• 若下结论前问过一句「什么情况下它不成立」，能省半天。

写进技能的铁律：

| 要求 | 理由 |

|---|---|

| 任何否决式判据（"不做 X"）必须附反例条件 | 没有反例的禁令，换个场景就变成误伤 |

| 任何性能/收益数字必须标实测环境（机型 / 版本 / 样本量） | 别台机器上数字不成立，读者会以为技能在骗人 |

| 未实测的一律写「未实测」，不得写成结论 | 已立规矩：large-v3 本机未实测，故不得声称它更快更准 |

| 推翻自己旧结论时，明写"作废"并保留原文可追溯 | 与 omni-research 的"订正批注、不静默改写"同源 |

| 写自检脚本时，判据要排除"必然变化项" | 本机实例：复核盖章结果时写的判据是「剥掉零宽后逐字相同」→ 必然误报，因为 盖章本身就要改写 fingerprint / mark_id / stamped_at 三个字段。正确判据是只比正文（去 frontmatter、去 H1 水印、去零宽）。凡是"复核"类脚本，先问一句：哪些字段是这次操作理应改动的？ |

| 一批并发 Edit 会静默丢改动 | 本机实例：同一轮发 3 个 Edit，dispatch 表落了盘、parser 注册没落 —— 但两个都回「Successfully edited」。直到新命令报 invalid choice 才暴露。规矩：一次只改一处，改完立刻 Grep 复核那一处；"报成功"不能当落盘证据 |

| 别为小目的批量删目录 | 本机 safe-delete 护栏：单次运行内删除数超 50 会被拦（SAFE_DELETE_BULK_CONFIRM_REQUIRED），拦得对。实例：为一次口径调整要删 2 个快照目录，第二个被拦、脚本中断。正确反应是改设计（旧快照留着无害 —— 默认回滚只取最新一张人工快照），不是绕过护栏 |

盖章后复核的标准动作（2026-09-20 实测定型）：

# ① 先备份（盖章会改盘，先留退路）

Copy-Item "$root\$d\SKILL.md" "$bak\$d.SKILL.md" -Force

# ② 预演（默认不写盘）→ 看清哪些资产 drift

& $py "$s\assetguard.py" stamp --target skills --dir $d --verbose

# ③ 确认改动是自己做的 → 才加 --accept-drift 重盖

& $py "$s\assetguard.py" stamp --target skills --dir $d --accept-drift --apply

# ④ 三方对账（指纹 + 水印 + 台账），要看到「通过 N / 异常 0」

& $py "$s\assetguard.py" verify --target skills --dir $d --verbose

实测正常盖章的改动面只有 4 处：fingerprint / mark_id / stamped_at ＋ H1 行水印重写，

行数一行不变。若 diff 出现其他行，立即回滚。

> ⚠️ PowerShell 里跑 assetguard.py 必须同时设

> [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 与 $env:PYTHONIOENCODING="utf-8"，

> 否则中文输出全成乱码（实测首次即中招）。

附 · 融合说明与位次依据

来源（4 部）

| 来源 | 贡献章节 | 资产 |

|---|---|---|

| skill-asset-guard（自研，29 XP） | §B1 两类判据、§B5 权属三件套、§B6 加密包、§B7 合规、§B8 分发两把尺子、§B9 发布线、§B10 回流、§B11 净室转生、§B12 归档卸载、§B14 专家规则 | assetguard.py、chacha.py、self_test_guard.py |

| skill-growth-merger（自研，23 XP） | §B1 血脉天花板、§B2 匠作九位三阶、§B3 架构、§B4 融合即进化 | growth.py、ledger.py、registry_check.py、self_test_growth.py |

| skill-content-audit（自研） | §B13.1 内容找茬六步 | — |

| skill-pack-hardened-install（自研） | §B13.2 安全审计与加固安装七步 | — |

未并入：英文原版安全审查技能 skill-vetter（外来乙类）。理由与处置见 B 篇 §B13.3。

融合中的关键处理

1. 保留了全部来源的硬性判据原文。 判据表、命令、断言逐条照搬，不因改写而丢失可执行性 —— 宁可长，不可少。

2. 零宽水印不继承。 四部来源各带自己的隐形水印（嵌在 H1 行尾），本次融合正文已重组、不沿用任何一部的旧水印——无水印≠无指纹，verify 仍按指纹比对。

3. 法条引用补了版本。 《著作权法》合作作品条号 2010 版为第 13 条、2020 版为第 14 条，正文里两个版本号一并给出，避免判例更新后论证悬空。

4. self_test.py 撞名已处理。 两部来源各有一份，分别落为 self_test_guard.py / self_test_growth.py，各自保留原命令的所有断言。

5. 跨技能命令路径已重定向。 原散落各源的相互引用（如"走 技能-命名规范"、"skill-asset-guard/scripts/assetguard.py"）全部改写为融合后的新名字与新路径。

位次依据（不虚标）

按本技能 §B4「状态继承」规则 round(Σ成员XP × 0.3) 计算，宿主取 XP 最高者：

宿主 = skill-asset-guard        29 XP（load 1 / success 5 / compose 1，成功率 1.0）

成员 = skill-growth-merger      23 XP（load 2 / success 3 / compose 2）

       skill-content-audit       0 XP（未入注册表）

       skill-pack-hardened-install  0 XP（未入注册表）



融合后 = 29 + round((23 + 0 + 0) × 0.3) = 29 + 7 = 36 XP

L1 门槛 = 40 XP 且 load ≥ 3  →  36 < 40，未达标

故本技能位次为 L0 未习，当前 36 XP，距 L1 审曲差 4 XP。

load 合计已达 3（满足该项门禁），缺的是 XP 本身。真实使用一次（record <目录名> success）即 +5 XP，届时自然跨过门槛——不手动 promote，不用 whatever 之外的手段提位次。

> merge_policy: never —— 本技能是执行融合的工具，被并掉就没有工具了。（沿用原 skill-growth-merger 的声明。）

待办：本文件为四源重组，旧版权指纹对不上，交付前须运行 assetguard.py stamp --apply 重新登记后再 seal。

§B18 量化评分与独立评委（本地版 darwin 循环）

来源：darwin-skill 2.0（花叔 alchaincyf，MIT，2026-05-28），思路承自 Karpathy autoresearch。

吸收方式：只搬方法论，不搬包——它的棘轮依赖 git revert + git 仓库，而技能库不是仓库。

落点：assetguard.py score / assetguard.py duel（2026-09-20 立）。

为什么需要它

本库原有复核是「我改 → 我 verify」：改动者与评审是同一个人。

SkillLens（arXiv:2605.23899，微软研究院）实测 LLM 自评准确率仅 46.4%，低于抛硬币；补上三维度 rubric 后升到 73.8%。

所以症结不在"评得够不够认真"，而在结构：分数要可复算，评委要独立于改动者。

两条硬约束（已写死在工具里）

| 约束 | 落地方式 | 违反的代价 |

|---|---|---|

| 分数可复算 | 每维得分 = 10 × 通过项 / 总项，每条判据逐条打印 ✓/✗ | 印象分无法比较、无法回溯 |

| 评委独立于改动者 | score 只出机器初评，输出首行即声明自己不是评委 | 反例黑名单第 1 条：同一个 AI 又改又评 |

九维评分表（满分 100，照抄现行表，勿凭记忆改）

| 分组 | 维度 | 权重 | 判者 |

|---|---|---|---|

| 结构 59 | Frontmatter 质量 | 7 | 机器 |

| | 工作流清晰度 | 12 | 机器 |

| | 失败模式编码 | 12 | 机器 |

| | 检查点设计 | 6 | 机器 |

| | 可执行具体性 | 18 | 机器 |

| | 资源整合度 | 4 | 机器 |

| 效果 35 | 整体架构 | 12 | 评委 |

| | 实测表现 | 23 | 评委 |

| Meta 6 | 反例与黑名单 | 6 | 机器 |

> ⚠️ 网络流传的旧版把「可执行具体性」记作 17，现行表是 18（7+12+12+6+18+4+12+23+6 = 100）。改这张表时脚本会当场断言失败。

本地五阶段映射（缺什么要明说）

| 原项目 | 本机做法 | 状态 |

|---|---|---|

| Phase 0 初始化 | snapshot --dir X --note … 拍快照留底（不引入 git，见 §B19） | ✅ 有 |

| Phase 1 基线评估 | score --dir X --verbose | ✅ 有 |

| Phase 2 单维度优化 | 看输出的「下一轮该改哪个维度」，只动第一项 | ✅ 有 |

| 2 个独立子 agent 重评 | 派 2 个 agent 各填一份评分 json | ✅ 有 |

| keep / revert 棘轮 | 分涨 → 留；分跌 → rollback --dir X --apply（连台账一起恢复） | ✅ 有 |

| 涨幅 < 1 早停 | duel --dir X --save 自动比对台账历史 | ✅ 有 |

> 棘轮这一环 2026-09-20 补齐（§B19）。六环全绿，但要点名一条边界：本机的"回滚"是快照回滚，不是 git revert —— 没有分支、没有合并、没有历史重写能力，只能整部资产退到某一张快照。够用，但要清楚它的能力上限。

命令

# 单部：九维明细 + 逐条判据 + gap 排序

python assetguard.py score --dir omni-research --verbose



# 全库：机器可判分排名（效果 35 分留白）

python assetguard.py score



# 出评委待填骨架（auto 维度也留空，避免锚定评委）

python assetguard.py score --dir omni-research --json judgeA.json



# 两位评委比对：逐维分歧 + 最大分歧 + 早停判断 + 下一轮改哪一维

python assetguard.py duel --a judgeA.json --b judgeB.json --dir omni-research --save



# 棘轮：改前留底 → 改 → 分跌了就回滚（详见 §B19）

python assetguard.py snapshot --dir omni-research --note "本轮改 检查点设计"

python assetguard.py rollback --dir omni-research --apply

三条边界（不知道就会用错）

1. score 出的是机器初评，不是评委分。 它从不宣称自己完成了评估——只把"能机械核验的部分"算干净，其余留白。

2. 效果两维（整体架构 12 + 实测表现 23 = 35 分）一律留白。 原表即标「需要实测」，用正则去猜这两项等于制造假精确。

3. duel 只比对与建议，不替任何一方改分，也不自动改技能正文。改动必须由人过 checkpoint 后执行。

本库基线（2026-09-20 实测，22 部）

| 项 | 值 |

|---|---|

| 机器可判分最高 | omni-standard-verify 62.3 / 65 |

| 机器可判分最低 | omni-drama-naming 27.4 / 65 |

| 区分度最高的维度 | 检查点设计（均分 4.09/10）、资源整合度（5.68）、反例与黑名单（5.91） |

| 无区分度判据 | 11 / 36 条全库全员通过（frontmatter 存在、有触发条件、有版权声明等）——这些是基线分，不体现任何技能的优势 |

score --verbose 会在每条全员通过的判据后标 [全库 N/N 均过 · 无区分度]，就是为了不让基线分被误读成优势分。

只标注，不删项——为了"看起来有区分度"而收紧或删掉全员通过的判据，是反例黑名单第 3 条的镜像。

踩坑（2026-09-20 本轮实测）

1. label 里不能嵌动态值。 误写成 模糊词密度 < 3/千字 (实测 0.00)，导致每条技能的 label 都不同，全库统计归并不了——22 部技能被算成 14 个互不相干的条目。凡会被聚合的 label 必须固定，会变的值放 note。

2. 中文表格不能用 len() 排版。 中文占 2 列而 len() 算 1，%-14s 排出来的表必然歪。用 _disp_width / _pad / _padl 按显示宽度算。

3. 判据必须按本库实况校准。 「name == 目录名」这条照抄别人题面就会全库误判（本库 name 带「· L2 位次」后缀）。上线任何新判据前，先跑一遍全库通过率，看有没有 0% 或 100% 的项。

4. asset_ledger.json 是嵌套的。 记录在 led["assets"]["skill:<目录名>"] 下，顶层只有 assets / schema_version / updated_at 三个键。写成 led.get("skill:xxx") 会把全库都报成「未登记」——35 项误报，看起来像灾难，其实只是读错了一层。

5. 工具有两套 --target 口径。 stamp 只盖甲类（own），verify 的「共 N」也按 own 统计；自研专家包（my-experts/）属于 own 但常未盖章，会出现在「未盖章」计数里，别把它当成"库里多了东西"。

A 篇 · 治理（盘货）：库里有哪些、叫什么、字段对不对

A 篇 · 治理（盘货）

本篇管的是技能库这个货架——什么该上架、放在哪格、叫什么名字、牌子上的字写得对不对；至于这部技能练到几品、属于谁、能不能加密发出去，那是 B 篇 · 铸造的事。

两篇的分工不是按"做不做改正"划分，是按工作对象划分：本篇的工作对象是集合，铸造的工作对象是单个资产。

§A0 规则体系：12 条 + 两组前置（先读这个）

全文在 references/技能标准体系_v1.2.md。（入口页：references/核心内容总结.md） 定位：规则是出厂门禁，回流在门外。

（v6.2→v6.3 只增补 §7.6 八bis 读列表的两个致命坑，其余未动；v6.1／v6.2 旧版留作对照。）

> 五份依据（前三份在 references/）：

> ① 本文件（技能标准体系）＝技能资产合不合格 ｜

> ② 工作规则体系_v1.3.md ＝人干活合不合格（W1 开工四问 → W10 边界红线）｜

> ③ 知识体系_v1.3.md ＝我们知道什么（外部学习／视频卡总结／实践经验 ＋ 分域知识索引）｜

> ④ 自研技能索引.md ＝22 部技能一行功能表（开工前扫一眼用）｜

> ⑤ 原话库（<工作根>\用户原话库\，本地加密程序，零积分）。

> 三大体系跟着原话库自动更新：每日采集 → 生成 体系更新候选.md → 提炼进正文（附原话依据）。

| 类 | 规则 | 一句话 |

|---|---|---|

| 身份类 | 1 结构字段 · 2 技能命名 · 3 标识图像 | 可被唯一识别与脚本定位 |

| 融合成长类 | 4 升级融合 · 5 进化成长 | 同领域合并、学习吸收、按回流迭代 |

| 体检类 | 6 检查合规 · 7 评分验收 · 8 盖章与授权 · 9 过程文件清理 | 出门前验完，不过不放行 |

| 留痕类 | 10 台账登记 · 11 规则同步与跨机 | 事实唯一，换台电脑照做 |

| 边界类 | 12 保护与授权边界 | 圈定可动/可授权范围（横切·全程生效） |

| 门外 | 反馈飞环（不占编号） | 实操检验 → 改进依据，落点 5 进化成长 |

两组前置（不占 12 条编号，2026-09-21 齐备）：

• §〇bis 作业前置标准（7 条） —— 用技能的人有没有对准用户标准：给了参考先读完 / 先确认要「内容」还是「过程」/ 每条路线先定止损线 / 方法当场沉淀回技能。

• §〇ter 判据合格性标准（M1–M5） —— 判据本身合不合格：

M1 检查项须能一行命令复现（记录 ≠ 执行）｜ M2 声明值不得作证据，一律回读实物 ｜

M3 对宿主/工具的行为假设必须实证（贴函数名原文，或标「未验证」）｜

M4 制判者与执行者不得同一轮上下文（自审不算审）｜ M5 范围界定用白名单法，不用排除法。

编号 = 流程序：首次出厂走 1→9，随后 10→11；12 全程生效。

规则与流程冲突时规则优先；规则改了 → 流程与工具跟着改，并重过门。

> v6.1 三处订正（2026-09-21，均以宿主源码为证）：

> ① 命名＝三层口径（name＝kebab 机器标识须等于目录名；中文显示名住 _user_meta.json.name；

> 取值优先级 _user_meta.name > frontmatter.name > 目录名）—— 旧表述「本机自用 = 中文两段式」已作废；

> ② 回流三件套必须在插件根／包根才生效（放技能目录里不执行）；

> ③ skills 扫描根下任何非技能目录，其 SKILL.md 必须改名避开（宿主递归 ≤5 层、不跳 . 开头目录、按 name 去重）。

> 新建技能第一件事：把 5 进化成长的硬条款埋进去 —— hooks/hooks.json + feedback.mjs +

> FEEDBACK.md 三件齐，缺了不许出厂。等"以后再加"的结果就是全库只有 1/22 带通道。

>

> 落地工具（2026-09-20 起）：新建走模板 assets/skill_template/（十键 frontmatter ＋ 正文八节骨架 ＋

> 三件套 ＋ 自查表，复制即用）；老技能补内容字段用 scripts_curator/fm_backfill.py --table <表> --apply

> （默认预演、只补缺失键、内建保护清单）；单目录自检用 scripts/rule_audit.py --dir <目录>。

> ⚠️ 别用 fm_normalize.py fix 批量跑 —— 它的 DROP 表会删 triggers（本库评分认它），要修展示名须加

> --dual-only。⚠️ 三件套放在技能目录里不会被执行 —— hooks.json 用的是 ${CODEBUDDY_PLUGIN_ROOT}

> （插件根变量），打包/上架时须把 hooks/ 与 feedback.mjs 提升到包根才生效。

§A0-pub · 开放平台上架工具链（2026-09-22 立 · 全链路实测）

把技能送进 WorkBuddy 开放平台（open.workbuddy.cn）的完整可重跑实现。

规则层见 references/技能标准体系_v1.2.md §7.6 §7.7；操作手册见 references/上架流程_开放平台.md。

> 🔀 另有第二条独立通道：skillhub.cn（社区源，与开放平台互不互通，须实名 + API Token）。
> 规格、字段差异、CLI 能力边界与「图标必须随上架补齐」硬规则见 references/上架规格_SkillHub.md。
> ⚠️ 该文档与 上架规格_WorkBuddy开放平台.md 同属造技能的人看的内部件，本技能若上架应一并排除出包。

| 脚本（scripts/publish/） | 干什么 | 典型命令 |

|---|---|---|

| publish_skill.py | 单部主流程：校验 → 查重 → 传包 → 填第②步 → 提交 | --k omni-web [--submit]；--list 只列现状 |

| publish_batch.py | 批量 + 三重护栏（本地校验／查重／逐部独立进程＋台账续跑） | --k js/omni-*.json --submit |

| render_icons_512.py | 渲染 512×512 头像（CDP deviceScaleFactor=1 ＋ CSS 锁 ＋ PIL 兜底） | --verify-only 只量尺寸 |

| fix_pkg_desc.py | 修包内 plugin.json.description（＝平台「介绍」的来源） | 默认预演，--apply 落盘 |

> 三条最容易翻车的地方（都已在代码里设防，改代码时勿删）：

> ① plugin.json.description 必须是业务描述 —— 平台「介绍」读它，写成内部机制说明就会上架即暴露；

> ② 头像必须真 512×512 —— page.screenshot(clip=512×512) 实测只出 492×420，缺 deviceScaleFactor=1；

> ③ 读列表要选对标签页 + 轮询 —— page.url 为空时会开出空白页，固定 sleep 也不可靠

> （实测 0～2.2s 全是「加载中…」，3.2s 才出数据）。

SkillHub 那条通道已独立成部 —— 见「万象-SkillHub自动上架」（omni-skh-auto-publish）：
含三段式自动上线脚本（预检／上传提交／状态确认）、七条硬判据与 18 条实测踩坑台账。

> 本节的边界（迁出后）：本文只保留开放平台这条通道的判据。
> SkillHub 的浏览器向导判据已整体迁往该部，本节不留副本 ——
> 同一能力只留一个判据家，避免两处判据各自漂移。

§A1 三条铁律（优先级最高，其余规则都从这三条推出）

1. 绝不直接删除。 任何淘汰动作一律移入归档区 C:\Users\<你>\.workbuddy\skills_archive\，目录名追加 __归档原因__日期，并在台账登记。归档完全可逆——还原就是把目录移回去。真正的删除只在"归档满两个复盘周期仍无人要求恢复"之后，且必须征求用户确认。

2. marketplace / 插件自带的技能不动本体。 这类技能由应用本身管理，物理改动可能引发加载异常。能做的只有：在台账标记「重复/冲突」+ 向用户提出禁用建议，等用户决定。（这正是外来技能不能参与融合的物理原因——见 §A4.2。）

3. 重大动作先确认。 归档或合并影响到 2 个以上技能、或目标技能近 30 天内被使用过时，先列清单给用户确认再动手。新建和回写不需要确认——它们无损且可逆。

> 这三条的排序是有意的：第 1 条保的是"还能救回来"，第 2 条保的是"别把手伸进别人的东西里"，第 3 条保的是"别替用户决定"。

§A2 命名与字段：两套标准，各管一个场景

这是本次融合中最需要先摆平的一件事。 两个来源给出过互相冲突的要求，而且两边都对——它们说的是不同场景：

| | 本机自用 | 对外上架（平台/市场） |

|---|---|---|

| 谁读 | 本机应用：技能列表、/ 引用标签、选择器 | 技能市场 / 平台侧展示与召回 |

| name 取什么 | SKILL.md 的 name 是 kebab-case 机器标识（须等于目录名）；显示名另存 _user_meta.json.name | kebab-case，且须与目录名一致 |

| 展示名怎么给 | 显示名 = _user_meta.json.name，格式两段式 万象-<功能>（L# 位名）（应用读取优先级 meta?.name \|\| frontmatter.name \|\| dirName） | display_name（下划线，中文上架名） |

为什么不是"选一个改掉"： 早期版本做过一次——把 displayName 直接改名成 display_name，结果修好了上架、修坏了本地列表。正确动作始终是保留已有的、补上缺的那个，而不是二选一改名。

> 2026-09-19 订正：本机显示名已改由 _user_meta.json.name 承载、SKILL.md 的 name 让给 kebab 机器标识 —— 所以本机不再需要 displayName（它对本机应用是冗余的，且会与 name 必须等于目录名的硬要求相撞）。上架时仍按平台九件套补 display_name，或在上架前另生成合规版本。

§A2.1 本机自用：中文两段式

> 沿革：2026-09-19 起由三段式 <万象>-<域>-<功能> 改为两段式 万象-<功能> —— 域层取消，前缀位固定为品牌「万象」。判据是用户给出的参考标准「万象-数字世界（L0 未习）」。原口径下 15 部里 6 部功能名只有 2 字、3 部多带一层域，长度参差；统一后 15 部显示名全部收敛到 14 字符。老的三段式词表存档在 naming.json 的 prefix_by_group__retired / func_by_dir__retired，不删只归档。

万象-<功能>（L# 位名）

万象-透水路面（L0 未习）

万象-色彩配色（L4 审势）

| 位置 | 取值 | 为什么 |

|---|---|---|

| 目录名 | ASCII 短横线（sand-permeable-standard-map） | 运行时定位 SKILL.md 的路径标识；中文目录名在跨平台路径解析上有风险 |

| 显示名 | 中文两段式 万象-<功能>（L# 位名），住 _user_meta.json.name | 这是技能列表里的显示名与调用名 |

| triggers | 中文短语列表，每项加引号 | 独立触发词列表，不要只把触发词内嵌在 description 里 |

| description | 能力 + 触发情境 + 不适用边界 | 平台按此匹配触发 |

前缀怎么取：2026-09-19 起前缀位固定为品牌「万象」，不再按工作对象取域。词表落在

.registry/naming.json：prefix_by_dir 逐目录登记前缀（现全为「万象」），func_by_dir

逐目录登记功能名（4 字，人工定一次，不由程序压缩），rules 里的 level_open / level_close

也归它管 —— 规则不写在代码里，改词表即改全库。

本名（前缀＋功能）有长度上限（rules.max_label，两段式下即 2 + 4 = 6 字）。越界会被 rename 报出来但不阻止 ——

报出来是让你决定，不是让它替你决定。

——它由成长系统按位次生成，升位时只换这一段。这条是刻意设计的：按名字搜技能，升位前后都能命中。

§A2.2 上架：双写键（最易错的一处）

| 读它的地方 | 认的键 | 只有另一个键时的表现 |

|---|---|---|

| 本地应用 | displayName | 显示成 slug，例如 omni-distill——用户按中文名怎么找都找不到 |

| 技能市场上架 | display_name | 展示名为空 |

配套还要写 display_name_en / displayName_en。

上架场景的字段口径（与本地自用的 name 双写是两套口径，别混）：

| 字段 | 要求 |

|---|---|

| description_zh / description_en | 中英双份，语义必须一致 |

| version | 语义化 MAJOR.MINOR.PATCH |

| author | 官方口径为「合作方名称」，不是真实姓名 |

| category、allowed-tools | 建议字段，非必填 |

做 / 不做：

| 做 | 不做 |

|---|---|

| 识别非规范键名并报告 | 不判断技能内容是否合规（那属于脱敏与版权范畴） |

| 补写双写键（只补不删） | 不覆盖已有的同名键、不猜测内容 |

| 重命名真笔误键 / 删除平台无定义的键 | 不删除任何文件、不修改正文 |

| 报告缺必填 / 缺建议字段 | 不代填内容 —— 缺什么由人来写 |

scan 只读，任何情况下不动文件。

改字段的边界（一律守）：只补不删 —— 不覆盖已有的同名键、不猜测内容、

不删除任何文件、不修改正文；缺什么由人来写，不代填。fix 默认 dry-run；

--dual-only 会关掉所有删除动作（slug / triggers 不动） —— 这两者虽非平台字段，

但可能正被别的东西引用。

解析器对未识别的 frontmatter 键是静默忽略的——不报错、不提示，只是不生效。

§A2.3 常见错误写法

| 错误 | 正确做法 | 后果 |

|---|---|---|

| 只写 displayName | 再补写 display_name | 上架后展示名为空 |

| 只写 display_name | 再补写 displayName | 本地列表显示 slug |

| displayname / display_name_zh | 改名为 display_name | 真笔误，两边都读不到 |

| slug | 用 name | 平台无此字段 |

| triggers: 用了不被识别的顶层结构（如写成字典、或缩进不对） | 写成 YAML 字符串列表，每项加引号 | 不参与召回 |

| 把两个展示名二选一改名 | 保留已有、补缺的那个 | 修一边坏一边 |

§A2.4 规范从哪里来：实证，不靠查文档

不要靠查文档定字段名。 文档有二手转述，社区文章互相抄，误差会一路传下去。实证方法有两条：

判据一（应用行为，优先）：应用自有的 storage/**/skill-picker.json 里存着它实际解析出来的技能名。2026-09-18 实测：凡 displayName 有值的技能都被解析成中文；而只有 display_name 的被回退成 slug。这是应用行为的直接证据，优先于频次统计。

python scripts_curator/fm_normalize.py probe

统计范围：~/.workbuddy/plugins/cache/**/SKILL.md 与 ~/.workbuddy/skills/**/SKILL.md。

判据二（频次）：如果某个写法只在自己产出的包里出现，那不是规范，是笔误。

> ⚠️ 规范会漂移（历史上从"289 个包"复核到今天的双写口径就改过）。跑 probe 现查一遍胜过背结论。

§A3 标准 frontmatter 结构（本机自用）

---

name: <kebab-目录名>          # 机器标识：仅 a-z/0-9/-，且须等于父目录名（官方规格硬要求）

agent_created: true

description: |

  能力说明。当用户……时使用。

  不适用于：……（这类边界信息保留在 description，不放进 triggers）

triggers:

  - "触发词一"

  - "触发词二"

source_book: 来源（书籍/实战批次）

tags: [domain, type]

related_skills: [中文技能名, 中文技能名]

growth:

  merge_group: <合并域，英文短横线>

  merge_priority: 10            # 主线=10 / 成员=50 / 未声明=99（数小者优先）

  merge_policy: confirm         # never = 声明拒绝融合

copyright:

  holder: "zzzzzzzp"

  year: 2026

  license: "All Rights Reserved"

---

> 显示名不在这份 frontmatter 里。 name 自 2026-09-19 起是机器标识，中文显示名（两段式 万象-<功能>（L# 位名））住同目录 _user_meta.json 的 name 字段。应用读取优先级：meta?.name || frontmatter.name || dirName。

格律：name 与 agent_created 放最前，triggers 紧跟 description。

growth 块决定这部技能能不能参与融合——没有它，§A4.2 的跨域护栏读不到域声明，融合能力等于不存在。新建技能时必须写。

§A4 技能库地图与生命周期

§A4.1 位置与六族分类

| 位置 | 说明 |

|---|---|

| C:\Users\<你>\.workbuddy\skills\ | 用户级技能库（治理对象） |

| {workspace}\.workbuddy\skills\ | 项目级技能（不在本技能治理范围） |

| C:\Users\<你>\.workbuddy\skills_archive\ | 归档区（只进不出，除非用户要求恢复） |

六族用于盘点时给技能归堆，它是观察用的分类，不等于 §A3 里那个决定能否融合的 merge_group：

| 族 | 覆盖 | 典型 |

|---|---|---|

| A 金融数据 | 行情/财报/研报查询 | westockdata、neodata-financial-search |

| B 浏览器自动化 | CDP 零依赖族 + 官方插件 | cdp-batch-form-filler、zero-dep-frontend-verify |

| C 蒸馏·进化 | 经验/作品/人物 → 技能与方法论 | cangjie-distill、yourself-skill |

| D Agent 行为 | 主动性、记忆、指令转换 | proactive-agent、ontology |

| E 文本处理 | 去 AI 味、润色 | humanizer-bilingual |

| F 业务专用 | 景观/文件/短剧/上传等具体场景 | file-organizer、register-sync |

> 注：上表「典型」列是建族时的示例名，不等于当前实盘名单——多轮融合后部分示例已并入《万象》系列。

> 实际盘点一律以 §A4 的实盘扫描结果为准，不要拿本表当清单用。

§A4.2 生命周期与判定规则（量化）

经验 → [候选] → 新增 → 使用中 → (修正回写) ↺

                        ↓                ↘

                      归档 ←— 替代/重叠      进化出子技能

                        ↓

                      丢弃（归档后 2 个复盘周期无人要求恢复）

新增（经验 → 技能）

• 同一类经验/坑出现 ≥ 2 次，且现有技能无法覆盖 → 沉淀为新技能

• 只出现过一次的教训 → 先记 memory，不急着建技能

• 新技能必须自问：六族里有没有重复的？有 → 走「合并」或写进现有技能

合并（冗余消除）

• 两技能触发场景重叠 ≥ 50%，或同一指南/同一来源的双语/双版本 → 合并

• 合并动作：新技能单入口 + 原文挂 references/ + 原件归档（目录名标 __merged_日期）

• 触发词分属不同场景的不算重叠（如 CDP 三技能：填表 / 验证 / 登录态修复，场景不同，保持独立）

• ⚠️ 借用技能（外来）不可被融合——见 §A1 铁律 2。要用熟它只有一条干净的路：B 篇 §B11 净室转生（先转成自研技能，再谈融合）。

归档（膨胀控制）—— 满足任一即可提上议程

• 被官方/插件版完全替代（自研版 vs 官方插件版）

• 90 天未使用且无独占能力

• 修的坑已不存在（平台改版、环境已变）

丢弃：归档满 2 个复盘周期（约 2 个月）仍无人要求恢复 → 征求用户确认后永久删除。

回写进化（最核心，每次用完技能都做）

• agent_created: true 的技能：发现过时/错误/更优做法 → 立即改回 SKILL.md 本体

• 外部安装技能（无 agent_created 标记）：不改本体，在台账该技能条目下追加一行「patch 笔记：日期 + 发现 + 规避办法」

• 每次回写后把技能 version +0.1，在 frontmatter 加/更新 changelog

§A4.3 插件侧：不是技能，但有开关（2026-09-19 立）

技能库治理只覆盖 ~/.workbuddy/skills/（递归扫，唯一可改名归一的地盘）。

应用侧的 60 个插件是另一套系统：显示名由应用控制，改不了。本节只管一件事——要不要留。

开关只有一个：~/.workbuddy/settings.json → enabledPlugins

• false = 禁用；true / 不出现 = 启用。可逆、不删任何文件，改前先备份。UI 截图右上角「批量管理」是同一开关的图形入口。

• 键名格式 插件名@来源市场；内置技能型带 skill- 前缀（skill-skill-creator@workbuddy-builtin）——写成 skill-creator 静默不生效（解析器忽略未识别键，不报错）。

❌ 「删文件」这条路已被实测证伪：改 installed_plugins.json ＋删 cache/ 后，2.5h 内 15 个被还原 11 个（登记条数 64→49→60）。

插件权威状态在账户态，不在本地文件 ⇒ 手动删 = 白删。

五类来源（事实源 installed_plugins.json，共 60 条）：

| 来源 | 数量 | 性质 |

|---|---|---|

| @workbuddy-builtin | 42 | 应用内置，随版本同步 |

| @experts | 11 | 专家市场下载 |

| @codebuddy-plugins-official | 3 | 唯一的真·市场下载（agent-browser / find-skills / playwright-cli）|

| @cb_teams_marketplace | 2 | 团队市场（document-skills / finance-data）|

| @my-experts | 2 | 用户自传专家团，必须保留 |

🔴 禁之前必须做的一件事：查依赖。 插件可能正是某部技能的取数 / 执行通道。

> 案例：finance-data 被误设 false —— 它内含 neodata-financial-search ＋ westock-data / westock-tool，

> 而 万象-金融投研 有 18 个文件引用 westock（commands.md ×213）、16 个引用 neodata。

> 留着 false 等于掐断取数链路。

> 查法：在技能包里检索该插件的关键字，命中即视为依赖，禁前先问。

⚠️ .in_use 不能当「用没用」的判据（同日立、同日自查否掉）：

• .in_use/ 每文件＝一次加载记录（{"pid":…,"procStart":…}）；

• 但它只覆盖非 skill- 前缀插件 —— 28 个 skill-* 全为 0，其中含用户每天在用的

skill-wb-finance-skill、skill-geo-map-compliance-guard ⇒ 是盲区，不是证据；

• 且「加载过」≠「主动用过」：常驻插件每次启动都加载（agent-browser / find-skills / playwright-cli 痕迹数完全相同＝48）。

⇒ 判据铁则：新判据上线前先做「反例检验」——拿一个已知「在用」的对象去套，套不上就是判据错。

不可禁的机制依赖（禁了会坏功能）：

skill-geo-map-compliance-guard（地图强制触发）／skill-wecom-forwarded-chat-resources（宿主注入）／

skill-recommend-connectors ＋ skill-recommend-experts（系统流程程序化调用）／skill-tencent-docs-routing（Office 强制前置）。

「自研替代」的边界：插件里一半是文档、一半是接口。

• 可自研（价值在方法论）：skill-creator、skill-expert-manager、skill-marketplace-skill-installer、find-skills、skill-sites —— 本包已替代前两个。

• 不可自研（价值在背后的平台服务）：图像处理／3D·视频算力／地图合规数据／本地 editor_sdk／云端资料库。

对着接口自研，等于照着说明书造一台没有零件的机器。

插件清单与生命周期（官方原文，2026-09-19 核）

技能库只管 ~/.workbuddy/skills/；插件是另一套容器 —— 它自己能带技能、hook、agent、MCP、PATH 可执行文件与默认设置。规格如下：

| 项 | 规格 |

|---|---|

| 清单位置 | .codebuddy-plugin/plugin.json（同时兼容 .workbuddy-plugin/ 与 .claude-plugin/）。只有清单在它里面，其余目录一律在插件根 |

| 唯一必需字段 | name（kebab-case，无空格）。它同时是组件命名空间前缀（<插件名>:<组件名>） |

| 组件路径字段 | commands / agents / skills / outputStyles 的自定义路径会替换默认目录；hooks / mcpServers / lspServers 则是追加语义 |

| 默认启用 | defaultEnabled（默认 true）。为 false 时首次安装保持禁用；已有 enabledPlugins 优先于它 ⇒ 升级/重装不会翻掉用户已明确选过的状态 |

| 开关 | settings.json 的 enabledPlugins（键名 插件名@来源市场）。这是唯一可逆的禁用手段；「删文件」那条路已被实测证伪 |

| CLI | /plugin（装/卸/启停面板）、/reload-plugins（改完清单热加载）、plugin install / uninstall / enable / disable / update / prune / list、plugin marketplace ... |

| bin/ | 插件启用时加入 Bash 工具 PATH ⇒ 包内工具可作裸命令调用，不必写绝对路径 |

| 持久化 | ${CODEBUDDY_PLUGIN_DATA} → ~/.codebuddy/plugins/data/<插件id>/。更新后保留；卸载最后一个安装作用域时自动删（--keep-data 可留） |

> 🔴 官方文档一律写 ~/.codebuddy/...，本机实盘是 ~/.workbuddy/...。 照抄文档路径会找不到文件且不报错。

> 口径：文档给字段名与语义，实盘给真实路径 —— 两者都要，不能只取一个。

§A4.4 技能图标：按等级挂到技能列表（2026-09-19 立）

技能列表的图标不在 SKILL.md 里，而在技能目录的一个元数据文件里。机制已实测确认：

skills/<技能目录>/

  _icon.svg          图标本体（SVG 文本；扩展名随意，应用只当路径用）

  _user_meta.json    {"iconLocalPath": "<绝对路径>\\_icon.svg"}

应用扫描技能目录时，按固定优先级取第一个存在的 meta：

_skillhub_meta.json → _marketplace_meta.json → _knot_meta.json → _builtin_market_meta.json → _user_meta.json

取到 iconLocalPath 且文件存在，即 iconUrl = local-file:///…；否则回退 iconSource（http 链接，仅市场技能有）。

⇒ 自研技能换图标 = 写 _user_meta.json。但优先级最高的是 _skillhub_meta.json ——

目录里若留着市场残留 meta，_user_meta.json 会被整体忽略，须先让其让位（改名留档，不删）。

图标 = 身份层 × 等级层（两层几何不相交，构造法见 万象-矢量图标）：

| 层 | 内容 | 半径 |

|---|---|---|

| 身份（内） | 域爻（朱/青…域色）＋ 功能元件（墨色） | r ≤ 30 |

| 等级（外） | 刻度冠（亮 lit 格）＋ 加法层（八辐／方城） | r = 38→52 |

⇒ 升级只动外围，身份分毫不变，故同一技能可挂任意等级。

列表按 28px 显示 ⇒ 依尺寸降级规则用 32px 出图（<48px 不绘细节圈层，否则 1.4 坐标单位不足半像素、糊成灰雾）。

同步器（唯一真相源；产物 _icon.svg 勿手改）：

万象标识体系/tools/sync_skill_icons.py            # 预览：只出图并并排比对，不动技能目录

万象标识体系/tools/sync_skill_icons.py --apply    # 落盘：写技能目录 + 出预览图

• 真相源三处：几何构造 tools/gen_icons.py（DOMAINS / SKILLS / LEVELS / build）｜

当前等级 ~/.workbuddy/skills/.registry/state.json｜目标目录 ~/.workbuddy/skills/<目录>/

• 幂等：图标内容与等级均未变即跳过（实测重跑「更新 0 / 跳过 17」），可安全重复调用。

• 自动更新：等级一变（growth.py 的 annotate / promote 之后）重跑 --apply 即刷新。

• 回退：删各技能目录下的 _icon.svg 与 _user_meta.json 即还原。

• 加新位之前：先查「同域内元件互不重复」—— 八域 × 八元件 = 64 位，同域撞元件即两位一图。

> ⚠️ 改生成器要回读产物：SKILLS 表加一条只是登记，svg/skill/ 里的图要靠重跑 gen_icons.py 才落盘；

> 且补位元件必须从该域尚未占用的元件里取，取错不报错、只是两枚图标长得一样。

§A5 执行流程（用户说"整理技能库"时）

1. 扫描 —— 用 scripts_curator/scan_skills.py 全量扫（文件数/大小/mtime/frontmatter），禁止逐个人工读

```bash

python scripts_curator/scan_skills.py

```

> 本机坑：bash 偶发 PATH 损坏（ls/head/cat 均 not found，退出码 127）→ 用完整路径调 Python，或用 PowerShell；且不要用 | head（head 同样 not found，脚本会被杀在读文件之前）。

2. 台账比对 —— 读台账 技能库每日自进化/references/SKILL-LIBRARY.md，找新增未登记、状态待定的项

3. 出方案 —— 按四类动作（新增 / 合并 / 归档 / 仅标记）列出清单和理由，给用户确认

4. 执行 —— 小批量、可逆、每步验证（移动后 os.path.exists 复核）

5. 更新台账 —— 动作、日期、原因全部落台账

6. 报告 —— 整理前后技能数、本次动作摘要、待用户决策项

§A6 批量改造：改名与补字段

§A6.1 第 1 步 · 盘点现状

导出所有技能的 name 与目录名，找出英文名、缺 triggers 的：

$root = "$env:USERPROFILE\.workbuddy\skills"

Get-ChildItem -LiteralPath $root -Directory | ForEach-Object {

  $md = Join-Path $_.FullName "SKILL.md"

  if (Test-Path -LiteralPath $md) {

    $lines = [System.IO.File]::ReadAllLines($md, [System.Text.Encoding]::UTF8)

    $nm = ($lines | Where-Object { $_ -match '^name:\s*' } | Select-Object -First 1) -replace '^name:\s*',''

    "{0}`t{1}" -f $_.Name, $nm

  }

}

§A6.2 第 2 步 · 改 name 与补 triggers

同一文件的多个修改必须串行，或合并为一次 Edit。 并发发两个 Edit 会互相覆盖，且都报"成功"（见 §A9 踩坑 1）。

改动优先级：① 显示名（_user_meta.json.name）→ 中文两段式；② description 结尾边界行之后 → 插入 triggers: 块；③ description 与 related_skills 中指向其他技能的英文标识 → 中文名。

§A6.3 第 3 步 · 用工具改名，不要脚本全文替换

改名不要手改 name 行，也不要写脚本做全文替换。用成长体系的命令：

$py = "<Python 绝对路径>"

$g  = "$env:USERPROFILE\.workbuddy\skills\omni-skill-forge\scripts\growth.py"



& $py $g rename                                  # 预演

& $py $g rename --apply                          # 执行

& $py $g rename --only <目录名> --apply

& $py $g rename --refs-only --apply              # 不改名，只补同步漏掉的引用

为什么不能用脚本全文替换：技能名会作为触发词原样出现在 triggers 与 description 里。全文替换一定会把触发词一起改掉 —— 实测踩过一次：透水结构选型 被换成 透水-结构选型 后，用户按原来的说法提问就再也命中不了这部技能。工具的替换范围是白名单式的：

| 位置 | 处理 | 理由 |

|---|---|---|

| name: 行 | 换 | 它就是显示名 |

| related_skills: 行 | 换 | 明确指向另一部技能 |

| description 里 走 / 详见 / 参见 / 参照 / 改用 之后 | 换 | 交叉引用 |

| description 里 触发词： 之后 | 不换 | 清单，必须保留旧说法 |

| triggers: 列表 | 不换 | 同上 |

| 正文全文 | 换 | 正文里没有触发词清单 |

| 文档 H1 标题 | 换（若它恰好等于旧名） | 否则会留下一个已不存在的老名字 |

rename --refs-only 是给漏改补救用的：旧名只留在 events.jsonl 的 rename 事件里，重新推命名方案只能推出新名，拿新名去找新名等于什么都没做。所以映射要从事件历史重建。

§A6.4 第 4 步 · 改完必须重新盖章

改名会让版权指纹失效 —— 它同步了正文里的互相引用，正文一变指纹即失效。这个 links 必须显式认领：

& $py "$env:USERPROFILE\.workbuddy\skills\omni-skill-forge\scripts\assetguard.py" stamp --apply --accept-drift

& $py "$env:USERPROFILE\.workbuddy\skills\omni-skill-forge\scripts\assetguard.py" seal

> --accept-drift 不能无脑加：如果那处改动不是你做的，那这一下等于替别人把改动洗白成"一直如此"。

§A6.5 第 5 步 · 校验（必做）

现成的校验命令优先于临时脚本：

& $py $g rename              # 预演即校验：字数越界会报出来

& $py $g report              # 等级与名字现状

& $py $g registry_check      # 或直接 registry_check.py：状态库完整性（含 frontmatter 可解析）

& $py "$...\assetguard.py" verify                # 版权章与正文是否一致

& $py "$...\self_test_growth.py"                 # 改名逻辑的回归自测

& $py "$...\fm_normalize.py" scan                # 字段名体检（只读）

单人份查 frontmatter 时（怀疑某份被改坏）：

import os, yaml

root = r"C:\Users\<你>\.workbuddy\skills"

for t in os.listdir(root):

    p = os.path.join(root, t, "SKILL.md")

    if not os.path.isfile(p): continue

    raw = open(p, encoding="utf-8").read()

    if not raw.startswith("---"): print("BAD ", t); continue

    try:

        d = yaml.safe_load(raw.split("---", 2)[1])

    except Exception as e:

        print("FAIL", t, e); continue

    tg = d.get("triggers")

    print("OK   %-40s name=%s triggers=%d" % (t, d.get("name"), len(tg) if isinstance(tg, list) else 0))

缺 pyyaml 时：& "<venv>\Scripts\pip.exe" install pyyaml --quiet

§A6.6 第 6 步 · 复查残留

用 Grep 工具，glob 限定 **/SKILL.md，搜旧英文名。

期望残留：构建标识行、references/ 路径行 —— 其余应为 0。

§A7 保护清单（改动时一律跳过）

改了会失效或造成隐患：

| 对象 | 例子 | 原因 |

|---|---|---|

| 构建标识 | cangjie.bundle-id: pantone-color-harmony | 构建工具靠它匹配产物 |

| 能力 ID | cap.pantonecn-color-system.color-naming | 被 capability-index / 其他文件交叉引用 |

| 文件路径 | references/general-codes.md | 目录名未变，路径仍然有效且必须准确 |

| 外部引入的技能 | cangjie-skill、flyelep-ai-skills | 上游更新会覆盖本地改动 |

| 历史测试记录 | test-results.md、test-prompts.json | 记录当时事实，不必追改 |

> 注意：目录名本身不变，因此旧英文名并非"断链"，只是"用目录名指代技能"。正文引用改成中文是为了阅读一致性，不改也不会真的失联。

§A8 台账与复盘节奏

台账 = 技能库每日自进化/references/SKILL-LIBRARY.md（由自进化技能所辖，不在本技能包内）。每次整理必更新；单次回写进化也登记一行。

台账是持久化视图，磁盘才是事实源——与磁盘不符时以磁盘为准，并当场修正台账。

复盘节奏：

• 用户主动说"技能库复盘/体检" → 全量跑一遍 §A5

• 建议自然节奏：每月一次

• 补充触发时机：安装 ≥ 3 个新技能后、某项目收尾后

§A9 踩坑记录（本机实测）

1. 同文件并发 Edit 会静默丢改动。 一条消息里对同一文件发两个 Edit，两个都报 Successfully，但后写的基于旧内容、覆盖前一个结果。同一文件的多处修改必须串行，或合并成一次 Edit。

2. PowerShell 的 *> 重定向产出无法直读的编码，Read 会报 "Cannot display content of binary file"。改用 [System.IO.File]::WriteAllLines($path, $array, [System.Text.UTF8Encoding]::new($false)) 落盘。

3. 写文件一律用无 BOM UTF-8：New-Object System.Text.UTF8Encoding($false)。带 BOM 会让 --- 前多出字符，前端解析器可能识别不到 frontmatter。

4. 改完必须 grep 复查。 脚本替换可能漏掉特殊写法（-like 匹配、跨行引用），也可能误伤路径。grep 是唯一可靠的确认手段。

5. 新名字当次会话不生效。 技能清单在会话启动时加载，改名结果要到下次会话才出现在列表里。务必告知用户，别让他们以为没生效。

6. snake 与 camel 双写是"两个都要"，不是"改哪个都行"。 缺哪边坏哪边，而且失败不在任何日志里。

7. --dual-only 会关掉所有删除动作（slug / triggers 不动）。批量处理自己不熟悉的技能时务必带上。

8. 引导词别收单字。 判定"这句话在指向另一部技能"时若用 走|转|详见|参见|参照，其中单字 转 太常见——转义特殊字符、转换链、转场 的后半截都会被当成技能名捕获。两字及以上的固定搭配才配做引导词。

9. "某行含某关键字就整行跳过"是过粗的判断。 保护触发词清单时按行跳过含「触发词」的行，结果 不适用于：技能命名与触发词规范 这种只是提到「触发词」三字的句子也被跳过，里面的交叉引用永远补不上。要按标记切，不要按行切（切在 触发词： 之后）。

10. state 是派生物，文件才是事实。 一次事故：把备份里的单个成员解压到了当前目录，直接覆盖掉真实的技能文件。此后 state 里是新名、文件里是旧名，而"要不要改名"若只看 state 就会报「无需改动」，把不一致永久留在库里。判断必须读文件里的实际值。

11. 第三方依赖必须显式声明，不能假设机器上有。 本机受管 Python 无 pyyaml、requests、Pillow；用到时先在 venv 里装，并在正文写明依赖，否则换台机器就跑不动。

§A10 检查清单

改造完成后逐项打勾：

• [ ] 目录名未改动（仍是 ASCII）

• [ ] 显示名是 万象-<功能>（L# 位名） 两段式（前缀位固定为品牌「万象」，见 naming.json 的 brand）

• [ ] 本名（前缀＋功能）未越界；越界要么缩，要么显式接受

• [ ] 等级段没手写（升位时由 growth.py 自动换，手写会被覆盖）

• [ ] triggers 已补，项数 ≥ 5，覆盖用户会说的口语说法

• [ ] triggers 与 description 里的触发词清单一字未动（用 rename 工具而非脚本替换）

• [ ] description 的 不适用于: 边界信息保留，其中的交叉引用已同步为新名

• [ ] 正文与 related_skills 的互引用已同步

• [ ] 上架件：displayName 与 display_name 双写齐全（本机件不必）

• [ ] bundle-id / cap ID / 文件路径 / 外部技能未被动过

• [ ] registry_check.py 与 growth.py rename（预演）全通过

• [ ] 改过正文的已重新盖章（stamp --apply --accept-drift）并重封包（seal）

• [ ] 已告知用户"下次会话生效"

§A11 命令速查

$py = "<Python 绝对路径>"

$b  = "$env:USERPROFILE\.workbuddy\skills"



# —— A 篇 · 治理侧 ——

& $py "$b\omni-skill-forge\scripts_curator\scan_skills.py"   # 全量扫描技能库

& $py "$b\omni-skill-forge\scripts_curator\fm_normalize.py" scan    # 字段名体检（只读）

& $py "$b\omni-skill-forge\scripts_curator\fm_normalize.py" probe   # 复核「规范」当下是否仍成立

& $py "$b\omni-skill-forge\scripts_curator\fm_normalize.py" fix --path <目录> --deep --dual-only --apply   # 只补双写键



# —— B 篇 · 铸造侧 ——

& $py "$b\omni-skill-forge\scripts\growth.py" rename           # 改名预演 / --apply 执行

& $py "$b\omni-skill-forge\scripts\growth.py" report           # 位次与名字现状

& $py "$b\omni-skill-forge\scripts\registry_check.py"          # 状态库完整性

& $py "$b\omni-skill-forge\scripts\assetguard.py" verify       # 版权章与正文一致性

& $py "$b\omni-skill-forge\scripts\self_test_growth.py"        # 改名逻辑回归自测

& $py "$b\omni-skill-forge\scripts\self_test_guard.py"         # 版权侧的回归自测

fm_normalize.py fix 默认 dry-run —— 不带 --apply 只打印将要做的改动。scan 在任何情况下都不动文件。

§A12 与相邻技能的分工

| 场景 | 去哪 |

|---|---|

| 库本身膨胀了、要分类/归档/合并 | 本技能 |

| 名字怎么起、字段怎么写、怎么批量改名 | 本技能 |

| 位次怎么算、能不能融合、血脉上限 | B 篇 §B1–§B4 |

| 版权归谁、要不要加密包、对方的使用经验怎么回来 | B 篇 §B5–§B10 |

| 外来技能包进来之前的安全审查 | B 篇 §B13（另有英文原版 skill-vetter 作第二意见） |

| 把一个新的多源主题融合成一部技能 | C 篇 |

| 犯错/被纠正要长记性 | self-improving-agent |

| 从书/文章提炼方法论成技能 | 万象-知识蒸馏 |

| 把"人"的经验蒸馏成技能 | 万象-知识蒸馏 |

| 上架前的内容合规（凭证、路径、危险代码） | 万象-知识蒸馏 的 od_audit.py |

本技能专注一件事：字段名对不对。 内容对不对、安不安全，各有其主（见上表）。

附 · 融合说明与位次依据

来源（3 部）

• skill-library-curator（自研）：提供 §A1 三条铁律、§A4.1 位置与六族分类、§A4.2 生命周期量化规则、§A5 执行流程、§A8 台账与复盘节奏，以及 scripts_curator/scan_skills.py。作骨架宿主。

• skill-metadata-standard（自研）：提供 §A2.1 中文三段式、§A3 标准 frontmatter、§A6 批量改造五步、§A7 保护清单、§A9 踩坑、§A10 检查清单。

• skill-frontmatter-normalizer（自研）：提供 §A2.2–2.4 上架双写规则与实证方法（probe 从应用行为反查，而非查文档），以及 scripts_curator/fm_normalize.py。

融合中的关键处理

1. 消解了两条互相冲突的规范。 两部来源对 name 字段给出相反要求（一个要 kebab-case，一个要中文）。查证后确认它们说的不是同一场景，按"本机自用 / 对外上架"分列，并写明"不要二选一改名"的历史教训。这条若照抄任一部，都会让另一边失效。

2. 旧他人的机器路径已泛化。 skill-metadata-standard 原文档硬编码了旧机器的用户目录；本技能一律写 <你>\.workbuddy\... 或用 $env:USERPROFILE。

3. 跨技能命令路径已指向融合后的新位置。 原散落在各源的 skill-growth-merger/scripts/...、skill-asset-guard/scripts/... 全部改写成 omni-skill-forge/scripts/...——原路径在原件归档后即失效。

4. self_test.py 撞名。 铸造侧两部来源各有一份，已分别落为 self_test_guard.py / self_test_growth.py，两者各自保留。

位次依据（不虚标）

融合前三部来源在成长注册表中的实测状态：

| 来源 | XP | 事件数 | 最近使用 |

|---|---|---|---|

| skill-library-curator | 未入注册表 | — | — |

| skill-metadata-standard | 0.0 | 0 | — |

| skill-frontmatter-normalizer | 未入注册表 | — | — |

三部合计 XP = 0，故本技能位次为 L0 未习。若后续真正用起来，由 B 篇的 growth.py record 记账、annotate 回写名字第三段。

> merge_policy: confirm —— 本技能参与技能域的融合，但每次融合都要人工确认。理由与作者体系一致：融合不可逆，宁可不融合、不可错融合。

待办：本文件为三源重组，旧版权指纹对不上，交付前须运行 assetguard.py stamp --apply 重新登记（属 B 篇 · 铸造的职责）。

§B19 棘轮：分跌了就回到改前

一句话：darwin 循环的「分数只升不降」由两半拼成 —— 后半是 §B18 的量化评分 + 独立评委，前半就是这里的改前留底、跌了就回滚。

为什么不用 git

原版 darwin-skill 的棘轮靠 git revert 回滚。本库不引入 git：把技能库变成仓库要多一个 .git、还要定提交纪律与忽略规则 —— 那是改变库的性质，为一个回滚能力付这个代价不划算。改用自带快照，能力等价（可列历史、可回滚）、零依赖、不动库结构。

| 命令 | 作用 | 写盘门槛 |

|---|---|---|

| snapshot --dir X --note "…" | 给正文拍快照：二进制原件 + 当时指纹 + 当时机器分 + 当时台账条目 | 无门槛 |

| snapshot（不带 --dir） | 快照全景：谁有备份、谁一张都没有 | — |

| snapshot --dir X --list | 该资产的历史快照（带机器分升降） | — |

| rollback --dir X [--to N] [--apply] | 恢复到某张快照 | 默认预演，--apply 才写 |

snapshot 刻意不设 --apply 门槛：它只新增历史目录、不覆盖任何东西。给备份动作设门槛，只会让「改前先备份」这条纪律变得麻烦，而麻烦的纪律等于没有纪律。

历史区在 ~/.workbuddy/skills/.registry/history/<kind>__<dir>/<seq>_<时间>/ —— 以点开头，list_skills 的 d.startswith(".") 会跳过，不会被当成技能扫到。

一轮完整的棘轮

snapshot --dir X --note "本轮要改哪个维度"   # 留底

# …只改一个维度（§B18）…

score --dir X --verbose                      # 机器初评

duel --a A.json --b B.json --dir X           # 两个独立评委比对

rollback --dir X --apply                     # 分跌了 → 回到改前

verify --dir X                               # 确认闭环

四条纪律（写死在实现里，不是写在文档里）

| # | 纪律 | 为什么 |

|---|---|---|

| 1 | 回滚前自动给当前状态留底 | 回滚是覆盖写。没有这一张，回滚错了就再也回不来 —— 本库第一条硬规矩是「不可逆操作先留证据」 |

| 2 | 只动正文 | scripts/、assets/、_user_meta.json、plugin.json、settings.json 一律不碰。混进来，一次回滚就变成一次事故 |

| 3 | 连台账一起恢复 | verify 是三方对账（文件指纹 + 版权块 + 台账）。只恢复文件而不同步台账，verify 立刻报「与台账记录不一致」—— 回滚不算完成 |

| 4 | 默认目标跳过「自动留底」 | 自动留底记的是"当时那个状态"。拿它当默认目标，一次回滚之后再回滚，就会滚回刚被否掉的那个改动 —— 与棘轮"只升不降"恰好相反 |

落地时抓到的三个缺陷（都是自测与落盘复核抓的，不是设计时想到的）

1. 默认目标选中了「自动留底」 —— 一次回滚后再回滚 = 把刚否掉的改动请回来。修法即纪律 4，并在 manifest 里加 auto 标记、列表里显示 [自动留底]。

2. 同内容也留底 —— 回滚到与当前一致的快照时仍拍一张，纯堆垃圾。改为指纹相同时不留底。

3. 幂等未验 —— 连跑两次 --to N --apply 必须都不改内容、不堆垃圾。已补进自测第 8c 步。

验收判据（可复算，且必须在临时库跑）

--skills-dir 指向临时目录，绝不在真库上试：

拍快照 → 改正文 → verify 必须报「正文指纹不符」

       → rollback 预演必须不写盘（前后字节相同）

       → rollback --apply 后字节必须与快照时逐字节相同

       → verify 必须通过

       → 再 rollback 必须报「0 个文件需改」

反例（三条全部必须拒绝，rc=1）：--to 99 / 不存在的资产 / 对 klass=external 的资产回滚

附：content_files 的覆盖口径（2026-09-20 补齐 knowledge/）

专家包的指纹与水印覆盖哪些文件，由 content_files() 白名单决定：

| 覆盖 | 不覆盖 | 理由 |

|---|---|---|

| README.md、agents/*.md、knowledge/*.md、skills/*/SKILL.md | scripts/、tools/、avatars/、plugin.json、settings.json、memory/ | 水印是嵌进正文的零宽字符：代码与配置里嵌它可能被宿主校验或解释器读成脏数据，图片嵌不进去。只覆盖文档类 |

⚠️ memory/ 必须排除，且绝不能改成"递归扫全部 .md"。后果两条都很糟：① 使用者的私人经验库本就不该外发，却被嵌上权属水印；② 记忆是逐次追加的，会让指纹天天漂移 —— 每写一条记忆就报一次「正文被改过」。

改口径的顺序很重要：口径一变，已盖章资产的指纹立刻失效（变 drift）。所以要先改口径、再盖章；已经盖过的则必须重盖。本次只有 2 部未盖的自研专家包（design-pm-expert、omni-kanyu-team）—— 先补 knowledge/、再补盖章，一次到位，没有产生额外的重盖工作量。

§B20 触发回归测试集（tests/test-prompts.json）

为什么要有：九维里最重的两维是「整体架构 12」与「实测表现 23」（合计 35 分），机器判不了，只能靠评委。评委凭什么判？得给他一份可核验的输入 —— 这个技能该在什么话下触发、不该在什么话下触发、哪些情形触发了也必须当场声明边界。

放在哪：<技能目录>/tests/test-prompts.json，单文件（本库技能都是单 SKILL.md，不需要分子域）。

> omni-permeable-pavement/tests/ 下另有 6 份 <子域>/test-prompts.json —— 那是随外部来源包带进来的子域测试集（skill 字段写的是上游原始名 sand-permeable-*），不是本库规范。本库自建的放顶层单文件，两者并存，校验只认顶层。

格式（与上游 darwin-skill 兼容，另加一个字段）：

{

  "skill": "omni-xxx",

  "confusable_with": ["omni-yyy"],

  "test_cases": [

    { "id": "should-trigger-01", "type": "should_trigger",

      "prompt": "用户会怎么问（原话口吻）",

      "expected_behavior": "应激活 + 具体走哪篇/哪条线 + 一条可核验的判据",

      "notes": "这一条的依据来自正文哪一小节" }

  ]

}

type 三选一：should_trigger / should_not_trigger / boundary。

最低配置：6 条 = 3 正 + 2 负 + 1 边界。

五条铁律

| # | 铁律 | 为什么 |

|---|---|---|

| 1 | prompt 必须是用户原话 | 「请使用 omni-xxx 技能」这种自指式废话测不出任何东西 —— 真实用户不会这么说话。校验工具会直接判它不合格 |

| 2 | 诱饵必须取自本技能正文写明的「不适用」条目 | 本库真正的事故是误触发（把普通视频当模板特效、把进库审查当市场寻源），不是漏触发。只写正面例只能证明"能激活"，写上诱饵才证明边界真的在 |

| 3 | expected_behavior 里正文没写的判据不许编 | 写不出细判据时，宁可只写"激活本技能并走 X 篇"这种路由级判据 —— 路由级的仍然有价值（误触发的判定本来就只看路由），编造数值才是错的 |

| 4 | 不声称"跑过了" | 本机没有"把一段话喂给技能看会不会触发"的自动通道，真实触发只能靠真实对话。这份测试集的定位是评委的输入 + 人工回归清单。凡说"测试集通过率 90%"的，都不可信 |

| 5 | 改完技能，拿这几条自己走一遍 | 这是它作为"回归"的那一半用途：边界变了没有，走一遍就知道 |

命令

# 全库覆盖率：谁有、谁没有、各几条、结构合不合规

& $py "$s\assetguard.py" test-prompts

# 单部深度校验：schema + 引用真实性 + 是否自指式废话

& $py "$s\assetguard.py" test-prompts --dir omni-research

# 评分时评委能看到有没有测试集

& $py "$s\assetguard.py" score --dir omni-research --verbose

校验判据（10 条，都做过反例检验）

skill 字段与目录名一致 / JSON 合法 / test_cases 非空 / 条数 ≥ 6 / id 不重复 / type 合法 / prompt ≥ 8 字且非自指式废话 / expected_behavior ≥ 10 字 / 负例里引用的 omni-* 技能必须真实存在 / confusable_with 里的技能必须存在。

> 「指向不存在的技能」是最隐蔽的错误 —— 看着有内容，其实是编的。所以校验拿全库技能名当白名单逐个查。

一个真实教训（2026-09-20）：工具第一次在真实内容上跑，就在我自己写的 132 条里揪出 2 条 expected_behavior 只写了 8~9 字（「激活演示结构美化」），等于写了没写。判据的下限不是防空的，它挡的是"写了等于没写"那种判据。

本库现状（2026-09-20 建库）

22 部技能全部有测试集，共 132 条（每部 3 正 + 2 负 + 1 边界），全库校验 22/22 通过。

建立顺序的依据是触发边界混淆度（description 的 bigram 重合度，可复算）：最危险的对是 omni-3d-fx × omni-image-retouch（重合 0.28，都是图片进图片出），其次是 omni-market-sourcing × omni-skill-forge（0.16，都涉技能库）。若将来要扩充，先扩这两对。

C 篇 · 融合（把多部并成一部）

C 篇 · 融合（多源合并与覆盖度销账）

一句话：合并技能时最怕的不是写不好，是写漏。这套流程把"事后抽查"改成"写前销账 + 写后自动对账"。

§C0 命令入口：「万象融合」（一键续融）

用户说出「万象融合」即执行本命令。完整规格（判据 J1–J3 / 收益 U1–U3 / 反判据 R1–R6 / 停止条件 / 坑位表）见 references/命令_万象融合.md。

定位：本命令不是"把技能变少"，是把一部技能变强——数量下降是副产品。所以判据是「合并有用」：并了不变强的不合。

固定四段节奏，顺序不可调：

| 段 | 做什么 | 不许违背 |

|---|---|---|

| 0 勘察 | 跑 scripts_merge/fusion_scan.py，出「本轮可融合簇清单」，先报用户过目 | 出 0 簇即停，不硬凑 |

| 1 逐簇 | 每簇完整走一遍 §C1–§C7 | §C1 三条顺序铁律不可破 |

| 2 回归 | 七项全库回归（见命令文档 §4） | 本轮与历史各组一起跑，不许只跑新的 |

| 3 交代 | 四件事逐条报（见命令文档 §7） | 给证据，不给结论 |

命中任一反判据（R1–R6）的簇，一律停下来问用户，不自作主张。

§C1 先记住三条硬教训

这三条是实测代价换来的，先于一切操作：

1. 你的判据会错，内容往往是对的。 实测一轮中判据类失败累计 7 次、内容错误 0 次。每次对账报错，先定性是「内容真漏」还是「判据错」，不要急着改文档。判据错的四种典型形态：

• 容器节：源节只是个标题（I — 方法论骨架、E — 可执行步骤），内容全在子节 → 特征词命中必然低。应 DROP:结构性容器标题 或改映射到所有子节。

• 父子粒度：源节 H3 一路延伸到下一个 H2（中间夹着加粗段落），被你在目标里拆成多个子节 → 映射必须把拆出的子节全写上。

• 措辞改写：「全军覆没」→ 目标写「全部废止」。语义在，词不在。

• ** citing 装修 carried over**：标题词（Reading / Interpretation / Execution）目标里本就不该有。

2. 改完必回读。 本机 Edit 工具有静默不落盘的记录。定为铁律：改完立刻 Grep 该关键词回读点验；批量改动用"带断言的 Python 替换脚本"，脚本内部自己也回读一次。

3. 终验必须在归档之前跑完。 上一次踩出：归档后源目录不存在 → 检查器崩溃退出 → 你看到的 FAILS 数是上一次的陈旧报告在冒充新结果，极具欺骗性。现在 check 已支持归档区回退，但仍要养成"先验收、后归档"的顺序。

§C2 六步流程

第 1 步  勘察：列源技能的目录资产（脚本/references/数据），定宿主

第 2 步  备份：所有源（含大数据目录）copytree 进 skills_archive + 写 JSONL 台账

第 3 步  改造：优先 rename（零拷贝），次选 copytree；迁入各源独有资产，同名必改名避冲

第 4 步  写作：先把每个源当成"待销账清单"来读，写完后手动过一遍 §C4 的免责点

第 5 步  对账：draft → auto → 人工定夺 → check，直到 FAILS=0

第 6 步  归档 + 日志：移出源目录 → 追加当日工作日志

§C2.1 选宿主的判据

挑带可执行资产（脚本 / 数据目录 / references）的那部当宿主，纯文档源向它并入。理由：文档可以重写，来之不易的数据库与已验证过的脚本不能重建。

先判「一组出几部」，再选宿主。 融合不默认 N→1。八部治理类技能的实测分法（本技能 A/B/C 三篇即按此判据拆分）：

• 每部源先问一句「它回答的是同一件事吗」；答不上来的，就是两簇。

• 判据用职责动词：一组是「库里有哪些、叫什么、字段对不对」（盘货），

另一组是「这一件属于谁、能练到几品、能不能发出去」（处置单件）——

两簇动词不同、互不调用对方的判据，就出两部，别硬压成一部。

• 硬压的代价：正文会出现两个互不相干的"§C1 铁律"，触发词互相稀释，

以后任何一处的改动都要在另一簇的语境里重新解释一遍。

• 出两部时，每部各自建一份 spec（源只分给自己那簇），对账分别跑。

§C2.2 零拷贝改造（宿主资产很大时）

宿主 13 MB 以上不要 copytree，直接改目录名：

# 前提：已 copytree 备份到 skills_archive

if not os.path.isdir(new_dir):        # 目标必须空闲，否则 abort

    os.rename(host_src, new_dir)      # 零拷贝

宿主原 SKILL.md 不要删，侧存为 _SKILL_orig.md —— 既可逐字回溯，也省掉一次大文件 Read。

§C2.3 同名资产必须改名避冲

实测：references/general-codes.md（宿主）与另一源的 references/general-codes.md 内容共有行为 0（一份是量化总表、一份是域归属+实例），都想要。做法是改名而不是丢：general-codes-scope.md。

同类的还有 test-prompts.json vs test-prompts-ocr.json。

§C3 覆盖度销账工具（核心）

scripts_merge/fusion_coverage.py，零依赖，标准库。

§C3.1 四个命令

# ① 生成待销账表：把每个源的每一节登记一行

python scripts_merge/fusion_coverage.py draft <组名> <目标SKILL.md> <源目录1> <源目录2> ...

#   -> <组名>_spec.json（每行：src_dir / src_sec / to 待填）



# ② 机器预测映射：用"只在本节出现的特征词"匹配目标各节，给 top3 候选

python scripts_merge/fusion_coverage.py auto <组名>_spec.json

#   -> <组名>_auto.txt



# ③ 校验（最重要）

python scripts_merge/fusion_coverage.py check <组名>_spec.json

#   -> <组名>_coverage.txt，逐行给命中率，末尾 FAILS=N



# 校验的三道执法：

#   a. 有源小节漏登记吗（零遗漏）

#   b. 有没有未销账的行

#   c. 映射指向的目标节存在吗

#   d. 源节的特征词 / 主机名，只在【映射到的那个目标节内】匹配 —— 限定上下文，不做全文裸匹配

§C3.2 spec.json 的三种销账写法

| 写法 | 用途 | 判据 |

|---|---|---|

| "to": "目标节标题" | 正常迁移 | 特征词命中 ≥50% 且主机域名全在 |

| "to": "甲 + 乙 + 丙" | 内容被拆到多处 | 支持子串匹配（写标题片段即可）；多节之间用被半角空格包围的 + 分隔，各节正文拼接后再统算命中率 |

| "to": "DROP: 理由" | 主动声明删除（必须写理由） | 直接计入"已声明删除"，不列为 FAIL |

| "accept": "核可理由" | 内容确实在、只是词不同 | 即使命中率低也不算 FAIL，但理由要具体到"哪个内容落到了哪一节" |

> accept 不是免责按钮。写「理由」前必须打开源与目标逐条比对，确认内容真的在。拿不准就没有核可权。

§C3.3 怎么读懂命中率

• ≥50%：正常。

• 20–50%：多半是措辞改写或映射不全。先看报告里的「未命中特征词」列表——如果它们分属同一类（都是某个完整段落），说明那一段整体没搬。

• <20%：几乎一定有事。要么丢了，要么映射粒度错。

报告有可能超过你 Read 的行长上限（长行被 grep 省略）。需要看完整未命中词时，写 3 行 Python 把指定行导出（本机 PowerShell 不回显 stdout，脚本自落盘再 Read 是定式）。

§C4 融合写作的免责点与必收点

§C4.1 必收（丢了就是价值损失）

| 类型 | 为什么不能丢 |

|---|---|

| 量化实测数字（如"50 份中 18 份纯扫描"） | 是这条经验的可信度来源，删掉就变成空口建议 |

| 数据来源名（第三方站点、母平台名） | 用户要能回查；判断陈述是否可信时，它是唯一抓手 |

| 失败事故的复现与护栏（如某次把日志写到 8.7 GB 的看门狗代码） | 这类内容不可重建 |

| 脱敏与合规红线清单 | 属于对外分发的合规约束 |

§C4.2 可删 + 必须写进 drop 理由

• 源之间的"相邻技能分工"互指段落（融合后变成同一技能内部）

• 与融合后形态冲突的声明（如某源自称"纯知识速查、不含任何脚本"，而产物含 8 个脚本）

• 提示词级的经验回流节（受运行环境闸门约束且不可靠，应改成 hooks 级渠道）

• 纯结构性容器标题（I — 方法论骨架 这类本身无内容）

§C4.3 红线（每次写作前扫一遍）

• 旧称（本项目为「功法」）一律归一为「技能」

• 他人的私人路径（H:/某某的工作间/、C:/Users/<他人工号>/）必须泛化

• 真实项目名 / 人名 / 客户名不得进正文

• 本机用户名与安装路径：一律不写进技能（技能可能上线给他人用）。让命令可执行的正解是改写成环境变量或占位符（os.environ.get("OMNI_WS", os.getcwd())、<工作区>、~/.workbuddy/...）；「保留 + 加一句对外替换声明」挡不住泄漏，已被本机实测推翻。

§C5 验收标准

一组融合算完成，必须同时满足：

• [ ] check 报 FAILS=0，且报告中每一条 [低] / [ACC] 都经人工逐条比对过（不是批量勾选）

• [ ] 冒烟 FAILS=0：脚本 py_compile 全过、frontmatter 必备项齐、红线扫描 0 命中

• [ ] 目标技能的实跑自检通过（若源带 selftest，直接跑）

• [ ] 终验排在归档之前（顺序仍不可颠倒）。check 现对源与目标都做了归档区回退：目标产物若已被合法归档（如后续轮把它并走了），会按归档副本复验，并在报告首行标注 !! 目标已归档，本次按归档区回退副本复验：ARCH:<目录名>。看到这行必须确认回退到的是本组产物，别把上一轮的陈旧报告当成新结果

• [ ] 归档前扫一遍全库：除本组产物外，有没有别的技能在正文里引用这些旧目录名。组 3 实测这一步能提前抓出跨组断链

• [ ] 源技能已归档 skills_archive/<原名>__<原因>__<日期>\，台账有记录

• [ ] 明确列出"不并入"的源及理由（如外来技能不可被融合 → 原位保留 + 在新技能里显式互指），不留悬空

• [ ] 当日工作日志已追加记录该组的来源、精度（行数/删除数/核可数）与抓到的真漏清单

§C6 归档工具

scripts_merge/fusion_ops.py，两个函数 + JSONL 台账：

python scripts_merge/fusion_ops.py backup  <技能目录名> [原因]   # 只备份，不动源

python scripts_merge/fusion_ops.py archive <技能目录名> <原因>   # 备份后移出源目录

python scripts_merge/fusion_ops.py list                          # 查看台账

• 归档区 ~/.workbuddy/skills_archive/，目录名格式 <原名>__<原因>__<日期>

• 台账 _ARCHIVE_LEDGER.jsonl 逐条记 ts / action / dir / reason / dest / files

• 绝不直接 delete —— 用户既有偏好是"先移入待删除区，人工确认后再说"

§C7 已知边界

• fusion_coverage.py 的特征词是 2–8 字中文字片段 + ≥4 字符英文 token，对纯代码节能提取的信号有限；代码类内容建议额外人工比对。

• 自动映射（auto）只是候选，短节拿不到足够特征词时会全部并列 0%，必须人工复核，不能直接当结论。

• 检查器按 markdown 标题切节（##–####）。如果目标技能用别的写法（如仅加粗当标题），需先改造 merge 逻辑。

• 本工具防的是"遗漏"，不防"写错"。日期写串、数字写反它抓不出来，那要靠 _meta 校验类工具。

附 · 三篇分工一页纸

| 你要做什么 | 去哪一篇 | 先跑什么 |

|---|---|---|

| 看库现在乱不乱、哪些该进该退 | A 篇 §C4–§C5 | scripts_curator/scan_skills.py |

| 给技能起名、改中文名、批量改名 | A 篇 §C2、§C6 | scripts/growth.py rename（预演） |

| 查字段名对不对、补 triggers / 双写键 | A 篇 §C2–§C3 | scripts_curator/fm_normalize.py scan |

| 看某部技能练到几品、能不能融合 | B 篇 §C1–§C4 | scripts/growth.py report / domains |

| 盖章、做加密发布包、上架前合规 | B 篇 §C5–§C9 | scripts/assetguard.py status |

| 收别人的使用经验、看改进心得 | B 篇 §C10 | scripts/assetguard.py ingest / wishes |

| 想量化打分、找下一轮该改哪一维 | B 篇 §B18 | scripts/assetguard.py score / duel |

| 改之前留底、改砸了要退回 | B 篇 §B19 | scripts/assetguard.py snapshot / rollback |

| 给技能写触发回归测试集、查覆盖率 | B 篇 §B20 | scripts/assetguard.py test-prompts |

| 审一个外来技能包能不能装 | B 篇 §C13 | 先 zipfile 只读侦察 |

| 把多部技能并成一部 | C 篇 §C2–§C5 | scripts_merge/fusion_coverage.py draft |

三篇之间的固定顺序（做一次完整整合时）：

A 篇 扫描盘点 → C 篇 融合（宿主零拷贝改造 → 装配 → 销账 FAILS=0）

  → B 篇 过户 XP（state/events/merges）→ B 篇 盖章（stamp）→ B 篇 封包（seal）

  → A 篇 登记台账（`技能库每日自进化/references/SKILL-LIBRARY.md`）

> 顺序不能反。 先盖章再改正文 = 白跳一个版本号（B 篇 §C9）；先归档再跑销账 = 校验器崩溃后留下陈旧报告冒充新结果（C 篇 §C1 硬教训 3）。

不并入本技能的相关技能（各有其主）：

| 场景 | 去哪 |

|---|---|

| 创作技能内容本身 | skill-creator |

| 从书/文章/人物提炼方法论成技能 | 万象-知识蒸馏 |

| 判断工程建设标准是否现行 | 万象-规范核验 |

| 犯错/被纠正要长记性 | self-improving-agent（外来，只读） |

| 把应用发布到线上 | 发布为应用 |

本技能的边界一句话：它管技能这个产物本身（货架、位次、权属、融合）——不管技能里写的内容对不对。