メニュー
将纠错经验沉淀为持久化的 Rules/Skills 更新，构建反馈闭环。当被用户纠正且错误具有模式性时自动触发，或通过 /reflect 命令手动触发回顾。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | self-refinement |
| description | 将纠错经验沉淀为持久化的 Rules/Skills 更新，构建反馈闭环。当被用户纠正且错误具有模式性时自动触发，或通过 /reflect 命令手动触发回顾。 |
从错误中构建反馈闭环：将非结构化的错误经验转化为结构化的持久化上下文（Rules/Skills），防止同类错误在新会话中重复发生。
原理：LLM 没有跨会话的持久记忆——会话 A 中被纠正的错误，在会话 B 中会以相同概率再次发生。唯一的解法是将错误经验外化为持久化的上下文。
触发条件：AI 在协作过程中被用户纠正（用户否定了 AI 的输出并给出了正确方向）。
行为：
输出格式：
---
💡 **经验沉淀建议**
刚才的纠正揭示了一个可沉淀的模式：
- **错误模式**：[简述 AI 犯的错]
- **根因**：[规范缺失 / 知识缺失 / 流程遗漏 / 模式错误]
- **建议**：[更新 Rule/Skill 的具体操作]
是否需要我执行？（回复"沉淀"执行，或忽略继续当前工作）
设计原则：
触发条件：用户通过 /reflect Command 主动发起。
行为：
无论自动还是手动触发，共享同一个核心流程：
回顾对话中 AI 被纠正的场景，提取：
| 根因类别 | 定义 | 典型表现 |
|---|---|---|
| 规范缺失 | 现有 Rules/Skills 中没有覆盖该场景 | AI 不知道项目的特定约定 |
| 知识缺失 | AI 缺少项目特定的领域知识 | AI 对某个模块的行为/限制不了解 |
| 流程遗漏 | Workflow Skill 中缺少关键步骤或检查点 | AI 跳过了应有的验证步骤 |
| 模式错误 | AI 应用了错误的思维模式 | AI 用类比代替第一性原理推导 |
搜索现有 Skills 和 Rules：
每条建议包含：
### 建议 N: [简短标题]
- **根因**：[规范缺失 / 知识缺失 / 流程遗漏 / 模式错误]
- **目标文件**：`[Rules/Skills 文件路径]`
- **操作**：[新建 / 在 X 位置添加 / 修改 Y 内容]
- **具体内容**：
[要添加或修改的具体文本]
建议数量：≤ 3 条。多于 3 条时，按影响范围排序取 Top 3。
以上是本次经验沉淀建议，请选择：
- **全部执行** → 我将依次执行所有建议
- **选择执行** → 告诉我执行哪几条（如"执行 1 和 3"）
- **跳过** → 不执行任何建议
用户确认后，更新现有文件或创建新文件，并写入对应的 Rules/Skills 更新内容。
| 规则 | 说明 |
|---|---|
| 建议优先 | 不自主执行任何 Rules/Skills 修改，必须经用户确认 |
| 不打断 | 自动触发时，建议附在回复末尾，不打断当前工作流 |
| 轻量化 | 自动触发时，建议控制在 3 条以内，每条不超过 5 行 |
| 可追溯 | 每条建议明确标注根因类别和目标文件 |
| 不重复 | 执行前检索现有 Rules/Skills，避免重复添加相似规则 |
| ❌ 错误做法 | ✅ 正确做法 |
|---|---|
| 被纠正后立即修改 Rules/Skills | 先完成当前任务，再提建议 |
| 输出冗长分析 / 建议过于宽泛 | 每条建议 ≤ 5 行，具体到文件和内容 |
| 自主执行变更 / 打断工作流 | 等用户确认；附在回复末尾 |
代码文件修改的统一入口。当用户请求任何代码变更（新功能、优化、Bug 修复、重构）时必须首先调用此 skill。仅适用于代码文件（如 .cc/.cpp/.h/.go/.py 等），修改 .md 等非代码文件时不需要调用。它会评估复杂度、检查 spec.md、生成 tasks.md、并逐个任务执行。
测试生成。基于 spec.md 或被测代码，生成单元测试、集成测试、性能测试。当用户请求生成测试、TDD 模式、或 workflow-code-generation 完成后触发。
问题排查。当用户遇到编译错误、运行时异常、单测失败、流水线报错、现网告警等需要定位问题时触发。
代码评审。协调 5 个专项 reviewer subagent 对代码进行并行多维度审查。可由用户直接触发，也可由主 agent 加载后作为 Judge 执行。
需求澄清。只负责明确"要解决什么问题"，生成 spec.md 的前三章节（背景、目标、需求）。禁止在本阶段讨论设计方案——设计是 workflow-system-design skill 的职责。
系统设计。当 spec.md 前三章节（背景、目标、需求）已完整但设计章节为空时调用。按 spec.md 章节顺序逐个与用户讨论，每轮只处理一个 section。