技能管家 · 把"技能集合"当成一个可迁移系统来治理

它管什么：站在整个技能库视角回答四件事——要不要加新技能、加了放哪跟谁配合、现有集合健不健康、外部技能怎么收。 它不管什么：不替你写单个技能的正文（那是 skill-creator 类技能的活，本技能把关后交给它）；不执行同步分发（库的同步脚本干）；默认只管用户自有的技能集合，但范围由参数/约定决定，不写死任何目录。 最容易误触发的一条：去读、clone、解读某个 GitHub 仓库、论文或外部提示词/Agent 实践，哪怕研究对象本身就是“技能怎么写、提示词为什么有效”，也不归本技能——那是 feynman-explainer 的技术调研。本技能只在动作对象是“你自己这套已安装技能集合”（要不要收、有没有冲突、怎么拆并、放哪）时才启用；研究外部资料 ≠ 治理自己的技能库。

零环境依赖原则（本技能自己也要遵守）

• 库位置可发现、不写死：技能库根目录按这个顺序确定——用户显式给出 ＞ 当前工作目录或其上级里第一个含多个 <name>/SKILL.md 的目录 ＞ 宿主约定的技能目录。任何路径都作为参数传入，代码里不内置绝对路径、用户名、平台名。
• 平台能力只作可选增强：若宿主提供 skill-creator、文档平台、检索、同步脚本等，能增强就用；没有这些时本技能的判断、清单、体检报告照样产出。
• 可迁移性是硬要求：一个不能迁移、强绑定特定平台的技能，要先做去绑定改造或拒绝收录。依赖某平台 API 时必须写成"若具备则用，否则降级到通用方式"，依赖只是上层配置，不是技能本体。

三条主线

A. 准入：要不要为它做一个新技能（先走五问，别直接动手）

完整判据与「好好说话」的真实产生范例见 references/admission-gate.md。五问全部过才建：

1. 需求成立吗：高频反复的痛；或低频但高重要、且长期解决不了。不痛、只是"看起来不错"，不建。
2. 该归因到哪一层：先判断问题是模型能力、Harness 常驻规则、工具/脚本、还是技能方法层。只有"该归技能层、且现有技能接不住"才继续；该在别的层解决就别动技能。
3. 业界方案能不能直接用：先找现成的。能直接用就用；好用但有平台绑定→炼化成自有；评测过确实不行（会改错原意、降准确性等硬伤）才自研。不许没评测就重造轮子。
4. 值得独立且不打架吗：一句话唯一性检验；放进流向图看上下游——会不会和现有技能抢触发、规则冲突、甚至结论互相矛盾。同一件事就合并，不新建。
5. 能持续吗：先定成功判据和质量关，预留评测/召回回路；技能不是建完即满分。

任意一问答"否/不是"：给出"不做的理由 + 已有的正确承接方"。判不准就标观察项，等真实需求反复出现。

B. 健康体检：现有技能集合配不配得健康

检查项与三层分工（静态脚本 / 人工语义 / Harness 动态）见 references/health-check.md。 先用脚本静态扫描，再人工判读：

python3 scripts/library_doctor.py <技能库目录>                 # 全量静态扫描
python3 scripts/library_doctor.py <目录> --baseline baseline.json   # 只报基线外的新增问题
python3 scripts/test_doctor.py                                # 先验证体检本身有效（正反夹具）

脚本能稳定查的（frontmatter/命名、description 路由信号、broken reference、围栏闭合、 正文平台硬绑定、超长/真孤儿/空壳占位/疑似密钥，以及库级的覆盖真空 C003 / 悬空技能交接 C001）都带规则 ID； 语义项（退出条件、有限重试、可观察触发、规则矛盾、真实撞车、覆盖真空是否成立）不写正则，靠人工用真实 query 判断；真实触发率等动态项归 Harness。

静态体检关注：

• frontmatter/命名：缺 name/description、重名、name 与目录不符、描述超长/含尖括号、YAML 非法。
• 路由质量：description 有没有写清「何时触发 + 边界 + 用户原话样例」。
• 引用完整性：SKILL.md 正文指向的本地文件是否存在（broken reference）、代码围栏是否闭合。
• 平台硬绑定：正文有没有写死绝对路径/宿主目录（README 安装示例不算）。
• 结构卫生：正文超长、真孤儿 reference、空壳占位文件、疑似硬编码密钥。

体检产出是一张「问题 → 证据（文件+字段）→ 建议动作（合并/改名/去绑定/补边界/弃用）」的清单，不擅自改技能。

C. 收录与炼化外部技能

三种决策，记录理由：

• 直接用：质量够、无绑定、与现有不撞 → 登记进库或直接引用，不复制。
• 炼化：内核好但有平台绑定/风格不合 → 保留方法、剥掉宿主专属引用与默认交付、改成中性降级；炼完必须过 A 的第 4、5 问（不打架、有质量关）。
• 重造：评测证实有硬伤 → 先剖析它为什么不行（必要时写清根因），再自建；避免重蹈其覆辙。

标准工作流

1. 确定技能库根目录（按零依赖原则发现，不猜路径）。
2. 判断任务属于 A / B / C 哪条主线。
3. A、C：先收集需求证据（频率、痛点、现有承接、外部方案评测），按五问给结论，不通过就明确说不做。
4. B：先跑 library_doctor.py 静态扫描，再人工补"规则矛盾/实际触发率"这类脚本看不出的判断。
5. 给出结构化结论；若判定要落地编写，移交给 skill-creator 类技能（没有就按目标技能自己的规范写）。
6. 任何收录/炼化/合并后，更新库的关系图与同步分发（若库提供这些资产/脚本）；没有就只提示用户手动更新。

输出骨架

技能库根目录：……（如何发现的）
本次事项：准入 / 体检 / 收录炼化
结论：做 / 不做（含理由）/ 体检发现 N 项
五问或体检表：逐条，附文件证据
正确承接方或建议动作：……
后续：交给 skill-creator？需要更新关系图/同步吗？

防失败模式（硬规则）

• 禁止为做而做：五问不过必须说不做，并给承接方；不因为"看起来高级"放行。
• 禁止越层：问题该归模型/Harness/脚本层时，不硬塞成技能。
• 禁止没评测就重造：自研前必须有外部方案评测结论。
• 禁止写死路径/平台：库位置一律可发现或传参；平台能力只能可选增强。
• 不擅自改动技能：体检只出报告和建议，合并/删除等动作需用户拍板。
• 不管理范围外技能：公司内部/第三方技能默认不动，除非用户明确把它们纳入本次范围。
• 结论可迁移：建议不依赖"必须用某宿主"才成立。

交付前自检

• 库根目录是发现/传入的，不是内置绝对路径。
• 准入走了五问，且给了"不做也有正确承接"的退路。
• 收录/炼化明确区分了直接用、炼化、重造三档并给理由。
• 体检结论有文件/字段证据，动作建议具体且不越权。
• 新增技能已检查与现有技能的触发、规则、上下游关系。
• 全程没有把某平台写成必需依赖。