ds-lessons 是一个给 AI 编码智能体使用的技能，核心观点是：智能体可以跳过的指令只是愿望，只有让重复错误直接失败，才能真正改变行为。
用途 它针对的是同一仓库中智能体反复犯的同类错误。做法不是继续写更多提示词或规则，而是把每类错误转成结构性的约束，优先采用类型、Lint/CI 检查、测试等可自动验证的手段，最后才用文档或智能体规则处理无法检查的判断性问题。
主要流程
- 收集错误：阅读当前会话、近期提交、回滚记录、评审意见、智能体指令文件和工作区中绕行方案的注释，把错误按类别分组；同一类出现两次才计为一类。
- 为每类选择有效且层级最高的做法，顺序为：
- 结构：同一状态只有一个归属，同类任务只保留一种受支持做法，隐藏内部细节，删除智能体会照抄的旧模式。
- 类型：让错误状态无法被写出。
- Lint 或 CI 检查：错误信息应指明应使用的正确文件、类型或函数；若坏模式已很普遍，只对新增加的部分报错。
- 测试：检查行为而非内部实现。
- 文档或智能体规则：只用于无法自动检查的判断性场景，并附一个失败示例。
- 优先修复出现频率最高的类别，每类单独一个提交。
- 验证每个新检查：重新引入一个真实发生过的历史错误，运行检查并展示其失败；再移除该错误并展示通过。
- 在智能体指令文件中维护一张表，列出规则及其执行方式；若规则早已存在但从未被执行，视为重复错误并立即补上执行手段。
- 会话结束时反思：列出出错项、多花循环的项和用户纠正的项，分别归入检查、技能修改或规则；一次性问题直接丢弃。
停止条件 每个选定类别都有被证明能在真实错误上失败的强制手段；或者本次会话已处理排名前三的类别，其余记录在案。
规则 若修复属于结构性改动，就不要再补充说明文字，因为文字本身只是症状。报告每类错误时需给出证据、所选层级以及更高层级为何不可行的理由。
适用场景 适用于有智能体参与开发、错误容易重复出现、评审意见反复出现的代码仓库；也适合把人工纠正沉淀为可执行约束的团队。
限制 资料未提供具体安装命令、支持的平台、配置细节、收费方式或效果数据，这些信息暂未提供。该技能依赖真实错误证据和仓库访问，且需要人工判断错误类别与强制层级。