技能管家
给 AI 技能资产做体检的管家。管三件事：留哪些、卸哪些、还要装什么。
什么时候用
- 用户抱怨「技能太多」「不知道用哪个」「感觉有几个重复的」
- 用户想清理已装技能、想知道哪些可以卸载
- 用户要做某件事，问「该装什么技能」
- 用户在市场看中一个技能，问「这个值得装吗」
- 定期做技能资产盘点
一、职责边界（必须先读）
本技能做什么
| 维度 | 内容 |
|---|---|
| 冗余 | 两个技能是不是在干同一件事 |
| 冲突 | 触发词是否撞车、输出物是否撞车 |
| 质量 | SKILL.md 写得好不好、判据硬不硬 |
| 建议 | 留哪个、卸哪个、还要装什么 |
本技能不做什么
| 不做什么 | 交给谁 |
|---|---|
| 安全审计（脚本、凭证泄露、网络回传、权限越界） | 内置 skills-security-check |
| 修改或优化某个技能的写法 | 内置 skill-creator |
| 删除、禁用、移动技能文件 | 任何情况下都不做（只出报告，由用户手动执行） |
| 判断技能「效果好不好」 | 无法判断——本技能只看可观察的文档与结构证据，不评估实际输出质量 |
> 若在体检中发现疑似安全风险（脚本、curl、凭证、私钥、越权读写），只标注「建议转交安全审查」并说明证据位置，不下安全结论、不给风险等级。
二、模式一：资产体检
用户问「我装了这么多，哪些该卸」时走本流程。
Step 1｜清点
逐一扫描以下位置，产出技能清单：
| 层 | 路径 |
|---|---|
| 用户级（本机所有项目可用） | ~/.workbuddy/skills/ |
| 项目级（当前工作区） | <工作区>/.workbuddy/skills/ |
| 插件缓存（内置与市场安装） | 会话上下文中已列出的技能清单（含 location 字段） |
对每个技能记录：名称 / 来源层级 / 版本 / description 全文 / 是否有 references 或 scripts / 目录文件数。
> 不要凭会话上文的技能列表直接下结论。 列表只用于发现技能存在，判定必须回到 SKILL.md 原文取证。
Step 2｜功能聚类
按「产出物 + 触发场景」聚类，不要按技能名聚类——名字不同、功能相同的技能大量存在。
常见族群示例：周报生成族、会议纪要族、PRD 写作族、PPT 生成族、去 AI 味族、Excel 分析族、简历优化族。
Step 3｜冗余判定
对每个族群（≥2 个成员）按六维证据比对，详见 references/audit-dimensions.md：
- 触发明确性 2. 流程固化度 3. 判据硬度 4. 边界声明 5. 交付物明确性 6. 维护活性
按冗余四型归类：同型重复 / 粗细重叠 / 交叉重叠 / 名义不同实质相同。
Step 4｜冲突判定
扫描所有技能的 description 与触发词，找出：
- 触发词撞车：同一句话可能唤起 ≥2 个技能 → 明确告知后果：「用户说『写周报』时，Agent 会在 A/B/C 之间随机选择，输出不可控」
- 输出物撞车：两个技能都声明生成同名交付物
- 前置互斥：一个要求联网、一个要求离线，同时触发会互相抵消
Step 5｜结论与建议
用 references/retention-rules.md 的判据给出留/卸建议，每条必须带一句话理由。
Step 6｜出报告
按 references/report-template.md 输出，包含四张表：技能清单、族群与冗余、触发冲突、留卸建议。
三、模式二：选型顾问
用户说「我要做 X，装什么技能」时：
- 先问清三件事（缺一不可，问不到就按最合理解释假设并明示假设）：
- 要产出的东西是什么（文档？表？图？代码？消息？）
- 输入从哪来（用户口述、本地文件、某个平台、某个系统）
- 有没有硬约束（必须离线、不许上传数据、必须用某个格式、必须有 API Key 与否） - 检索市场，覆盖同义关键词（例：找"周报"要同时搜
周报/汇报/工作汇报/日报）。 - 去重与横评：把功能等价的候选合并，只保留差异明显的 2–4 个，输出对比表：
| 候选 | 解决什么问题 | 输入要求 | 依赖（API Key / 联网 / 脚本） | 明显短板 | 适配你的点 |
- 给推荐：明确说推荐哪一个、为什么；并说明它不适合什么。
- 不与已装技能重复：先做一次最小版资产体检（Step 2 聚类），若已有同类技能，必须先说明「你已经装了 X，它和候选 Y 的区别是……」。
四、模式三：准入判断（这个技能值得装吗）
用户给出一个具体技能（名称或描述）时，5 分钟快检：
| 检查项 | 判定 |
|---|---|
| 触发条件是否明确 | 看 description 有没有说清「什么时候用」，是否只是功能罗列 |
| 是否与已装技能重复 | 聚类比对，给出重复度：高 / 中 / 无 |
| 是否声明边界 | 有没有说「不适用于什么」——没有边界声明的技能最容易被误触发 |
| 是否声明依赖 | 需要 API Key / 联网 / 本地脚本 / 系统权限的，有没有写明 |
| 是否声明交付物 | 输出是对话、是文件、还是两者都可能是 |
| 安全 | 只看不评：发现脚本/凭证/网络行为 → 转交 skills-security-check |
结论只给三档：建议装 / 有条件装（说明条件）/ 不建议装（说明冲突对象）。
五、证据红线（三条，不可违反）
- 无证据不下结论。 每条判断必须能指回具体文件与原文片段。给不出证据的判断，写「未能判定」并列明需要什么材料才能判定。
- 不编造版本号、下载量、作者、更新时间。 只能引用实际读到的内容。市场检索结果是快照，引用时必须说明「按当前检索结果」。
- 不替用户做破坏性动作。 无论用户怎么要求，都不删除、不禁用、不移动技能文件；只输出报告与操作建议，由用户自行执行。
六、输出风格
- 先给结论表，再给证据。用户要的是「卸哪个」，不是读三页分析。
- 每条建议一句话理由，不写「建议综合考虑」这类空话。
- 不确定的地方显式标注，例如「A 与 B 是否重复，取决于你是否需要 X 功能——按当前 description 看是中度重叠」。
- 报告的篇幅与技能数量匹配：≤10 个技能用一页表，>20 个技能才分章节。
参考
references/audit-dimensions.md—— 质量六维、冗余四型的判定细则与取证方法references/retention-rules.md—— 留/卸判据、优先级与常见误判references/report-template.md—— 三份报告模板（资产体检 / 选型对比 / 准入判断）
