@hawk2048/oh-my-dsh 0.2.1 → 0.3.3

package/skills/omd-autoresearch/references/skill-survey.md

@@ -0,0 +1,158 @@
+# 外部报告类 Skill 调研结论（哪个能强化 omd-autoresearch）
+
+调研时间：2026-11-03。方法：GitHub API + raw 原文直读（web 搜索通道当时不可用）。
+可信度标注：**已核** = 读到 SKILL.md/README 原文；**仅元数据** = 只核到仓库存在、star、描述；**未找到** = 在可访问来源里没定位到，不臆测其机制。
+
+---
+
+## 一、六个指定技能
+
+### 1. huashu-report（花叔报告）· 已核
+
+`github.com/alchaincyf/huashu-report` · MIT · 482★ · 作者 alchaincyf
+规范取自 42 份顶级机构报告 PDF 的反向拆解（Stanford HAI、McKinsey、BCG、OpenAI、Anthropic、PwC、World Bank）。
+
+工作流：三问定原型 → 建数据表 → 写正文 → 补机制与文献定位 → 做图 → 逐页自检。
+
+可迁移机制：
+
+- **每个百分比必须带分母 N**，没有 N 的百分比视为不可用。
+- **图表标题写结论**，不写主题（研报型例外）。
+- **预先反驳自己四段式**：列替代解释 → 各自怎么排除 → 诚实说没排除掉的 → 主动降级结论。
+- **删除判据**：「把这句话删掉，读者对结论的判断会不会改变？不变就是工作日志，删。」
+- **附录 ≤ 正文 10%**，附录是来源表，不是数据表转印。
+- **数据源行**：区分「谁采的数」和「谁做的图」。
+- **「太干」的正解是补机制层与文献定位层**；加形容词、换口语化都不管用。
+
+它没解决的：口语化、逐句改写的机械规则（它靠原型选型与删除判据治「读不下去」）。
+
+### 2. deep-research-plus-skills · 已核（影响面小）
+
+`github.com/Asaceoo/deep-research-plus-skills` · MIT · 1★ · 作者 Asaceoo
+编排层，把 4 个调研子技能串成流水线。社区验证为零，机制可抄，别当权威。
+
+可迁移机制：
+
+- **闸门外置成脚本退出码**：`gate --stage outline|confirm|results|review|report`，0 通过 / 1 违规。
+- **大纲强制至少 1 条反方条目**（竞品反对、已知缺陷、失效场景），否则拦下。
+- **来源数下限是公式**：档位基数 + 反方加权，只搜一次就落盘会被判违规。
+- **引用是硬字段**：完整 URL + 日期 + 来源类型枚举，裸域名判 0。
+- **承重引用开页核对**：链接能打开不算数，要确认内容支撑结论。
+- **单源标 `single-source`，社区来源支撑决策级结论标 `high-risk`。**
+- **固定六章骨架，缺章不合格**；复杂度分档（light 档不产出完整报告）。
+
+### 3. industry-research · 已核（同名歧义多）
+
+`github.com/geekjourneyx/industry-research` · MIT · 33★ · 作者 geekjourneyx
+同名/近名仓库另有 5 个以上（`hehe-industry-research-skill-pack` 315★、`PerryLink/dsh-industry-research` 215★、`luopan` 390★ 等），若指的是别的版本需回退确认。
+
+核心信条：**搜索结果只是线索，不是证据。**
+
+可迁移机制：
+
+- **四层证据分层，禁止越级**：搜索结果 → 来源材料 → 推理（显式标注）→ 结论（置信度匹配证据质量）。
+- **A/B/C 证据级 + 5 个独立证据家族三角验证**；同一家族的多个信号只算一个。
+- **证据 schema 必填**：来源类型枚举、核实状态（仅检索到 / 已开页 / 已交叉）、独立性说明。
+- **时效规则**：>180 天视为陈旧，不能单独支撑当前判断。
+- **反证三问**：什么证据能证明它错？查过没有？没找到是因为结论硬，还是数据拿不到？
+- **诚实空手离场**：找不到反证就标 `DATA_INSUFFICIENT_FOR_BEAR_CASE`，禁止编造风险。
+- **篇幅三联表**：深度级别 × 目标字数 × 章节强制性。
+
+### 4. research-copilot · 已核
+
+`github.com/ptt-22/research-copilot`（3★；另有 `tririver/arc` 114★ 等相近项，未逐一验证）
+手动触发型深度调研：先定研究边界 → 读 report-framework → 多源采集 → 证据账本 → 交叉验证 → 结构化报告，默认出 MD/HTML/DOCX/PDF 四份。
+
+可迁移机制：
+
+- **来源编号制 `[S3]`**，正文引用即回指，和本技能的 `evidence.md` 同构。
+- **来源四级 A/B/C/D**，C 级只能证明「有人这样反馈」，不能证明客观事实。
+- **主张级缺口标注**：`单一来源` / `未充分交叉验证` / `来源冲突` / `未找到一手来源`。
+- **转载不算多源**：多篇转同一原始报道按一个来源计。
+- **默认深度**：≥20 个候选来源，最终引用 12–25 个高质量来源。
+
+### 5. Xiaobai-Research · 未找到
+
+在 GitHub 仓库搜索、中文关键词组合（小白 调研 skill / Xiaobai research）里都没有定位到同名项目。
+可能是本地自制、付费社群内部分发或已改名。**本技能不采用任何未核实的「小白向机制」描述**——需要用户提供路径或链接后再补。
+
+### 6. fxbaogao-deep-research · 已核
+
+`github.com/fxbaogao/fxbaogao-deep-research` · 10★ · 作者 fxbaogao（发现报告）
+方法叫「先想后搜」：明确研究边界 → MECE 拆子问题 → 按子问题定向搜研报 → 筛选核心研报精读 → 整理成事实卡片 → 对比推导 → 结构化结论。
+
+可迁移机制：
+
+- **子问题先行**：先出问题清单再检索，避免「搜到哪算哪」。
+- **中间产物模板化**：问题拆解 / 资料来源 / 事实卡片 / 对比框架 / 推导过程 / 终稿六件套，正文之前先有卡片。
+- **研报精读 playbook**：把长报告拆成可复用的抽取规则。
+
+---
+
+## 二、其他更值得抄的（本次调研新增）
+
+### 2.0 书面 / 口语表达类，单独立一条
+
+`github.com/op7418/Humanizer-zh` · 21880 星 · MIT · 已核（仓库元数据，未读规则正文）
+Humanizer 的汉化版，目标是消除中文文本里的 AI 痕迹。同类的还有 `MrGeDiao/shuorenhua`（2435 星）与英文原版 `blader/humanizer`（64268 星），三家分工不同：
+
+| 项目 | 覆盖 | 缺什么 |
+|---|---|---|
+| blader/humanizer | 英文 AI 写作特征，按强度分级 | 中文句式与黑话 |
+| Humanizer-zh | 中文 AI 痕迹，汉化后的规则集 | 未覆盖工程词外泄 |
+| shuorenhua | 中文黑话 + 可脚本化指标 + 标定方法 | 需要自备语料 |
+
+**要不要为「书面 / 口语表达」单独做一个 omd 技能？判断：不单独做。** 现有三处已经覆盖，再加一处会互相打架——写作时的用词规则在 `report-style.md`，事后清理在 `omd-ai-slop-cleaner`，外部机制来自上表三家。真正缺的那一层是语域问题：工具内部词混进给读者的正文（`报警项`、`判死`、`小疤`）。这一层不属于「表达技能」，已经补进 `report-style.md` 的「语域：三类词别混用」和 `report_lint.py` 的工程词检查。
+
+| 项目 | 规模 | 抄什么 |
+|---|---|---|
+| `blader/humanizer` | 64k★ MIT 已核 | 模式**按强度排序**：强信号单次即改，弱信号同段凑够才改；工作流固定「标 tell → 起草 → 复检」；结论是「结构习惯比词表更持久」 |
+| `MrGeDiao/shuorenhua` | 2.4k★ MIT 已核 | **可脚本化的判定从 judge 手里拿走**（句长离散度、破折号密度、留存率）；阈值必须在自己语料上标定；设误杀率门禁 |
+| `Weizhena/Deep-Research-skills` | 2.5k★ MIT 已核 | 调研编译成两个机器可读契约（大纲 + 字段），每条产出过 `validate_json.py` 才算完成，不确定值填「[不确定]」并登记 |
+| `tonyazhuuki/deep-research-skill` | 32★ MIT 已核 | 证据评鉴拆两根轴（因果是否成立 / 强度与适用性），置信度不足自动追加一轮深挖（≤2 轮），引用由脚本真去查库 |
+| `ruanyf/document-style-guide` | 13k★ 已核（许可证未核到） | 中文句长/段长/标题层级的硬数字：单句 >40 字不可接受，段落 ≤7 行，尽量避免四级标题 |
+| `Leonxlnx/unlazy` | 4.3k★ 仅元数据 | 给每个叶子节点分配完整时间预算，用结构对抗提前收尾 |
+
+采购判据（本次调研得出）：合格的调研技能至少有 ①机器可校验的产物 schema 或校验脚本 ②不确定如何标注的协议 ③人工审批闸门 ④有阈值的评分表。四条缺两条，基本是提示词空话。
+
+---
+
+## 三、采纳了什么，没采纳什么
+
+| 机制 | 来源 | 采纳 | 落在哪 |
+|---|---|---|---|
+| 篇幅档位（brief/standard/comprehensive）| industry-research、deep-research-plus | ✅ | SKILL.md 第 0 步 |
+| 证据编号 + 来源分级 + 去重 + 时效 | research-copilot、industry-research | ✅ | `report-rules.md` §1–3 |
+| 反证四段式 + 诚实空手离场 | huashu-report、industry-research | ✅ | `report-rules.md` §4 |
+| 承重引用开页核对 | deep-research-plus | ✅ | `report-rules.md` §3 |
+| 六章骨架 + 缺章不合格 | deep-research-plus | ✅ | `report-rules.md` §5 |
+| 大纲必须含反方条目，否则拦下 | deep-research-plus | ✅ | `SKILL.md` 第 3 步结构闸 + `report-rules.md` §4 |
+| 来源数下限按档位定 | deep-research-plus、research-copilot | ✅ | `SKILL.md` 第 0 步（brief 3 / standard 6 / comprehensive 12） |
+| 补「机制层 + 文献定位层」治太干 | huashu-report | ✅ | `rubric.md` D2 与 `SKILL.md` 报告硬规则 |
+| 百分比必须带分母 N | huashu-report | ✅ | `report-rules.md` §3、§6；`rubric.md` D1 |
+| 引用即硬字段（URL+日期+类型，裸域名不算） | deep-research-plus | ✅ | `report-rules.md` §1 证据表字段 |
+| 单源 / 社区来源显式标注 | deep-research-plus、research-copilot | ✅ | `report-rules.md` §3 缺口标注 |
+| 标题层级（一级下不跳三级、少用四级） | ruanyf | ✅ | `report_lint.py` 标题跳级判死 + `report-style.md` 排版表 |
+| 删除判据 + 附录 ≤10% | huashu-report | ✅ | `report-rules.md` §6 |
+| 图表标题写结论 + 数据源行 | huashu-report | ✅ | `report-rules.md` §6 |
+| 分级处置（强信号即改 / 弱信号凑够 / 只报警）| blader/humanizer、shuorenhua | ✅ | `report-style.md` 分级处置 |
+| 对偶句密度判死 + 豁免额度 | shuorenhua、ruanyf | ✅ | `report-style.md` T1-1 |
+| 句长/段长/破折号硬阈值 | ruanyf、shuorenhua | ✅ | `report_lint.py` |
+| 连词密度不设全局阈值 | shuorenhua 实测反例 | ✅（反向采纳）| `report-style.md` T3 |
+| 机器闸门脚本化 | deep-research-plus、shuorenhua | ✅ | `report_lint.py` |
+| 闸门外置成 CLI 退出码全流程 | deep-research-plus | ❌ | 依赖外部脚本，DSH 内无对应能力；改用 lint 退出码做单点闸 |
+| 契约文件 + validate_json 全流程 | Weizhena | ❌ | 与 omd-research 子代理分工重复，收益低于复杂度 |
+| 红队/蓝队/仲裁四角色 | industry-research | ❌ | 单份报告成本过高；已用「反证段 + 评估者」覆盖 |
+| 研报精读 playbook | fxbaogao | ❌ | 依赖发现报告站点 API，非通用 |
+| 四种格式同源导出 | research-copilot | ❌ | 交付格式另有 office-* 技能负责 |
+
+## 四、结论
+
+能强化 `omd-autoresearch` 的是四类机制，不是四个 skill：
+
+1. **篇幅与骨架先定**（industry-research、deep-research-plus）→ 治「太长」。
+2. **证据编号与来源分级**（research-copilot、industry-research、huashu）→ 治「不可信」。
+3. **反证层与机制层**（huashu、industry-research）→ 治「太干」，这是最反直觉的一条：加一层解释，比加形容词有效。
+4. **机器闸门 + 分级处置**（shuorenhua、blader、ruanyf）→ 治「AI 腔」，且不会误杀正常文本。
+
+Xiaobai-Research 未核实，未采纳。若有具体来源，把它补进 `report-style.md` 的误杀防护表即可。

package/skills/omd-cancel/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-cancel
-description: "取消：干净地停止进行中的编排模式——暂停目标轮次、中断后台子代理、终止任务——并留下干净的检查点。触发词：cancel / 停止 / 停下 / 取消 / 别跑了 / stop / abort。"
----
-
-# oh-my-dsh · Cancel 取消进行中模式
-
-干净地停掉正在跑的编排，留下可恢复的检查点。对应 OMC 的 `cancel` skill（触发词 stop/cancel/abort）。
-
-## 何时用
-
-- 用户说「停」「取消」「别跑了」。
-- 一个 autopilot/ralph/team/ultragoal 跑偏了，需要中断。
-
-## 取消纪律
-
-1. **盘点**：先搞清楚现在有什么在跑——`goal`（`get_goal` 查当前目标）、后台 `subagent`（`list_agents`）、后台 `job`（`job_list`）。
-2. **停目标**：`update_goal` 用 `pause`（或 `blocked`）停掉跨轮目标，别让它继续自动续轮。
-3. **停子代理/任务**：对还在跑的子代理 `interrupt_agent`，对后台命令 `job_kill`。
-4. **留检查点**：用 `remember` 或写文件记下「进行到哪、下一步从哪续」，别让进度白费。
-5. **报告**：说清停了什么、还留着什么、怎么恢复。
-
-## 与其它模式的关系
-
-- 取消不是删除：用 `cordis_stop`/`update_goal pause` 保留定义与进度，别 `undefine`/`complete` 式永久清掉（除非用户明确要删）。
-- 取消后要重来，从检查点接续；方向都变了就先 `omd-plan` 重新规划。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出取消结果：`table`（对象/动作/结果）+ `callout`（恢复方式）。让「停了什么、怎么续」一眼可见。
-
-## 反模式
-
-- 别只说「已停止」却不真正调停对应机制——goal 会继续续轮、子代理会继续跑。
-- 别把取消做成不可逆删除。
-- 别不留检查点就停，否则前功尽弃。
+---
+name: omd-cancel
+description: "取消：干净地停止进行中的编排模式——暂停目标轮次、中断后台子代理、终止任务——并留下干净的检查点。触发词：cancel / 停止 / 停下 / 取消 / 别跑了 / stop / abort。"
+---
+
+# oh-my-dsh · Cancel 取消进行中模式
+
+干净地停掉正在跑的编排，留下可恢复的检查点。对应 OMC 的 `cancel` skill（触发词 stop/cancel/abort）。
+
+## 何时用
+
+- 用户说「停」「取消」「别跑了」。
+- 一个 autopilot/ralph/team/ultragoal 跑偏了，需要中断。
+
+## 取消纪律
+
+1. **盘点**：先搞清楚现在有什么在跑——`goal`（`get_goal` 查当前目标）、后台 `subagent`（`list_agents`）、后台 `job`（`job_list`）。
+2. **停目标**：`update_goal` 用 `pause`（或 `blocked`）停掉跨轮目标，别让它继续自动续轮。
+3. **停子代理/任务**：对还在跑的子代理 `interrupt_agent`，对后台命令 `job_kill`。
+4. **留检查点**：用 `remember` 或写文件记下「进行到哪、下一步从哪续」，别让进度白费。
+5. **报告**：说清停了什么、还留着什么、怎么恢复。
+
+## 与其它模式的关系
+
+- 取消不是删除：用 `cordis_stop`/`update_goal pause` 保留定义与进度，别 `undefine`/`complete` 式永久清掉（除非用户明确要删）。
+- 取消后要重来，从检查点接续；方向都变了就先 `omd-plan` 重新规划。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出取消结果：`table`（对象/动作/结果）+ `callout`（恢复方式）。让「停了什么、怎么续」一眼可见。
+
+## 反模式
+
+- 别只说「已停止」却不真正调停对应机制——goal 会继续续轮、子代理会继续跑。
+- 别把取消做成不可逆删除。
+- 别不留检查点就停，否则前功尽弃。

package/skills/omd-debug/SKILL.md

@@ -1,35 +1,35 @@
----
-name: omd-debug
-description: "调试：复现失败，用证据定位根因，最小化修复，并用回归测试锁定。触发词：debug / 调试 / 报错 / 崩溃 / 为什么失败 / 修 bug / 排查。"
----
-
-# oh-my-dsh · Debug 结构化调试
-
-按「复现 → 定位 → 最小修复 → 回归验证」排查故障，每一步都留证据。对应 OMC 的 `debug` 工具 skill。
-
-## 何时用
-
-- 有报错/崩溃/异常行为，需要找出根因并修掉。
-- 用户说「修一下」「为什么失败」「排查这个 bug」。
-
-## 调试纪律
-
-1. **复现**：先用 `pwsh`/`bash` 拿到**确切的**报错信息（命令 + 完整 stderr + 退出码），别凭记忆。
-2. **定位**：二分缩小范围——`read` 读相关代码、`grep` 追调用链、加日志/断点式打印，把根因锁定到具体 file:line。
-3. **最小修复**：只改必要的，别顺手重构（配合 `omd-minimal-code-discipline`）。
-4. **回归验证**：补/跑一条测试证明修好了，再确认没引入新问题。
-
-## 与其它模式的关系
-
-- 定位「在哪里」用 `omd-deepsearch`；理解「为什么这么设计」用 `omd-deep-analyze`；`debug` 专注「为什么坏了 + 修好」。
-- 修完交给 `omd-review` 复核；需要反复验证的交给 `omd-verify`。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出排查轨迹：`timeline`（复现→定位→修复→验证）+ `table`（根因/文件:行/修复/回归测试）。让「坏了什么、改了什么、怎么证明好了」一眼可见。
-
-## 反模式
-
-- 别没复现就改——那是猜，不是 debug。
-- 别只看第一处报错就下结论，追到根因。
-- 别修完不验证就宣称「已修好」。
+---
+name: omd-debug
+description: "调试：复现失败，用证据定位根因，最小化修复，并用回归测试锁定。触发词：debug / 调试 / 报错 / 崩溃 / 为什么失败 / 修 bug / 排查。"
+---
+
+# oh-my-dsh · Debug 结构化调试
+
+按「复现 → 定位 → 最小修复 → 回归验证」排查故障，每一步都留证据。对应 OMC 的 `debug` 工具 skill。
+
+## 何时用
+
+- 有报错/崩溃/异常行为，需要找出根因并修掉。
+- 用户说「修一下」「为什么失败」「排查这个 bug」。
+
+## 调试纪律
+
+1. **复现**：先用 `pwsh`/`bash` 拿到**确切的**报错信息（命令 + 完整 stderr + 退出码），别凭记忆。
+2. **定位**：二分缩小范围——`read` 读相关代码、`grep` 追调用链、加日志/断点式打印，把根因锁定到具体 file:line。
+3. **最小修复**：只改必要的，别顺手重构（配合 `omd-minimal-code-discipline`）。
+4. **回归验证**：补/跑一条测试证明修好了，再确认没引入新问题。
+
+## 与其它模式的关系
+
+- 定位「在哪里」用 `omd-deepsearch`；理解「为什么这么设计」用 `omd-deep-analyze`；`debug` 专注「为什么坏了 + 修好」。
+- 修完交给 `omd-review` 复核；需要反复验证的交给 `omd-verify`。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出排查轨迹：`timeline`（复现→定位→修复→验证）+ `table`（根因/文件:行/修复/回归测试）。让「坏了什么、改了什么、怎么证明好了」一眼可见。
+
+## 反模式
+
+- 别没复现就改——那是猜，不是 debug。
+- 别只看第一处报错就下结论，追到根因。
+- 别修完不验证就宣称「已修好」。

package/skills/omd-deep-analyze/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-deep-analyze
-description: "深度分析：对代码、架构或问题做多角度、有证据支撑的分析。需要透彻推理而不是快速修补时使用；触发词：deep-analyze / 深度分析 / 分析一下 / 为什么这样 / 值得吗。"
----
-
-# oh-my-dsh · Deep-analyze 深度分析
-
-对一段代码、一个架构决策或一个问题做**多角度、带证据**的深入分析，而不是给一个速修补丁。对应 OMC 的 `deep-analyze` 提示词触发模式。
-
-## 何时用
-
-- 用户要「为什么」「值不值」「有什么隐患」，而不是「改成什么」。
-- 涉及架构/安全/性能/可维护性等多维权衡，单一视角会偏。
-
-## 分析纪律
-
-1. **扎根证据**：先 `read`/`grep` 把相关代码与历史读透，结论必须落到具体文件/行。
-2. **多角度并行**：用 `subagent` 并行从不同视角分析——架构、安全、性能、可测试性、数据流——每个子代理返回结构化发现。
-3. **显式权衡**：对每个候选方案列「利/弊/代价/风险」，别只给一个答案。
-4. **给建议**：以「若目标是 X，建议 Y」收口，并标出证据强度（确证/推测）。
-
-## 与其它模式的关系
-
-- 分析产出「为什么与权衡」，要落地成方案再转 `omd-plan`。
-- 需求本身没问清先 `omd-deep-interview`；代码在哪没摸清先 `omd-deepsearch`。
-- 只想「推理决策、不查代码」的纯思考用 `omd-ultrathink`；要看代码证据用本模式。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出分析结构：视角清单 + 每视角关键发现 + 方案权衡表。让「从哪些角度看了、各自结论、怎么取舍」一眼可见。
-
-## 反模式
-
-- 别只给结论不给证据（file:line / 引用）。
-- 别只从单一视角（比如只谈安全）下结论。
-- 别把「分析」做成「直接改」——本模式产出判断，不产出补丁。
+---
+name: omd-deep-analyze
+description: "深度分析：对代码、架构或问题做多角度、有证据支撑的分析。需要透彻推理而不是快速修补时使用；触发词：deep-analyze / 深度分析 / 分析一下 / 为什么这样 / 值得吗。"
+---
+
+# oh-my-dsh · Deep-analyze 深度分析
+
+对一段代码、一个架构决策或一个问题做**多角度、带证据**的深入分析，而不是给一个速修补丁。对应 OMC 的 `deep-analyze` 提示词触发模式。
+
+## 何时用
+
+- 用户要「为什么」「值不值」「有什么隐患」，而不是「改成什么」。
+- 涉及架构/安全/性能/可维护性等多维权衡，单一视角会偏。
+
+## 分析纪律
+
+1. **扎根证据**：先 `read`/`grep` 把相关代码与历史读透，结论必须落到具体文件/行。
+2. **多角度并行**：用 `subagent` 并行从不同视角分析——架构、安全、性能、可测试性、数据流——每个子代理返回结构化发现。
+3. **显式权衡**：对每个候选方案列「利/弊/代价/风险」，别只给一个答案。
+4. **给建议**：以「若目标是 X，建议 Y」收口，并标出证据强度（确证/推测）。
+
+## 与其它模式的关系
+
+- 分析产出「为什么与权衡」，要落地成方案再转 `omd-plan`。
+- 需求本身没问清先 `omd-deep-interview`；代码在哪没摸清先 `omd-deepsearch`。
+- 只想「推理决策、不查代码」的纯思考用 `omd-ultrathink`；要看代码证据用本模式。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出分析结构：视角清单 + 每视角关键发现 + 方案权衡表。让「从哪些角度看了、各自结论、怎么取舍」一眼可见。
+
+## 反模式
+
+- 别只给结论不给证据（file:line / 引用）。
+- 别只从单一视角（比如只谈安全）下结论。
+- 别把「分析」做成「直接改」——本模式产出判断，不产出补丁。

package/skills/omd-deep-interview/SKILL.md

@@ -1,68 +1,68 @@
----
-name: omd-deep-interview
-description: "深度访谈：写代码前用苏格拉底式追问澄清需求——用 ask_user_question 在加权维度上收敛模糊想法。需求模糊或有歧义时使用；触发词：deep-interview / 深度访谈 / 先澄清需求 / 需求访谈。"
----
-
-# oh-my-dsh · Deep Interview 需求澄清
-
-在写任何代码之前，用苏格拉底式追问把模糊想法收敛成可执行的规格。对应 OMC 的 Deep Interview 模式。
-
-## 何时用
-
-- 需求模糊："我想做个任务管理应用"。
-- 用户对设计摇摆、想被引导着想清楚。
-- 用户说"deep-interview""深度访谈""先澄清""访谈"。
-- 不要在有明确规格的任务上做访谈——那是浪费时间。
-
-## 澄清维度（加权）
-
-| 维度 | 要问清的问题 | 权重 |
-|------|------------|------|
-| 目标 | 最终要解决谁的什么问题？成功长什么样？ | 高 |
-| 范围 | 包含什么、**明确不包含**什么（non-goals）？ | 高 |
-| 约束 | 技术栈、性能、安全、合规、时间/成本硬约束？ | 高 |
-| 验收 | 怎么判断"做完了"？可度量的标准是什么？ | 高 |
-| 优先级 | 若只能先做一件，先做什么？哪些可砍？ | 中 |
-| 数据 | 数据从哪来？格式、量级、敏感度？ | 中 |
-| 风险 | 最可能翻车的地方？边界和失败模式？ | 低 |
-
-## 提问纪律（用 ask_user_question）
-
-- 每轮最多 2–4 个问题，每个问题给 2–4 个候选选项（可多选），并说明每个选项的取舍。
-- 问题必须**收敛**：问完一轮，维度就从"未知"变"已知"，别原地打转。
-- 只问**你无法通过检查代码库得到**的用户决策；能在仓库里查出来的事实不要拿去问。
-- 问题要具体，不要"你想要什么？"这种空泛问法——给候选方向。
-- 每个问题带一个稳定 `id`，答案会原样回传。
-
-```js
-ask_user_question({ questions: [
-  { id: 'scope', header: '范围', question: '第一版要覆盖哪些？',
-    options: [
-      { label: 'MVP：仅核心闭环', description: '最快验证价值，其余后续迭代' },
-      { label: '含协作与权限', description: '复杂度明显上升，工期翻倍' }
-    ] },
-  { id: 'acceptance', header: '验收', question: '怎么算"做完"？',
-    options: [
-      { label: '可演示的端到端闭环', description: 'happy path 全通即可' },
-      { label: '测试覆盖 + CI 全绿', description: '质量门槛更高' }
-    ] }
-] })
-```
-
-## 流程
-
-1. 先扫一眼仓库/现状（`glob`/`read`/`grep`），把"能查出来的事实"和"必须问用户的决策"分开。
-2. 按权重从高到低，每轮问 2–4 个问题。
-3. 每轮结束，把已确定的点回写成一份"需求快照"（简短），让用户确认没跑偏。
-4. 所有高权重维度都清晰后，输出最终规格：目标 / 范围 / 非目标 / 约束 / 验收标准 / 优先级 / 数据 / 风险。
-5. **拿到规格才开始动手**——之前的任何对话都只是澄清，不是开工许可。
-
-## 收尾
-
-最终规格用 `dsh-ui` 的 `keyvalue`/`table` 呈现（见 `omd-hud`），并明确说"以下规格确认后即开始实现"。
-
-## 反模式
-
-- 别一次甩 10 个问题。
-- 别问能靠读仓库回答的问题。
-- 别把用户"嗯/可以"当成完整需求确认——关键维度没问清就继续问。
+---
+name: omd-deep-interview
+description: "深度访谈：写代码前用苏格拉底式追问澄清需求——用 ask_user_question 在加权维度上收敛模糊想法。需求模糊或有歧义时使用；触发词：deep-interview / 深度访谈 / 先澄清需求 / 需求访谈。"
+---
+
+# oh-my-dsh · Deep Interview 需求澄清
+
+在写任何代码之前，用苏格拉底式追问把模糊想法收敛成可执行的规格。对应 OMC 的 Deep Interview 模式。
+
+## 何时用
+
+- 需求模糊："我想做个任务管理应用"。
+- 用户对设计摇摆、想被引导着想清楚。
+- 用户说"deep-interview""深度访谈""先澄清""访谈"。
+- 不要在有明确规格的任务上做访谈——那是浪费时间。
+
+## 澄清维度（加权）
+
+| 维度 | 要问清的问题 | 权重 |
+|------|------------|------|
+| 目标 | 最终要解决谁的什么问题？成功长什么样？ | 高 |
+| 范围 | 包含什么、**明确不包含**什么（non-goals）？ | 高 |
+| 约束 | 技术栈、性能、安全、合规、时间/成本硬约束？ | 高 |
+| 验收 | 怎么判断"做完了"？可度量的标准是什么？ | 高 |
+| 优先级 | 若只能先做一件，先做什么？哪些可砍？ | 中 |
+| 数据 | 数据从哪来？格式、量级、敏感度？ | 中 |
+| 风险 | 最可能翻车的地方？边界和失败模式？ | 低 |
+
+## 提问纪律（用 ask_user_question）
+
+- 每轮最多 2–4 个问题，每个问题给 2–4 个候选选项（可多选），并说明每个选项的取舍。
+- 问题必须**收敛**：问完一轮，维度就从"未知"变"已知"，别原地打转。
+- 只问**你无法通过检查代码库得到**的用户决策；能在仓库里查出来的事实不要拿去问。
+- 问题要具体，不要"你想要什么？"这种空泛问法——给候选方向。
+- 每个问题带一个稳定 `id`，答案会原样回传。
+
+```js
+ask_user_question({ questions: [
+  { id: 'scope', header: '范围', question: '第一版要覆盖哪些？',
+    options: [
+      { label: 'MVP：仅核心闭环', description: '最快验证价值，其余后续迭代' },
+      { label: '含协作与权限', description: '复杂度明显上升，工期翻倍' }
+    ] },
+  { id: 'acceptance', header: '验收', question: '怎么算"做完"？',
+    options: [
+      { label: '可演示的端到端闭环', description: 'happy path 全通即可' },
+      { label: '测试覆盖 + CI 全绿', description: '质量门槛更高' }
+    ] }
+] })
+```
+
+## 流程
+
+1. 先扫一眼仓库/现状（`glob`/`read`/`grep`），把"能查出来的事实"和"必须问用户的决策"分开。
+2. 按权重从高到低，每轮问 2–4 个问题。
+3. 每轮结束，把已确定的点回写成一份"需求快照"（简短），让用户确认没跑偏。
+4. 所有高权重维度都清晰后，输出最终规格：目标 / 范围 / 非目标 / 约束 / 验收标准 / 优先级 / 数据 / 风险。
+5. **拿到规格才开始动手**——之前的任何对话都只是澄清，不是开工许可。
+
+## 收尾
+
+最终规格用 `dsh-ui` 的 `keyvalue`/`table` 呈现（见 `omd-hud`），并明确说"以下规格确认后即开始实现"。
+
+## 反模式
+
+- 别一次甩 10 个问题。
+- 别问能靠读仓库回答的问题。
+- 别把用户"嗯/可以"当成完整需求确认——关键维度没问清就继续问。

package/skills/omd-deepsearch/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-deepsearch
-description: "代码库聚焦检索：定位本地代码库中的实现、调用点、定义与数据流。问「东西在哪」而非「怎么做」时使用；触发词：deepsearch / 找一下 / 代码在哪 / 定位 / 谁调用了 / 哪里实现的。"
----
-
-# oh-my-dsh · Deepsearch 代码库聚焦检索
-
-在**本地仓库**里做证据驱动的检索：定位实现、调用点、定义、数据流。对应 OMC 的 `deepsearch` 提示词触发模式。
-
-## 何时用
-
-- 问题答案是「代码在哪里/谁调用了/哪里实现的」，而不是「该怎么做」。
-- 要追一条调用链、一个符号的定义与引用、一个配置项的生效位置。
-
-## 检索纪律
-
-- **本地优先**：`grep`（按符号/正则搜内容）、`glob`（按路径模式找文件）、`read`（读上下文）。代码库问题先用它们，别一上来 `web_search`。
-- **给证据**：每个结论带 `file:line`（或文件 + 关键片段），让用户能直接点过去核。
-- **追到底**：从调用点沿定义→引用→实现追完整链，别停在第一处匹配。
-- **广撒网再收口**：范围不明时并行 `subagent`，每个子代理负责一个模块/一条链路，返回带行号的结论，主代理汇总。
-
-## 与其它模式的关系
-
-- 只想「找到」就只返回定位结果；找到后要「改」就转 `omd-plan` 或 `omd-execute`。
-- 要理解「为什么这么设计」而不仅是「在哪」，转 `omd-deep-analyze`。
-- 框架/API 的**外部**语义仍用 `web_search`/`web_fetch` 查官方文档，别猜。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出检索结果：命中清单表（符号/文件/行号/角色：定义|调用|实现）。让「找到了什么、每条证据在哪」一眼可见。
-
-## 反模式
-
-- 别对代码库问题直接 `web_search`——那是外部信息，不是本项目事实。
-- 别返回没有 `file:line` 的模糊结论。
-- 别在找到第一处匹配就停，确认它是唯一/权威的那一处。
+---
+name: omd-deepsearch
+description: "代码库聚焦检索：定位本地代码库中的实现、调用点、定义与数据流。问「东西在哪」而非「怎么做」时使用；触发词：deepsearch / 找一下 / 代码在哪 / 定位 / 谁调用了 / 哪里实现的。"
+---
+
+# oh-my-dsh · Deepsearch 代码库聚焦检索
+
+在**本地仓库**里做证据驱动的检索：定位实现、调用点、定义、数据流。对应 OMC 的 `deepsearch` 提示词触发模式。
+
+## 何时用
+
+- 问题答案是「代码在哪里/谁调用了/哪里实现的」，而不是「该怎么做」。
+- 要追一条调用链、一个符号的定义与引用、一个配置项的生效位置。
+
+## 检索纪律
+
+- **本地优先**：`grep`（按符号/正则搜内容）、`glob`（按路径模式找文件）、`read`（读上下文）。代码库问题先用它们，别一上来 `web_search`。
+- **给证据**：每个结论带 `file:line`（或文件 + 关键片段），让用户能直接点过去核。
+- **追到底**：从调用点沿定义→引用→实现追完整链，别停在第一处匹配。
+- **广撒网再收口**：范围不明时并行 `subagent`，每个子代理负责一个模块/一条链路，返回带行号的结论，主代理汇总。
+
+## 与其它模式的关系
+
+- 只想「找到」就只返回定位结果；找到后要「改」就转 `omd-plan` 或 `omd-execute`。
+- 要理解「为什么这么设计」而不仅是「在哪」，转 `omd-deep-analyze`。
+- 框架/API 的**外部**语义仍用 `web_search`/`web_fetch` 查官方文档，别猜。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出检索结果：命中清单表（符号/文件/行号/角色：定义|调用|实现）。让「找到了什么、每条证据在哪」一眼可见。
+
+## 反模式
+
+- 别对代码库问题直接 `web_search`——那是外部信息，不是本项目事实。
+- 别返回没有 `file:line` 的模糊结论。
+- 别在找到第一处匹配就停，确认它是唯一/权威的那一处。