@hawk2048/oh-my-dsh 0.2.0 → 0.3.2

package/skills/omd-ai-slop-cleaner/SKILL.md

@@ -1,43 +1,43 @@
----
-name: omd-ai-slop-cleaner
-description: "AI-slop-cleaner: strip AI-generated filler, boilerplate, redundant comments, and vague prose from code or text. Use when the user says ai-slop / 去废话 / 精简 / 去水 / 太啰嗦 / 去AI味, or wants output tightened."
----
-
-# oh-my-dsh · AI-slop-cleaner 去废话
-
-删除 AI 生成的冗余、套话、废话注释与空洞措辞，让代码/文本**精炼、具体、像人写的**。对应 OMC 的 `ai-slop-cleaner` 提示词触发模式（其内部转 `review`）。
-
-## 何时用
-
-- 用户嫌输出啰嗦、有「AI 味」、要精简。
-- 清理冗余注释、无意义样板、`In conclusion` 式套话。
-
-## 清理纪律
-
-识别并移除这些典型 slop：
-
-| 类型 | 例子 | 处理 |
-|------|------|------|
-| 复述注释 | `// set x to 1` 紧跟 `x = 1` | 删注释，代码自明 |
-| 废话样板 | "In today's fast-paced world…" | 整段删 |
-| 空洞形容词 | "robust, scalable, cutting-edge" | 换成具体事实 |
-| 冗余总结 | 结尾把上文再讲一遍 | 删，留结论 |
-| 无意义占位 | TODO 永不实现、`pass` 式填充 | 删或落实 |
-
-原则：**保留含义，删掉水分**。改完让输出更短、更具体，但不丢信息。
-
-## 与其它模式的关系
-
-- 清理完交给 `omd-review` 复核，确认没误删语义。
-- 清理的是「写得啰嗦」，不是「逻辑有错」——后者走 `omd-debug` / `omd-review`。
-- 用于生成时，把它当 `omd-execute` 的输出后置滤网。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出清理对照：删除条目 + 前后字数 + 类型分布。让「删了什么、精简多少」一眼可见。
-
-## 反模式
-
-- 别为精简牺牲准确性或可读性。
-- 别把有信息量的注释当 slop 删掉（`为什么` 的注释要留）。
-- 别只删不改——该重写的句子要重写成具体措辞。
+---
+name: omd-ai-slop-cleaner
+description: "去AI味：清除代码或文本里 AI 生成的废话、套话、冗余注释与含糊表述。触发词：ai-slop / 去废话 / 精简 / 去水 / 太啰嗦 / 去AI味；或想让输出更紧凑时。"
+---
+
+# oh-my-dsh · AI-slop-cleaner 去废话
+
+删除 AI 生成的冗余、套话、废话注释与空洞措辞，让代码/文本**精炼、具体、像人写的**。对应 OMC 的 `ai-slop-cleaner` 提示词触发模式（其内部转 `review`）。
+
+## 何时用
+
+- 用户嫌输出啰嗦、有「AI 味」、要精简。
+- 清理冗余注释、无意义样板、`In conclusion` 式套话。
+
+## 清理纪律
+
+识别并移除这些典型 slop：
+
+| 类型 | 例子 | 处理 |
+|------|------|------|
+| 复述注释 | `// set x to 1` 紧跟 `x = 1` | 删注释，代码自明 |
+| 废话样板 | "In today's fast-paced world…" | 整段删 |
+| 空洞形容词 | "robust, scalable, cutting-edge" | 换成具体事实 |
+| 冗余总结 | 结尾把上文再讲一遍 | 删，留结论 |
+| 无意义占位 | TODO 永不实现、`pass` 式填充 | 删或落实 |
+
+原则：**保留含义，删掉水分**。改完让输出更短、更具体，但不丢信息。
+
+## 与其它模式的关系
+
+- 清理完交给 `omd-review` 复核，确认没误删语义。
+- 清理的是「写得啰嗦」，不是「逻辑有错」——后者走 `omd-debug` / `omd-review`。
+- 用于生成时，把它当 `omd-execute` 的输出后置滤网。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出清理对照：删除条目 + 前后字数 + 类型分布。让「删了什么、精简多少」一眼可见。
+
+## 反模式
+
+- 别为精简牺牲准确性或可读性。
+- 别把有信息量的注释当 slop 删掉（`为什么` 的注释要留）。
+- 别只删不改——该重写的句子要重写成具体措辞。

package/skills/omd-autopilot/SKILL.md

@@ -1,51 +1,51 @@
----
-name: omd-autopilot
-description: "Autopilot: one lead agent (you) drives a single objective to verified completion across goal rounds, delegating via subagents and tracking with todo_write. Use for end-to-end autonomous feature work with minimal ceremony, or when the user says autopilot/自动驾驶/自主执行/自动驾驶式."
----
-
-# oh-my-dsh · Autopilot 自动驾驶
-
-一个主控代理（你）把一个目标从模糊一路推到「已验证完成」。对应 OMC 的 Autopilot 模式：**单领导、自主执行、持续到底**。
-
-## 何时用
-
-- 用户给了一个明确的最终目标："搭一个 REST API""重构认证模块"。
-- 不想走 Team 的完整五阶段仪式，但目标要真正跑完、验证过。
-- 用户说"autopilot""自动驾驶""自主执行""一路做完"。
-
-## 核心：goal 工具循环
-
-Autopilot 的地基是 DSH 的 goal 工具——一个**跨多轮持续到完成**的目标，不是单轮内做完。
-
-```
-create_goal(objective)  →  [每一轮]  todo_write 推进  →  subagent 委托  →  update_goal 推进  →  完成
-```
-
-1. **建目标**：`create_goal(objective, { max_goal_rounds })`。objective 写成"可验收的完成目标"，不是任务描述——"通过 npm test 的认证模块重构"优于"重构认证"。
-2. **拆计划**：立刻用 `todo_write` 列出实现步骤，每步一条；并行步骤可同时 `in_progress`。
-3. **每轮推进**：本轮该做的做（`subagent` 委托独立子任务、读代码、改文件），做完就把对应 todo 置 `completed`，用 `update_goal` 保持目标推进。
-4. **持续到完成**：跨轮继续，别在单轮里硬塞。每个长目标都属于 goal 工具，不属于一次回答。
-5. **委托**：能独立、能并行的子任务用 `subagent`（后台并行），不要把上下文全烧在主控里。
-6. **收尾**：只有「验证通过、验收标准满足」才 `update_goal complete`；用 `get_goal` 读当前 revision 再更新。
-
-## 目标状态纪律
-
-- `complete`：目标**真正达成**才标。别因为"做完了主要部分"就提前标。
-- `blocked`：**同一阻塞条件持续至少 3 个 goal 轮**才标，并在 `blocked_reason` 里写明具体条件。"难/不确定/还有活"不算 blocked。
-- 目标在会话恢复或 fork 后会解除武装：用户说"继续/接着做"时用 `update_goal resume` 重新武装。
-
-## 与 Team / Ralph 的边界
-
-- **Team**：多子系统、要分阶段规格。Autopilot 是单领导直推，不搞 prd 仪式。
-- **Ralph**：要"每个完成都必须验证、不许静默半成品"的强验证循环，或用户明说 fresh-agent 迭代。
-- Autopilot 内部可以顺手并行 `subagent`，但主控权始终在你这一个代理手里。
-
-## 收尾：HUD
-
-每轮结束按 `omd-hud` 输出内联仪表盘：目标 + 轮次 + todo 进度 + 子代理状态。让用户始终看到"现在到哪了、还差什么"。
-
-## 反模式
-
-- 别在单轮里试图一次做完整个目标——goal 工具就是为"跨轮持续"设计的。
-- 别把 goal 用在琐碎的单轮任务上。
-- 别静默交付半成品——收尾前必须验证。
+---
+name: omd-autopilot
+description: "自动驾驶：一个主控代理（你）跨目标轮次把单一目标持续做到已验证完成，用子代理委派并以 todo_write 跟踪。适合低仪式感的端到端自主功能开发；触发词：autopilot / 自动驾驶 / 自主执行 / 自动驾驶式。"
+---
+
+# oh-my-dsh · Autopilot 自动驾驶
+
+一个主控代理（你）把一个目标从模糊一路推到「已验证完成」。对应 OMC 的 Autopilot 模式：**单领导、自主执行、持续到底**。
+
+## 何时用
+
+- 用户给了一个明确的最终目标："搭一个 REST API""重构认证模块"。
+- 不想走 Team 的完整五阶段仪式，但目标要真正跑完、验证过。
+- 用户说"autopilot""自动驾驶""自主执行""一路做完"。
+
+## 核心：goal 工具循环
+
+Autopilot 的地基是 DSH 的 goal 工具——一个**跨多轮持续到完成**的目标，不是单轮内做完。
+
+```
+create_goal(objective)  →  [每一轮]  todo_write 推进  →  subagent 委托  →  update_goal 推进  →  完成
+```
+
+1. **建目标**：`create_goal(objective, { max_goal_rounds })`。objective 写成"可验收的完成目标"，不是任务描述——"通过 npm test 的认证模块重构"优于"重构认证"。
+2. **拆计划**：立刻用 `todo_write` 列出实现步骤，每步一条；并行步骤可同时 `in_progress`。
+3. **每轮推进**：本轮该做的做（`subagent` 委托独立子任务、读代码、改文件），做完就把对应 todo 置 `completed`，用 `update_goal` 保持目标推进。
+4. **持续到完成**：跨轮继续，别在单轮里硬塞。每个长目标都属于 goal 工具，不属于一次回答。
+5. **委托**：能独立、能并行的子任务用 `subagent`（后台并行），不要把上下文全烧在主控里。
+6. **收尾**：只有「验证通过、验收标准满足」才 `update_goal complete`；用 `get_goal` 读当前 revision 再更新。
+
+## 目标状态纪律
+
+- `complete`：目标**真正达成**才标。别因为"做完了主要部分"就提前标。
+- `blocked`：**同一阻塞条件持续至少 3 个 goal 轮**才标，并在 `blocked_reason` 里写明具体条件。"难/不确定/还有活"不算 blocked。
+- 目标在会话恢复或 fork 后会解除武装：用户说"继续/接着做"时用 `update_goal resume` 重新武装。
+
+## 与 Team / Ralph 的边界
+
+- **Team**：多子系统、要分阶段规格。Autopilot 是单领导直推，不搞 prd 仪式。
+- **Ralph**：要"每个完成都必须验证、不许静默半成品"的强验证循环，或用户明说 fresh-agent 迭代。
+- Autopilot 内部可以顺手并行 `subagent`，但主控权始终在你这一个代理手里。
+
+## 收尾：HUD
+
+每轮结束按 `omd-hud` 输出内联仪表盘：目标 + 轮次 + todo 进度 + 子代理状态。让用户始终看到"现在到哪了、还差什么"。
+
+## 反模式
+
+- 别在单轮里试图一次做完整个目标——goal 工具就是为"跨轮持续"设计的。
+- 别把 goal 用在琐碎的单轮任务上。
+- 别静默交付半成品——收尾前必须验证。

package/skills/omd-autoresearch/SKILL.md

@@ -1,45 +1,45 @@
----
-name: omd-autoresearch
-description: "Autoresearch: a bounded evaluator-driven improvement loop — produce a version, an evaluator subagent scores it against the target criteria, then improve, repeat until it meets the bar or the round cap. Use when the user asks to autoresearch/自动调研改进/边做边评/持续打磨到达标."
----
-
-# oh-my-dsh · Autoresearch 评估器驱动的改进循环
-
-不是单趟调研，而是**「产出 → 评估打分 → 按差距改进 → 再评估」的有界循环**，直到达标或达到轮次上限。对应 OMC 的 `autoresearch`。
-
-## 何时用
-
-- 产出物有明确的"达标标准"，但第一版通常不够好，需要迭代打磨（调研报告、设计文档、方案对比）。
-- 用户说"autoresearch""自动调研改进""边做边评""持续打磨""做到达标为止"。
-
-## 有界循环
-
-```
-create_goal(达标目标) → 产出当前版 → 评估子代理打分/找差距 → 按差距改进 → 再评估 → 达标或达上限即停
-```
-
-1. **定达标标准**：`create_goal` 写一个可验收的 objective（"有 3 个以上来源、覆盖性能与安全两个维度、无未决存疑项的报告"优于"好好调研一下"）。
-2. **产出当前版**：先出一版（可并行 `subagent` 分工）。
-3. **评估**：派评估子代理**独立**对照达标标准打分，返回「差距清单」（哪里不达标、差在哪、怎么改），只允许"达标 / 具体差距"，不允许"差不多"。
-4. **改进**：按差距清单修，回到第 3 步。
-5. **有界退出**：达标 → `update_goal complete`；达到轮次上限仍未达标 → 显式报告剩余差距，别装作完成。
-
-## 状态与可恢复
-
-- 用 goal 工具承载循环状态，跨轮持续。
-- 每轮把「当前版 + 评估结论」写进工作区文件（如 `AUTORESEARCH.md`），保证会话恢复后能接着改。
-
-## 与其它模式的关系
-
-- `research` = 单趟查证；`autoresearch` = research + 评估循环，目标是"持续改进到达标"。
-- 评估是**独立评估**，别让产出代理自我打分。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出：轮次 + 评分趋势 + 差距清单（未达标项）。让"离达标还差什么"始终可见。
-
-## 反模式
-
-- 别无界循环——必须有轮次上限 + 明确的达标退出条件。
-- 别把"评估分数"当最终结论——评估也是证据之一，最后仍要独立核验。
-- 别把评估做模糊（"还行"）——要具体到差距项。
+---
+name: omd-autoresearch
+description: "自动调研改进：有界的评估器驱动改进循环——产出一版，评估子代理对照目标标准打分，再改进、再评，直到达标或到达轮次上限。触发词：autoresearch / 自动调研改进 / 边做边评 / 持续打磨到达标。"
+---
+
+# oh-my-dsh · Autoresearch 评估器驱动的改进循环
+
+不是单趟调研，而是**「产出 → 评估打分 → 按差距改进 → 再评估」的有界循环**，直到达标或达到轮次上限。对应 OMC 的 `autoresearch`。
+
+## 何时用
+
+- 产出物有明确的"达标标准"，但第一版通常不够好，需要迭代打磨（调研报告、设计文档、方案对比）。
+- 用户说"autoresearch""自动调研改进""边做边评""持续打磨""做到达标为止"。
+
+## 有界循环
+
+```
+create_goal(达标目标) → 产出当前版 → 评估子代理打分/找差距 → 按差距改进 → 再评估 → 达标或达上限即停
+```
+
+1. **定达标标准**：`create_goal` 写一个可验收的 objective（"有 3 个以上来源、覆盖性能与安全两个维度、无未决存疑项的报告"优于"好好调研一下"）。
+2. **产出当前版**：先出一版（可并行 `subagent` 分工）。
+3. **评估**：派评估子代理**独立**对照达标标准打分，返回「差距清单」（哪里不达标、差在哪、怎么改），只允许"达标 / 具体差距"，不允许"差不多"。
+4. **改进**：按差距清单修，回到第 3 步。
+5. **有界退出**：达标 → `update_goal complete`；达到轮次上限仍未达标 → 显式报告剩余差距，别装作完成。
+
+## 状态与可恢复
+
+- 用 goal 工具承载循环状态，跨轮持续。
+- 每轮把「当前版 + 评估结论」写进工作区文件（如 `AUTORESEARCH.md`），保证会话恢复后能接着改。
+
+## 与其它模式的关系
+
+- `research` = 单趟查证；`autoresearch` = research + 评估循环，目标是"持续改进到达标"。
+- 评估是**独立评估**，别让产出代理自我打分。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出：轮次 + 评分趋势 + 差距清单（未达标项）。让"离达标还差什么"始终可见。
+
+## 反模式
+
+- 别无界循环——必须有轮次上限 + 明确的达标退出条件。
+- 别把"评估分数"当最终结论——评估也是证据之一，最后仍要独立核验。
+- 别把评估做模糊（"还行"）——要具体到差距项。

package/skills/omd-cancel/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-cancel
-description: "Cancel: stop an in-flight orchestration mode — halt goal rounds, interrupt background subagents, kill jobs — and leave a clean checkpoint. Use when the user says 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: reproduce the failure, isolate the cause with evidence, fix minimally, and lock it with a regression test. Use when the user says 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: multi-angle, evidence-backed analysis of code, architecture, or a problem. Use when the user says deep-analyze / 深度分析 / 分析一下 / 为什么这样 / 值得吗, and wants thorough reasoning, not a quick fix."
----
-
-# 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 / 引用）。
+- 别只从单一视角（比如只谈安全）下结论。
+- 别把「分析」做成「直接改」——本模式产出判断，不产出补丁。