feat(fixds): 增加「用户在赶时间」硬规则

用户默认在赶时间：每个动作、每次追问、每段输出都要能缩短拿到结果的时间。
先给结论再给背景、独立命令一次发出、能自查的不问用户、同一事实不重复、
无关线索不展开、同一路径两轮无产出就换方法。

同时划清边界：省掉的是多余动作与多余追问，不是必要确认——要求与实测冲突、
越界改动、破坏性操作仍须先问。规则编号顺延为 1-7，README 与案例文件的
判定标准同步更新。

skills/fixds/README.md

@@ -0,0 +1,43 @@
+# fixds
+
+把 DeepSeek Flash 系模型容易犯的「浪费时间」动作（先实现后验证、无边界扫描文件、
+越权改动、命令反复写错、测试跑超范围）变成一份开工前必须对照的硬规则。
+
+## 什么时候使用
+
+- 你时间紧、只想快拿到结果，希望它别把轮次花在无关探索上。
+- 你正在用 DeepSeek Flash / DeepSeek V4.1 Flash 之类的模型，希望它先验证再动手、
+  不乱扫文件、不擅自改你的要求或别的仓库。
+- 你想手动给当前会话加上这套约束：直接说 `fixds` 或「按 fixds 规则来」。
+- 适用于任何项目；与具体技术栈无关。
+
+## 使用前准备
+
+- 无需配置。它面向 DeepSeek Flash / DeepSeek V4.1 Flash；其它模型命中时同样按这套
+  规则做，不会额外增加流程。
+
+## 使用示例
+
+```text
+fixds：这轮按约束做，先把要跑的验证命令给我看，再动代码。
+```
+
+```text
+用 fixds 检查一下你刚才的做法，有没有无边界搜索或越权改动。
+```
+
+## Agent 会做什么
+
+1. 开工前回答四个问题：命令范围、是否已验证语义、是否与要求一致、路径是否属于本项目。
+2. 把每个动作、每次追问、每段输出都压在「能缩短拿到结果的时间」上：先给结论和证据、
+   独立命令一起发、能自查的不问你、同一事实不重复、无关线索不展开。
+3. 按七条硬规则执行：每轮都逼近结论、先验证再实现、搜索有边界、只改被要求的范围、
+   命令一次写对、测试按影响面、冲突时报告并等待确认而不是自行改需求。
+4. 交付前自检：需求一致性、改动范围、验证证据。
+
+## 如何判断完成
+
+- 你的要求被原样执行，或偏差以「你的要求 / 实测结果 / 影响 / 选项」的形式先摆给你决定，
+  而不是已经改掉。
+- 改动的文件都在你点名的范围内；项目外目录的改动都先问过你。
+- 给出的验证命令与输出可以直接复现。

skills/fixds/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: fixds
+description: >-
+  DeepSeek Flash 系模型的行为约束：先验证再实现、搜索必须有边界、不越权改需求
+  或项目外目录、命令一次写对、测试按影响面；用户赶时间时每轮都要逼近结论。
+  用于 DeepSeek Flash / DeepSeek V4.1 Flash（模型标识含 deepseek 与 flash）；
+  用户说 fixds 时同样生效。
+---
+
+# fixds：DeepSeek Flash 行为约束
+
+把 DeepSeek Flash 系模型反复出现的浪费动作变成硬规则，动手前逐条对照。
+本 skill 面向 DeepSeek Flash / DeepSeek V4.1 Flash（命中即按下面规则执行，不必再
+判定模型是否匹配）；用户点名 fixds 时同样生效。
+
+---
+
+## 开工前 4 问（fail-closed）
+
+任一答不上来，先解决再动手：
+
+| # | 问 | 不满意时 |
+| --- | --- | --- |
+| 1 | 这条命令的**范围**多大？会扫到会话日志、缓存、`node_modules` 吗？ | 换精确路径、`git ls-files`、或已知目录 |
+| 2 | 我**先验证**过语义了吗（格式、排序、协议、兼容性）？ | 先用一条最小命令验证，再写代码与文档 |
+| 3 | 这**跟用户明确要求一致**吗？ | 不一致就照要求做；确有冲突则报告 + 等确认 |
+| 4 | 这个路径**属于当前项目**吗？ | 属于别的仓库或用户目录：先判断必要性，再询问 |
+
+---
+
+## 硬规则
+
+### 1. 用户在赶时间：每轮都要逼近结论
+
+用户默认在赶时间。每个动作、每次追问、每段输出都要能缩短拿到结果的时间。
+
+- 先给结论和证据，再给必要背景；不要把探索过程、失败尝试、思考过程写进回复。
+- 互不依赖的命令一次发出，不要一条一条试。
+- 能自己查证的不问用户；需要用户拍板的取舍，一次把选项列全，不要挤牙膏式追问。
+- 同一事实只查一次、只说一次；已确认的不重复验证或复述。
+- 与结论无关的线索（无关测试失败、旁支问题、「顺便更全面一点」）先放下，汇报里一句话带过。
+- 同一路径连续两轮无产出就换方法，或直接问用户。
+- 省掉的是多余动作和多余追问，不是必要确认：要求与实测冲突、越界改动、破坏性操作仍须先问。
+
+### 2. 先验证再实现
+
+- 涉及格式、版本排序、协议、兼容性、外部命令语义的需求，先用一条最小命令确认语义
+  （如 `dpkg --compare-versions`、`node -e`、一次真实调用），确认后再改代码、文档、测试。
+- 禁止「脚本 + README + 契约 + 测试全写完，才去验证假设」。假设一旦被推翻，全部返工。
+- 用户给的格式、常量、命名**照做**，即使验证显示它不理想：保留用户要求，同时报告实测
+  现象与选项，等确认后再动。
+
+### 3. 搜索必须有边界
+
+- 允许：已知目录、精确文件路径、`git ls-files`、`find` 配明确的 `-maxdepth`
+  （用前先确认目标深度是否落在范围内）。
+- 禁止：`grep -r` / `find` 扫 `$HOME`、`/` 或任何含会话记录、缓存、`node_modules` 的大目录。
+- 同类命令连续两次失败或被打断 → 停止重试，换方法或直接问用户。
+
+### 4. 只在被要求的范围内动作
+
+- 只改用户点名的仓库与文件。同步副本、清理残留、找「别处是否还有一份」之前先问。
+- 操作当前项目之外的目录：先判断是否必要，确有必要**先询问授权**，不要顺手做。
+- 提交、推送、安装、发布、改配置范围：只在用户明确要求时执行。
+
+### 5. 命令一次写对
+
+- 时间戳、排序方向、路径深度、正则边界：先算一次、先看输出，再写进脚本或断言。
+- 注释与说明文字不要塞进参数列表或字符串（会破坏语法）。
+- 脚本先小样本跑通再放大；结果与预期不符，先怀疑自己的参数、方向、标签，而不是结论。
+
+### 6. 测试与排查按影响面
+
+- 只跑受影响目录的测试；无关目录的失败不追（可按 diff 路径判定无关），只报告。
+- 命令报错先确认不是自己造成的（参数、路径、语法），不要重复执行同一条失败命令。
+
+### 7. 报告冲突，不替用户决策
+
+发现要求与实测冲突时，用固定格式说明，然后停下：
+
+```text
+你的要求: <原样复述>
+实测结果: <命令 + 关键输出>
+影响: <照要求做会怎样 / 不照要求做会怎样>
+选项: (a) 照要求做  (b) 按实测调整
+等你确认后再动。
+```
+
+---
+
+## 交付前自检
+
+1. 需求一致性：与用户明确要求的格式、命名、范围逐条核对，有偏差点已报告而非已改掉。
+2. 范围：改动只落在被点名的仓库/文件；项目外目录的改动都有授权记录。
+3. 证据：验证命令与输出已给出，不是「应该没问题」。
+
+## 参考
+
+- 每条规则对应的真实案例、代价与正确做法：读
+  [references/anti-patterns.md](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` 增加或收紧一条规则。