skill-curator

name	skill-curator
description	技能提炼器——从调试会话中提取可复用技能，整合记忆并自我优化
metadata	{"type":"skill"}

技能提炼与记忆管理

触发条件

自动触发（无需用户显式调用）：

• 单次会话中工具调用超过 5 次后，在会话结束前自动评估是否可提炼为新技能或更新现有技能
• 检测到与已有踩坑记录匹配的故障模式时自动提醒

用户显式触发：

• "记住这个解决方法"
• "把这个流程提炼成技能"
• "更新板卡XX的踩坑记录"
• "整理一下记忆，有些内容重复了"
• "优化现有技能"

核心能力

1. 会话后自动提炼

触发阈值：当单次会话中发生以下情况时，启动提炼评估：

条件	说明
工具调用 ≥ 5 次	任务复杂度达到提炼门槛
解决了新的故障模式	新的踩坑知识
用户明确表达"记住"意图	直接触发
跨多个技能协作完成任务	可能产生新的组合工作流

提炼流程：

                         ┌──────────────────────┐
                         │ 会话达到提炼阈值      │
                         └──────────┬───────────┘
                                    │
                         ┌──────────▼───────────┐
                         │ 分析会话工具调用链    │
                         │ 提取关键决策点        │
                         └──────────┬───────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
           ┌────────▼──────┐ ┌─────▼──────┐ ┌──────▼────────┐
           │ 是新的故障模式?│ │是新工作流? │ │是踩坑经验?    │
           └───────┬───────┘ └──────┬─────┘ └──────┬────────┘
                   │ Yes            │ Yes           │ Yes
        ┌──────────▼──────┐ ┌──────▼────────┐ ┌───▼───────────────┐
        │写入 hardware-   │ │提议创建新 skill│ │写入对应板卡       │
        │debug 知识库     │ │或更新已有 skill│ │board-manager 的   │
        │                 │ │                │ │pitfalls 字段      │
        └─────────────────┘ └────────────────┘ └───────────────────┘

提炼输出格式（向用户提议，不自动执行修改）：

## 🔧 技能提炼建议

本次会话中发现以下可复用内容：

### 建议 1: 新踩坑记录 → board-manager
- 板卡: [板卡别名]
- 标题: [故障简述]
- 受影响的技能: hardware-debug, embedded-fullstack

### 建议 2: 新工作流 → 潜在新技能
- 流程: [从A到B到C的步骤序列]
- 重复使用可能性: [高/中/低]
- 建议技能名: [候选名称]

是否应用以上建议？[Y/n/选择性]

2. 踩坑记录结构化管理

踩坑记录生命周期：

发现 → 记录 → 验证 → 关联到板卡 → 关联到技能 → 在相关任务中主动提示 → 解决后标记 → 退役

关联到技能的映射：

踩坑类别	主要关联技能	触发时机
芯片勘误 (Errata)	embedded-fullstack, hardware-debug	用户在目标芯片上开发时主动提示
外设驱动问题	embedded-fullstack, knowledge-query	生成相关外设驱动代码时警告
硬件设计缺陷	hardware-debug, board-manager	打开对应板卡配置时展示
编译工具链问题	embedded-fullstack	构建失败时匹配已知模式
传感器校准问题	device-connect, knowledge-query	读取传感器数据时提醒校准

3. 重复记忆整合

检测条件：

• 同一板卡的同类别踩坑记录超过 3 条 → 建议合并为"常见故障模式"条目
• 两个技能中包含重复的工作流步骤 → 建议提取为共享子流程

整合策略：

原始状态:
  pitfalls:
    - id: 1, title: "I2C SCL 锁死在低电平"            # 同一根因
    - id: 2, title: "I2C 通信一段时间后挂死"           # 同一根因
    - id: 3, title: "I2C 恢复需要重新上电"              # 同一根因

整合后:
  pitfalls:
    - id: 1
      title: "I2C SCL 锁死——综合故障模式"
      symptoms:
        - "SCL 锁死在低电平"
        - "通信一段时间后挂死"
        - "恢复需要重新上电"
      root_cause: "从设备 Clock Stretching 超时 + 主设备未实现超时恢复"
      solution: "见 skills/hardware-debug 的 I2C SCL 锁死恢复章节"
      related_ids: [2, 3]  # 退役的旧条目

4. 记忆容量管理

容量分级预警：

级别	记录总数	行动
正常	< 200 条	无操作
提醒	200-500 条	首次达到时提醒用户"当前记忆条目 N 条，建议适时整理"
压缩	> 500 条	自动分析并建议：合并同板卡重复条目、退役已解决超过 90 天的条目、按"最后引用时间"排序归档低频条目

自动压缩提案：

## 记忆容量告警

当前记忆条目: 523 条（超过建议上限 500）

### 建议操作

1. **合并重复** (可减少 ~30 条)
   - [板卡A] 的 I2C 相关踩坑 5 条 → 合并为 1 条综合记录
   - [板卡B] 的 SPI 配置问题 7 条 → 合并为 2 条（模式配置 + 时钟极性）

2. **退役已解决** (可减少 ~45 条)
   - 已解决且超过 90 天未引用的条目，自动归档到 pitfall-archive.yaml

3. **按引用频率排序** (改善检索效率)
   - 将最近 30 天未引用的条目标记为 "cold"，优先归档

是否执行以上操作？[Y: 全部执行 / 1: 仅合并 / 2: 仅退役 / 3: 仅排序 / n: 跳过]

5. 跨会话技能自我优化

优化维度：

维度	检测信号	优化动作
工作流顺序	用户在多个会话中调整过执行顺序	更新技能中的"工作流程"步骤顺序
新增诊断方法	用户在最近会话中使用了新的调试手段并成功	追加到 hardware-debug 对应章节
工具/命令更新	用户使用了新版本的工具或替代工具	更新所有引用该工具的 skill
新的已知良好配置	某配置在多个会话中被验证可靠	标记为"已验证配置"并追加到嵌入式全流程技能
废弃的工作流	某工作流在过去 30 天未被触发过	标记为"deprecated"而非删除
技能间依赖	A 技能的输出被 B 技能频繁引用	在 A 的"输出格式"和 B 的"触发条件"中增加跨技能引用

优化提案格式：

## 技能优化建议

### hardware-debug: I2C 诊断流程追加
- 检测到您在最近 3 次会话中使用了新的 I2C 诊断方法：用逻辑分析仪抓取 SDA/SCL 并计算实际 SCL 频率
- 建议追加到 hardware-debug → 核心能力 → I2C 总线异常诊断 的物理层检查中

### embedded-fullstack: 新增工具链版本
- 检测到您已升级到 arm-none-eabi-gcc 13.2
- 建议将相关技能中的编译选项 `-mcpu=cortex-m4` 等相关标志与 GCC 13.2 兼容性更新

应用这些优化？[Y/n/逐项确认]

6. 技能依赖关系管理

技能间交互图：

embedded-fullstack ←── hardware-debug
       │                    │
       │  生成驱动代码       │  调试诊断
       │  烧录固件           │  故障定位
       ▼                    ▼
device-connect ────── board-manager
       │                    │
       │  扫描连接           │  板卡配置
       │  传感器读取         │  踩坑记录
       └────────┬───────────┘
                │
         knowledge-query     skill-curator
                │                 │
                │  手册查询       │  提炼优化
                │  协议参考       │  记忆管理
                └────────┬────────┘
                         │
                   所有技能共享

当修改某技能时，自动检查受影响的关联技能，并在修改前提示用户评估影响。 关键依赖规则：

• embedded-fullstack 生成的代码中出现外设通信失败 → 触发 hardware-debug 的诊断流程
• board-manager 中记录的踩坑 → 在 embedded-fullstack 和 hardware-debug 执行时主动提示
• device-connect 扫描到的设备 → 自动匹配 board-manager 中的板卡配置
• knowledge-query 的协议/芯片参数 → 被其他所有技能引用

工具要求

• 对 ~/.sinan/ 目录的读写权限
• 能够遍历所有技能文件以建立依赖图
• 访问板卡配置文件 (~/.sinan/boards/*.yaml)
• 访问踩坑记录（嵌入在板卡配置中 + 全局 pitfall 索引）

工作流程

1. 监控：在每次工具调用后记录调用链和决策点
2. 评估：在会话自然结束或达到阈值时，分析整个会话的可提炼内容
3. 分类：将提炼内容分类为：新踩坑 / 新工作流 / 技能优化 / 记忆整合
4. 提案：生成结构化建议，由用户确认后执行
5. 执行：修改目标技能文件或板卡配置
6. 验证：确认修改后的技能文件仍然符合 SKILL.md 格式规范

安全约束

• 绝不自动修改技能文件：所有技能修改必须经过用户确认。提案阶段只输出建议，不执行变更
• 保留历史：修改踩坑记录时不删除旧条目（标记为 retired），保持可追溯性
• 避免引入错误：提炼的新工作流必须包含"验证步骤"部分，防止将未完全验证的流程固化为技能
• 边界保护：不提炼涉及破坏性操作（烧录、寄存器暴力写入、Flash 擦除）的流程为标准工作流，除非用户明确定义了安全边界
• 记忆不泄露：板卡配置中的敏感字段（WiFi 密码、密钥）不包含在踩坑记录或优化提案中
• 技能文件完整性：在修改技能文件前先做一次结构校验，确认不会破坏 YAML front matter 和 Markdown 结构

输出格式

会话提炼报告

## 会话提炼报告 — [会话日期/概要]

### 本次会话统计
- 工具调用: N 次
- 涉及板卡: [列表]
- 涉及技能: [列表]
- 解决的故障: N 个

### 提炼建议(N 条)

#### [P1] 新踩坑记录
- 目标: board-manager → [板卡名] → pitfalls
- 标题: [故障简述]
- 摘要: [3 行以内]

#### [P2] 工作流提炼
- 目标: 候选新技能 [名称]
- 描述: [工作流概述]
- 复用可能性: [高/中/低] — [理由]

#### [P3] 现有技能优化
- 目标: [技能名] → [章节]
- 变更: [优化内容概述]

### 记忆容量
- 当前: N 条 (阈值: 500)
- 建议操作: [正常 / 需要压缩]

***
是否应用以上建议？[Y:全部 / 数字选择 / n:跳过]

踩坑记录追加格式

# 追加到 boards/{alias}.yaml 的 pitfalls 列表
- id: auto_gen_YYYYMMDD_NNN
  category: "[时钟/电源/通信/传感器/工具链/其他]"
  title: "[一句话标题]"
  symptom: "[故障现象]"
  root_cause: "[根因分析]"
  solution: "[解决步骤]"
  prevention: "[预防措施]"
  related_session: "[会话标识]"
  date: "[自动填入当前日期]"
  resolved: true/false