技能审计与缺口识别
当用户表达以下需求时，使用这个 skill：
- “帮我看看这些 skill 有没有重复”
- “哪些 skill 的职责冲突了”
- “当前 skill 体系还缺什么”
- “帮我做一次 skill 审计”
- “帮我优化当前 skill 结构”
设计目标
这个 skill 不负责执行业务流程，而是负责审计当前工作区 skill 体系的健康度，重点检查：
- 重复能力
- 职责边界冲突
- 类型覆盖缺口
- 可精简或可拆分的地方
- 哪些问题应优先处理
- 如何形成可执行重构路线图
审计范围
默认检查：
skills/**/SKILL.md
默认排除：
.github/skills/**skills/*GUIDE*.mdskills/*OVERVIEW*.mdskills/*TAXONOMY*.mdskills/*TEMPLATE*.md
审计方法
1. 先读取 skill 基础信息
每个 skill 至少分析：
- name
- description
- 适用场景
- 工作流程
- 输出要求
2. 判定重复能力
如果两个或以上 skill 同时具备以下特征，应判为“可能重复”：
- 服务同一类用户意图
- 产出高度相似的结果
- 工作流程差异很小
- 缺少明确主次职责区分
输出时要区分：
完全重复：几乎可以合并部分重叠：可以共存，但需明确边界
3. 判定职责冲突
如果两个 skill 都声称自己是同类任务的主处理 skill，且没有明确协作分工，应判为“职责冲突”。
常见冲突包括：
- 都想做日报主入口
- 都想做定时编排主入口
- 都想做机会缩圈主入口
4. 判定覆盖缺口
按 ../SKILL_TYPE_TAXONOMY.md 审查以下类型是否缺失或偏弱：
analysis-reportingopportunity-selectionrisk-controlworkflow-orchestrationskill-governanceexecution-supportdelivery-integration
5. 输出优化建议
每个发现的问题，都应配一条可执行建议，例如：
- 合并
- 拆分
- 明确主次职责
- 增加协作说明
- 新增缺口类型 skill
6. 给出处理优先级
每个发现的问题，不要只说“有问题”，还要标明处理优先级：
P0：已经造成明显主责冲突，继续扩展会加剧混乱P1：重复能力较高，短期内应明确边界或合并P2：存在优化空间，但不影响当前整体可用性
判定优先级时优先考虑：
- 是否影响用户触发时的 skill 选择稳定性
- 是否导致两个 skill 同时争夺主入口
- 是否已经阻碍后续新增 skill 的扩展
7. 生成重构路线图
审计结果不要停在“发现问题”，还应把建议整理成 3 段式路线图：
立即处理：本轮就应修改的职责冲突或命名问题下一轮处理：应在新增 skill 前完成的边界梳理或能力拆分后续增强：等业务稳定后再补的治理或集成能力
路线图中的动作建议应尽量具体，例如：
- 修改某个 skill 的 description
- 给两个重叠 skill 增加主次分工说明
- 新增一个缺口类型 skill
- 把散落能力从现有 skill 中拆出为独立 skill
输出要求
至少输出以下 4 部分：
一、重复能力审计
- 哪些 skill 高度重叠
- 重叠点是什么
- 是应合并还是保留边界
二、职责冲突审计
- 哪些 skill 存在主责冲突
- 冲突点是什么
- 应如何重新划分主责
三、覆盖缺口审计
- 哪些类型已覆盖
- 哪些类型仍缺失
- 哪些类型虽然存在但偏弱
四、结构优化建议
- 哪些可以保留
- 哪些应重命名或改描述
- 哪些应新增
五、处理优先级
- 每个问题的
P0 / P1 / P2 - 为什么是这个优先级
- 如果暂时不处理，会带来什么代价
六、重构路线图
- 立即处理什么
- 下一轮处理什么
- 后续增强什么
审计时的约束
- 不要为了显得专业而强行说有冲突。
- 如果只是部分重叠，应优先建议“明确边界”，而不是直接合并。
- 如果类型空缺是真实存在，要直接指出，不要绕开。
- 如果当前 skills 数量不多，也照样要给出真实审计结果。
- 不要把所有问题都打成高优先级，优先级必须拉开。
- 重构路线图要能落到具体修改动作，不能只写抽象方向。
与其他治理 skill 的关系
skill-registry-manager偏盘点、分类、协作路由skill-audit-manager偏审计、冲突识别、缺口分析
两者可协作，但职责不同。
