feat(fixds): 新增 DeepSeek Flash 模型行为约束 skill

把一次会话复盘中确认的浪费动作固化为硬规则，面向 DeepSeek Flash /
DeepSeek V4.1 Flash：先验证再实现、搜索必须有边界、只在被要求的范围内动作
（改项目外目录先问）、命令一次写对、测试按影响面、要求与实测冲突时报告并
等待确认而不擅自改需求。

不设运行时模型判定，只在 description 与正文标记适用范围，避免留出「模型标识
不匹配就不遵循」的逃生口。真实案例与代价放在 references/anti-patterns.md。

skills/fixds/references/anti-patterns.md

@@ -0,0 +1,56 @@
+# 浪费案例与正确做法
+
+本 skill 的来源是一次真实会话的复盘，判定标准是「该动作对结论有没有贡献，能不能避免」。
+规则正文在 `SKILL.md`，本文件解释每条规则为什么存在。
+
+## 案例 1：先实现后验证（代价最高）
+
+- 多余动作：用户指定了新格式 `20260918T1722`，于是把生成脚本、README、契约文档、测试
+  全部按该格式改完，之后才去验证排序语义。
+- 结果：验证发现该格式在同一天会小于旧格式包（Debian 把字母排在标点之前），同一批文件
+  全部重写一遍。
+- 正确做法：拿到格式先用一条 `dpkg --compare-versions` 比对真实旧包与候选格式，确认排序
+  语义成立，再动手写代码、文档与测试。一条命令的成本 vs 整套返工。
+- 附带教训：验证结果只用于「向用户报告并给选项」，不代表可以替用户改需求。
+
+## 案例 2：无边界扫描
+
+- 多余动作：`grep -rln <模式> /home/<user>`、`find /home/<user> -maxdepth N` 用来找分支、
+  查找第三份脚本副本。
+- 结果：连续三次因输出过大或命中会话日志被中断，零有效产出，还占掉多轮交互。
+- 正确做法：搜索限定在已知代码目录、精确路径或 `git ls-files`；`find` 先确认目标深度。
+  用户家目录下的会话记录、缓存、`node_modules` 不该进入扫描范围。
+
+## 案例 3：根因已定后继续追无关线索
+
+- 多余动作：根因（版本精度不足 + 字符串排序）已确认后，逐仓库执行 `git branch -a`、
+  翻 `packed-refs`、查看多个仓库，试图找出「是哪个项目产出的包」。
+- 结果：对结论零贡献，多轮浪费。
+- 正确做法：定位生成脚本（一次精确搜索即可）≠ 定位项目。需要项目信息时直接问用户，
+  或只在用户指明的目录里找。
+
+## 案例 4：主动扩大改动范围
+
+- 多余动作：用户只要求修本仓库，却顺手把另一仓库里的 vendored 副本一起改了，还想继续
+  找「是否还有第三份副本」。
+- 结果：用户明确质疑越权；改动随后被撤销。
+- 正确做法：改本项目之外的目录前，先判断必要性并向用户确认；用户没点名的仓库不动。
+
+## 案例 5：自造的返工
+
+- 排序脚本方向写反、把说明性注释写进版本号字符串导致工具报语法错误、把注释插入函数调用
+  参数中间导致语法错误、时间戳算错（当地 10:00 记成 02:00）、断言方向写反。
+- 每一项都多花一轮重跑。
+- 正确做法：算完先打印一次确认；注释放在语句之外；小样本先跑通；结果异常先怀疑自己的
+  输入，而不是先怀疑结论。
+
+## 案例 6：测试范围失控
+
+- 多余动作：只改了某个子目录，却跑了全量测试（数百个），随后排查其中几个与本改动无关的
+  失败（失败测试只读取另一个未改动的目录）。
+- 正确做法：按 diff 影响面选择测试范围；无关失败只在汇报里说明，不投入排查轮次。
+
+## 使用方式
+
+开工前过一遍 `SKILL.md` 的 4 问；交付前过一遍自检。发现新的浪费模式时，把案例补进本文件，
+并检查是否需要在 `SKILL.md` 增加或收紧一条规则。