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

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

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

skills/fixds/README.md

@@ -5,6 +5,7 @@
 
 ## 什么时候使用
 
+- 你时间紧、只想快拿到结果，希望它别把轮次花在无关探索上。
 - 你正在用 DeepSeek Flash / DeepSeek V4.1 Flash 之类的模型，希望它先验证再动手、
   不乱扫文件、不擅自改你的要求或别的仓库。
 - 你想手动给当前会话加上这套约束：直接说 `fixds` 或「按 fixds 规则来」。
@@ -28,9 +29,11 @@ fixds：这轮按约束做，先把要跑的验证命令给我看，再动代码
 ## Agent 会做什么
 
 1. 开工前回答四个问题：命令范围、是否已验证语义、是否与要求一致、路径是否属于本项目。
-2. 按六条硬规则执行：先验证再实现、搜索有边界、只改被要求的范围、命令一次写对、
+2. 把每个动作、每次追问、每段输出都压在「能缩短拿到结果的时间」上：先给结论和证据、
-   测试按影响面、冲突时报告并等待确认而不是自行改需求。
+   独立命令一起发、能自查的不问你、同一事实不重复、无关线索不展开。
-3. 交付前自检：需求一致性、改动范围、验证证据。
+3. 按七条硬规则执行：每轮都逼近结论、先验证再实现、搜索有边界、只改被要求的范围、
+   命令一次写对、测试按影响面、冲突时报告并等待确认而不是自行改需求。
+4. 交付前自检：需求一致性、改动范围、验证证据。
 
 ## 如何判断完成
 

skills/fixds/SKILL.md

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

skills/fixds/references/anti-patterns.md

@@ -1,7 +1,7 @@
 # 浪费案例与正确做法
 
-本 skill 的来源是一次真实会话的复盘，判定标准是「该动作对结论有没有贡献，能不能避免」。
+本 skill 的来源是一次真实会话的复盘，判定标准是「该动作对结论有没有贡献，能不能避免」，
-规则正文在 `SKILL.md`，本文件解释每条规则为什么存在。
+以及用户在等结果上付出的时间。规则正文在 `SKILL.md`，本文件解释每条规则为什么存在。
 
 ## 案例 1：先实现后验证（代价最高）