@hawk2048/oh-my-dsh 0.2.1 → 0.3.3

package/skills/omd-plan/SKILL.md

@@ -1,51 +1,51 @@
----
-name: omd-plan
-description: "规划：先用只读方式探索（读/搜索/静态分析），再产出具体的实现计划（带依赖的任务拆解 + 验收标准 + 文件级改动）。不写代码。作为 plan→execute→review→verify 流水线的第一阶段；触发词：plan / 规划 / 方案 / 计划 / 怎么实现。"
----
-
-# oh-my-dsh · Plan 规划
-
-先探明现状，再产出一份**可执行、可验收**的实现计划；此阶段**不写代码**。对应 OMC 的 `plan` 工作流（Tier-0 流水线第一段：`plan → execute → review → verify`）。
-
-## 何时用
-
-- 任务还没拆清楚，或横跨多文件/多模块。
-- 用户说"规划""方案""计划""先想清楚怎么做""plan"。
-- 作为流水线的起点：规划完交给 `execute`。
-
-## 探索优先（不动手）
-
-先用**非变更**手段把现状摸清，再谈怎么做：
-
-- `read` / `grep` / `glob` 读代码、搜符号、列文件；
-- `web_search` / `web_fetch` 查官方文档（用 SDK/框架/API 前必查）；
-- 大范围探索可并行 `subagent`：每个子代理负责一个子系统/一个疑问，返回结构化结论。
-
-原则：计划必须**扎根在真实仓库**，不要凭空假设接口或路径。
-
-## 产出计划
-
-计划至少包含三块：
-
-| 块 | 内容 |
-|----|------|
-| 任务分解 | 编号任务，标明依赖关系（哪些可并行） |
-| 验收标准 | 每个任务怎么算"做完"（测试/命令/观察点） |
-| 落地位置 | 每个任务改哪些文件、用什么既有模式 |
-
-把计划写成正文（markdown）。若当前处于 plan mode，用 `exit_plan_mode` 提交计划等待确认；否则把计划留在回答里，等用户确认后再进入 `execute`。
-
-## 与其它阶段的关系
-
-- `plan` 管"拆什么、怎么验收"；`deep-interview` 管"需求本身还没问清"——需求模糊先 `deep-interview`，需求清楚了才 `plan`。
-- 别在这里实现：`plan` 的产出是"做什么"，`execute` 才做。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出计划概览：任务清单表（依赖/验收列）+ 阶段进度条。让"要做什么、依赖谁、怎么算完"一眼可见。
-
-## 反模式
-
-- 别跳过探索直接写计划——没读代码的计划是猜的。
-- 别把 `plan` 和 `deep-interview` 混用：一个管需求，一个管实现方案。
-- 别在 plan 阶段改文件（非变更探索除外）。
+---
+name: omd-plan
+description: "规划：先用只读方式探索（读/搜索/静态分析），再产出具体的实现计划（带依赖的任务拆解 + 验收标准 + 文件级改动）。不写代码。作为 plan→execute→review→verify 流水线的第一阶段；触发词：plan / 规划 / 方案 / 计划 / 怎么实现。"
+---
+
+# oh-my-dsh · Plan 规划
+
+先探明现状，再产出一份**可执行、可验收**的实现计划；此阶段**不写代码**。对应 OMC 的 `plan` 工作流（Tier-0 流水线第一段：`plan → execute → review → verify`）。
+
+## 何时用
+
+- 任务还没拆清楚，或横跨多文件/多模块。
+- 用户说"规划""方案""计划""先想清楚怎么做""plan"。
+- 作为流水线的起点：规划完交给 `execute`。
+
+## 探索优先（不动手）
+
+先用**非变更**手段把现状摸清，再谈怎么做：
+
+- `read` / `grep` / `glob` 读代码、搜符号、列文件；
+- `web_search` / `web_fetch` 查官方文档（用 SDK/框架/API 前必查）；
+- 大范围探索可并行 `subagent`：每个子代理负责一个子系统/一个疑问，返回结构化结论。
+
+原则：计划必须**扎根在真实仓库**，不要凭空假设接口或路径。
+
+## 产出计划
+
+计划至少包含三块：
+
+| 块 | 内容 |
+|----|------|
+| 任务分解 | 编号任务，标明依赖关系（哪些可并行） |
+| 验收标准 | 每个任务怎么算"做完"（测试/命令/观察点） |
+| 落地位置 | 每个任务改哪些文件、用什么既有模式 |
+
+把计划写成正文（markdown）。若当前处于 plan mode，用 `exit_plan_mode` 提交计划等待确认；否则把计划留在回答里，等用户确认后再进入 `execute`。
+
+## 与其它阶段的关系
+
+- `plan` 管"拆什么、怎么验收"；`deep-interview` 管"需求本身还没问清"——需求模糊先 `deep-interview`，需求清楚了才 `plan`。
+- 别在这里实现：`plan` 的产出是"做什么"，`execute` 才做。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出计划概览：任务清单表（依赖/验收列）+ 阶段进度条。让"要做什么、依赖谁、怎么算完"一眼可见。
+
+## 反模式
+
+- 别跳过探索直接写计划——没读代码的计划是猜的。
+- 别把 `plan` 和 `deep-interview` 混用：一个管需求，一个管实现方案。
+- 别在 plan 阶段改文件（非变更探索除外）。

package/skills/omd-pyramid/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: omd-pyramid
+description: "金字塔结构化表达：把回答/汇报/方案/文档按 Minto 金字塔重组——结论先行、以上统下、归类分组(MECE)、逻辑递进，用 SCQA 开场，标题写成判断句。触发词：金字塔 / 金字塔原理 / 结构化表达 / 结论先行 / 总分总 / MECE / 不重不漏 / 怎么讲清楚 / 汇报怎么说 / 帮我把这段组织好 / pyramid / Minto / SCQA；或把一堆散点要点组织成有说服力的表达时。"
+---
+
+# oh-my-dsh · Pyramid 金字塔结构化表达
+
+把「有一堆信息要说」变成「别人一遍就能听懂并照做」。方法论来自 Barbara Minto 的《The Pyramid Principle》：**先给答案，再给支撑，同层不重不漏**。
+
+**本插件新增**（OMC 无对应项）：OMC 的表达类纪律只有 `ai-slop-cleaner`（管字面水分），没有管结构的方法论，所以这一条是 oh-my-dsh 自己补的。DSH 侧的原生载体是 `dsh-ui` 围栏（层级 → 组件）、`omd-hud`（进度快照）与 `todo_write`（骨架落地）。
+
+## 何时用
+
+- 用户说「讲清楚 / 结构化 / 结论先行 / 总分总 / MECE / 帮我组织一下」，或抱怨"说了一堆不知道你想说什么"。
+- 交付形态是**给人看的**：汇报、方案、评审结论、调研报告、复盘、PRD、PPT 大纲、邮件/IM 长消息。
+- 要点 ≥ 3 条、出现分歧需要裁决、需要对方做决定或采取行动。
+- 反例（别硬套）：纯探索性头脑风暴（此时要的是发散，不是收敛）、需要先铺垫情绪的坏消息正文、一步步教学推导——这些见下方「何时不该结论先行」。
+
+## 四根柱子
+
+| 柱子 | 含义 | 失败长相 |
+|------|------|----------|
+| **结论先行** | 第一句就是答案/建议/裁决，不是背景 | "背景是这样的…然后我们查了…最后发现…" |
+| **以上统下** | 上一层是下层的总结；下层回答上一层引发的疑问 | 上层说 A，下层全在讲 B |
+| **归类分组（MECE）** | 同层要点互斥不重叠、合计穷尽 | 三条理由里两条其实是一件事；漏掉关键第四类 |
+| **逻辑递进** | 同层要么是**归纳**（并列分组，须 MECE）要么是**演绎**（层层推导），二选一不混用 | 重要性倒挂，重点埋在最后一条；把演绎链硬拆成伪并列 |
+
+四条缺一不可：只有「结论先行」是喊口号，只有「分组」是清单。
+
+**演绎只放底层**：演绎链（大前提→小前提→结论）一环断则全塌，结论还埋在链尾——越往上越要用归纳。组内顺序按 **时间 / 结构 / 程度** 三选一。
+
+## 序言：SCQA 开场
+
+结论需要铺垫时（新听者、有冲突、有历史包袱），用 4 句开场，然后**立刻切回结论**：
+
+1. **S 情境**：双方都认同的事实（"当前 v0.2.1 已发布"）。
+2. **C 冲突**：打破情境的变化（"但技能清单和计数散落在 README、preset、docs 多处，加一个技能要同步改十几处"）。
+3. **Q 疑问**：冲突自然引出的问题（"怎么加才不失控？"）——**这一句通常写出来最好，它是往下走的钩子**。
+4. **A 答案**：就是你的结论，与全文第一条完全一致。
+
+S/C 各不超过一句。序言超过 4 行说明你在用背景拖延结论。
+
+## 三层自检（发出去之前逐层过）
+
+**纵向**：从下往上问「所以呢？」——每条论据合起来，是否**足以**推出上层结论？推不出的，要么补论据，要么改结论（多数时候该改结论）。
+
+**横向同层**：对每层做两问——
+- *互斥*：两条要点能合并吗？能合并的就是一条，别充数。
+- *穷尽*：还缺哪一类？用「按时间 / 按构成 / 按重要度」三个视角各扫一遍找漏项。
+
+**序言**：S 是不是双方真认同？C 是不是真冲突？读者读完 Q 会不会自然想问你的 A？
+
+## 数量与措辞纪律
+
+- **同层 3–5 条**为最佳。超过 5 条时先问「这几条能不能概括成一层」，而不是继续平铺——分组天生就是用来压缩数量的。
+- **标题写成判断句**，不写标签。`缓存不是瓶颈，连接池才是` ✅ ／ `性能分析` ❌。
+- 每层要点自带**数字或事实**，形容词不算支撑（"显著提升" → "P95 从 820ms 降到 210ms"）。
+- 一页纸骨架：
+
+```
+结论     ← 一句话，可决策/可执行
+论据 1/2/3  ← 同层 MECE，各 1 行，带数字
+支撑       ← 表 / 图 / 证据链（可折叠）
+下一步     ← 需要谁、在什么时候、做什么决定
+```
+
+## 落到 DSH：金字塔 ↔ dsh-ui 组件映射
+
+结构本身也能用组件承载，别把层级写成流水账。规则见 `genui` skill。
+
+| 金字塔位置 | 组件 | 说明 |
+|-----------|------|------|
+| 结论 | `callout` / `hero` | 一条回答最多一个 hero |
+| 同层论据（3–5 条） | `list` / `table` | ≥3 条并列优先 `list`/`table`，不写 markdown 项目符号 |
+| 数字对比 / 指标 | `stat` / `chart` / `table` | 有数就有组件 |
+| 层级与派生 | `steps` / `mermaid` / `accordion` | 展示"谁支撑谁" |
+| 裁决 / 风险 | `callout` | tone 表态：success / warn / danger |
+| 下一步 | `callout`（info）或 `steps` | 永远是最后一项 |
+
+纪律与 `genui` 一致：**同一批数据不重复表达**；组件多不是问题，"每个组件承载不同信息、有焦点层次"才是判据。
+
+## 与其它模式的关系
+
+- **`omd-ai-slop-cleaner`** 管「字面水分」，本 skill 管「结构错位」——先结构后文字，顺序反了会白删。
+- **`omd-hud`** 是进度快照，不是结论；HUD 之后仍要有一句金字塔式的结论收尾。
+- **`omd-plan` / `omd-review` / `omd-research` / `omd-autoresearch`** 的产出天然是金字塔素材：把它们的表格当层级里的支撑证据，别把过程重讲一遍。
+- **`omd-deep-interview`** 收敛出的规格，写给用户时按金字塔呈现（结论 = 定稿的规格，论据 = 关键取舍）。
+- **PPT / 文档交付**：一页一结论；页标题即该页的论据，全篇构成金字塔的横向一层。
+
+## 何时不该结论先行
+
+- **坏消息 / 敏感决定**：先 SCQA 建立共识，再给结论；直接甩结论会被当成不体谅。
+- **对方尚未认同前提**：先解决前提分歧，否则结论只会引发争论。
+- **纯发散**：要的是选项空间，此时结论先行会过早杀死可能性——先列，再收敛，收敛时切回金字塔。
+- **唯一可行路径的强操作**：直接给步骤（`steps`），不用论证。
+
+## 收尾：HUD
+
+按 `omd-hud` 输出结构化对照，让「改了什么」一眼可见：
+
+```dsh-ui
+{"title":"Pyramid · 结构重组","gap":14,"items":[
+  {"type":"row","wrap":true,"items":[
+    {"type":"stat","label":"结论位置","value":"第 1 句","delta":"原第 7 段"},
+    {"type":"stat","label":"同层要点","value":"4","delta":"-2 (合并)"},
+    {"type":"stat","label":"MECE 缺口","value":"补 1 类"}
+  ]},
+  {"type":"table","columns":["层","原状","改后"],
+   "rows":[["结论","埋在最后","首句，判断句"],["论据","6 条混杂","4 条 MECE"],["支撑","散落正文","表 + 证据链"]]},
+  {"type":"callout","tone":"info","title":"下一步","content":"按新骨架重写，再用 ai-slop-cleaner 过一遍文字"}
+]}
+```
+
+## 反模式
+
+- **漏斗式开场**：背景 → 过程 → 结果 → 结论。人类读长文才这样写，读你的回答不这样读。
+- **伪 MECE**：三条要点是同一件事的三种说法（"更快 / 性能更好 / 延迟更低"）。
+- **层级错位**：论据不支撑结论，只是因为「我想说」才写进去。
+- **标签标题**：`## 性能分析` 不传递任何判断，读者得自己总结——那就等于没写。
+- **贪多**：一层塞 9 条。宁可新起一层，也不要平铺。
+- **结构压过事实**：金字塔是组织方式，不是让弱论据显得强的化妆术；论据不足时该改的是结论。

package/skills/omd-ralph/SKILL.md

@@ -1,62 +1,62 @@
----
-name: omd-ralph
-description: "拉夫：持久验证/修复循环，不留静默半成品。显式全新代理迭代用原生 ralph 工具，否则用手动 goal+verify 循环。任务必须完整完成并验证时使用；触发词：ralph / 拉夫 / verify-fix / 必须做完。"
----
-
-# oh-my-dsh · Ralph 持久验证循环
-
-目标必须**完整完成并验证过**，绝不允许静默的半成品。对应 OMC 的 Ralph 模式。DSH 原生就带 `ralph` 工具，所以这里分两条路：原生 Ralph，和手动 verify/fix 循环。
-
-## 何时用
-
-- 用户说"ralph""拉夫""一定要做完""不许半途""fresh-agent 迭代"。
-- 任务有硬验收标准，必须验证到全绿。
-- 普通的"做一下就完"不要用 Ralph——它重。
-
-## 路线 A：原生 ralph 工具
-
-用户**明确要求 Ralph/fresh-agent 迭代**时，直接调 `ralph` 工具：
-
-```
-ralph(objective, { maxRounds })
-```
-
-语义（和 goal 不同，务必分清）：
-
-- 每一轮开一个**全新子代理**，不继承任何对话种子。
-- **共享工作区是唯一长期记忆**——子代理通过读/写文件在轮次间传递上下文。
-- 只有一份**有界结构化报告**跨轮传递，其余什么都不带。
-- 返回：某个 worker 报告完成、或报告具体阻塞、或达到轮次上限。
-- 完成与阻塞是**worker 的自述报告，不是独立评估**——最后你要自己核验工作区里的真实产物。
-
-用 Ralph 时，你的职责是：写一个**不可变、可验收的 objective**；把验收标准和进度约定写进工作区文件（如 `RALPH.md`）让每轮子代理读到；循环结束后独立检查产物是否真达标。
-
-## 路线 B：手动 verify/fix 循环（原生 ralph 之外的默认）
-
-用户没明说要 fresh-agent 迭代、但任务必须验证到全绿时，用 goal + 验证代理手动循环：
-
-```
-1. create_goal(objective)           # 持久目标
-2. 实现（主控 or subagent 委托）
-3. verify：subagent 验证代理对照验收标准产出"通过/缺陷清单"
-4. fix：有缺陷就修，回到第 3 步
-5. 全绿 → update_goal complete；同一阻塞 ≥3 轮 → update_goal blocked
-```
-
-验证代理的提示词要**硬性**：逐条对照验收标准，只允许"通过"或"具体缺陷"，不允许"看起来没问题"这类模糊结论。
-
-## 与其它模式的关系
-
-- Ralph **包含并行**：执行和验证阶段内部照常并行 `subagent`（`execute` 的并行能力），只是外面多套一层"必须验证到全绿"。
-- Ralph 强调**不许静默半成品**；Autopilot 强调**单领导持续到底**。两者常叠加。
-- Ralph 的 verify/fix 循环，本质是把 `plan→execute→review→verify` 里的 `verify` 阶段反复执行到全绿。
-
-## 收尾：HUD
-
-每轮 verify/fix 后按 `omd-hud` 输出仪表盘：轮次、通过/缺陷计数、fix loop 次数。让"还剩几个缺陷"始终可见。
-
-## 反模式
-
-- 别把 Ralph 用在琐碎任务上。
-- 别把 worker 的"完成报告"当最终结论——你要亲自核验工作区。
-- fix loop 必须设上限，且必须有"全绿"这个明确退出条件。
+---
+name: omd-ralph
+description: "拉夫：持久验证/修复循环，不留静默半成品。显式全新代理迭代用原生 ralph 工具，否则用手动 goal+verify 循环。任务必须完整完成并验证时使用；触发词：ralph / 拉夫 / verify-fix / 必须做完。"
+---
+
+# oh-my-dsh · Ralph 持久验证循环
+
+目标必须**完整完成并验证过**，绝不允许静默的半成品。对应 OMC 的 Ralph 模式。DSH 原生就带 `ralph` 工具，所以这里分两条路：原生 Ralph，和手动 verify/fix 循环。
+
+## 何时用
+
+- 用户说"ralph""拉夫""一定要做完""不许半途""fresh-agent 迭代"。
+- 任务有硬验收标准，必须验证到全绿。
+- 普通的"做一下就完"不要用 Ralph——它重。
+
+## 路线 A：原生 ralph 工具
+
+用户**明确要求 Ralph/fresh-agent 迭代**时，直接调 `ralph` 工具：
+
+```
+ralph(objective, { maxRounds })
+```
+
+语义（和 goal 不同，务必分清）：
+
+- 每一轮开一个**全新子代理**，不继承任何对话种子。
+- **共享工作区是唯一长期记忆**——子代理通过读/写文件在轮次间传递上下文。
+- 只有一份**有界结构化报告**跨轮传递，其余什么都不带。
+- 返回：某个 worker 报告完成、或报告具体阻塞、或达到轮次上限。
+- 完成与阻塞是**worker 的自述报告，不是独立评估**——最后你要自己核验工作区里的真实产物。
+
+用 Ralph 时，你的职责是：写一个**不可变、可验收的 objective**；把验收标准和进度约定写进工作区文件（如 `RALPH.md`）让每轮子代理读到；循环结束后独立检查产物是否真达标。
+
+## 路线 B：手动 verify/fix 循环（原生 ralph 之外的默认）
+
+用户没明说要 fresh-agent 迭代、但任务必须验证到全绿时，用 goal + 验证代理手动循环：
+
+```
+1. create_goal(objective)           # 持久目标
+2. 实现（主控 or subagent 委托）
+3. verify：subagent 验证代理对照验收标准产出"通过/缺陷清单"
+4. fix：有缺陷就修，回到第 3 步
+5. 全绿 → update_goal complete；同一阻塞 ≥3 轮 → update_goal blocked
+```
+
+验证代理的提示词要**硬性**：逐条对照验收标准，只允许"通过"或"具体缺陷"，不允许"看起来没问题"这类模糊结论。
+
+## 与其它模式的关系
+
+- Ralph **包含并行**：执行和验证阶段内部照常并行 `subagent`（`execute` 的并行能力），只是外面多套一层"必须验证到全绿"。
+- Ralph 强调**不许静默半成品**；Autopilot 强调**单领导持续到底**。两者常叠加。
+- Ralph 的 verify/fix 循环，本质是把 `plan→execute→review→verify` 里的 `verify` 阶段反复执行到全绿。
+
+## 收尾：HUD
+
+每轮 verify/fix 后按 `omd-hud` 输出仪表盘：轮次、通过/缺陷计数、fix loop 次数。让"还剩几个缺陷"始终可见。
+
+## 反模式
+
+- 别把 Ralph 用在琐碎任务上。
+- 别把 worker 的"完成报告"当最终结论——你要亲自核验工作区。
+- fix loop 必须设上限，且必须有"全绿"这个明确退出条件。

package/skills/omd-ralplan/SKILL.md

@@ -1,45 +1,45 @@
----
-name: omd-ralplan
-description: "共识规划：多视角并行规划——派出多个独立规划子代理从不同角度切入，再运行结构化审议裁决分歧，收敛为一份共识计划。适合高风险或需求模糊、需要多视角规划的特性；触发词：ralplan / 共识规划 / 多方论证 / 审慎规划。"
----
-
-# oh-my-dsh · Ralplan 共识规划
-
-和 `plan` 一样产计划，但**多视角 + 结构化审议**：不让单一视角拍板，而是让多个独立规划子代理从不同角度出草案，再由仲裁子代理逐条裁决分歧，收敛成一份共识计划。对应 OMC 的 `ralplan`。
-
-## 何时用
-
-- 高风险、影响面大、或需求本身有争议的任务。
-- 用户说"ralplan""共识规划""多方论证""审慎规划""想清楚再定"。
-- 单一视角容易漏掉的：架构选型、数据迁移、安全边界、破坏性重构。
-
-## 三步收敛
-
-```
-并行规划草案（多视角） → 分歧识别与仲裁 → 合并成共识计划（必要时再迭代）
-```
-
-1. **并行草案**：派多个规划子代理（视角不同：架构 / 数据 / 安全 / 测试 / 迁移风险），各自独立产出带验收标准的计划草案，不许互相看结果。
-2. **仲裁**：派一个仲裁子代理读全部草案，列出**分歧点**，逐条裁决（选 A / 选 B / 折中），并给裁决理由。
-3. **合并**：把裁决后的方案合并成一份共识计划，附「分歧记录」：哪些已裁决、哪些仍未决。高风险时再迭代一轮（等同 `--deliberate`）。
-
-## 产出
-
-- 共识计划（任务分解 + 依赖 + 验收标准）；
-- 分歧记录表：分歧点 / 各方立场 / 裁决 / 理由，未决项显式列出，不许模糊掉。
-
-## 与其它模式的关系
-
-- `plan` = 单一规划者快速出计划；`ralplan` = 多视角 + 审议，更重、用于高风险。
-- 需求本身还没问清，先 `deep-interview`，再 `ralplan`。
-- `ralplan` 产出共识计划后，交给 `execute` → `review` → `verify`。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出：草案数 + 分歧数（已裁决/未决）+ 共识计划概览表。让"不同意见在哪、怎么裁的"可见。
-
-## 反模式
-
-- 别只用单一视角假装"共识"——至少 2–3 个独立视角。
-- 别把分歧静默合并掉——每个分歧要么裁决、要么显式标记未决。
-- 别无限迭代审议——设轮次上限，未决项按"影响面"排序取舍。
+---
+name: omd-ralplan
+description: "共识规划：多视角并行规划——派出多个独立规划子代理从不同角度切入，再运行结构化审议裁决分歧，收敛为一份共识计划。适合高风险或需求模糊、需要多视角规划的特性；触发词：ralplan / 共识规划 / 多方论证 / 审慎规划。"
+---
+
+# oh-my-dsh · Ralplan 共识规划
+
+和 `plan` 一样产计划，但**多视角 + 结构化审议**：不让单一视角拍板，而是让多个独立规划子代理从不同角度出草案，再由仲裁子代理逐条裁决分歧，收敛成一份共识计划。对应 OMC 的 `ralplan`。
+
+## 何时用
+
+- 高风险、影响面大、或需求本身有争议的任务。
+- 用户说"ralplan""共识规划""多方论证""审慎规划""想清楚再定"。
+- 单一视角容易漏掉的：架构选型、数据迁移、安全边界、破坏性重构。
+
+## 三步收敛
+
+```
+并行规划草案（多视角） → 分歧识别与仲裁 → 合并成共识计划（必要时再迭代）
+```
+
+1. **并行草案**：派多个规划子代理（视角不同：架构 / 数据 / 安全 / 测试 / 迁移风险），各自独立产出带验收标准的计划草案，不许互相看结果。
+2. **仲裁**：派一个仲裁子代理读全部草案，列出**分歧点**，逐条裁决（选 A / 选 B / 折中），并给裁决理由。
+3. **合并**：把裁决后的方案合并成一份共识计划，附「分歧记录」：哪些已裁决、哪些仍未决。高风险时再迭代一轮（等同 `--deliberate`）。
+
+## 产出
+
+- 共识计划（任务分解 + 依赖 + 验收标准）；
+- 分歧记录表：分歧点 / 各方立场 / 裁决 / 理由，未决项显式列出，不许模糊掉。
+
+## 与其它模式的关系
+
+- `plan` = 单一规划者快速出计划；`ralplan` = 多视角 + 审议，更重、用于高风险。
+- 需求本身还没问清，先 `deep-interview`，再 `ralplan`。
+- `ralplan` 产出共识计划后，交给 `execute` → `review` → `verify`。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出：草案数 + 分歧数（已裁决/未决）+ 共识计划概览表。让"不同意见在哪、怎么裁的"可见。
+
+## 反模式
+
+- 别只用单一视角假装"共识"——至少 2–3 个独立视角。
+- 别把分歧静默合并掉——每个分歧要么裁决、要么显式标记未决。
+- 别无限迭代审议——设轮次上限，未决项按"影响面"排序取舍。

package/skills/omd-release/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-release
-description: "发布：走完仓库的发布流程——版本号、changelog、测试、打 tag、构建——并产出发布检查清单。触发词：release / 发布 / 发版 / 打 tag / 打版本 / changelog。"
----
-
-# oh-my-dsh · Release 发布
-
-按仓库既有惯例走一遍发版流程，产出**可核对清单**。对应 OMC 的 `release` 工具 skill。
-
-## 何时用
-
-- 用户要发版本、打 tag、出 changelog、准备发布产物。
-- 需要把「改完了」推进到「可交付」。
-
-## 发布纪律
-
-1. **摸清惯例**：先 `read`/`grep` 看仓库有没有 CI、`CHANGELOG`、版本规则（semver?）、发布脚本。有 `.omc/RELEASE_RULE.md` 或 `docs/RELEASE.md` 先读它。
-2. **前置检查**：测试全绿、无未提交变更、依赖/构建通过（`pwsh`/`bash` 跑真实命令）。
-3. **版本号**：按语义化版本 bump（major/minor/patch），改到该改的地方（package.json 等）。
-4. **changelog**：按「新增/变更/修复/移除」归类写清改动。
-5. **tag 与产物**：打 tag，出构建产物（如 `pnpm pack` 出 `.tgz`）。
-
-## 与其它模式的关系
-
-- 发布前用 `omd-review` 复核改动，用 `omd-verify` 确认达标。
-- oh-my-dsh 自身的发布流程见 `docs/RELEASE.md`——本 skill 是通用发布纪律，二者不冲突。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出发布清单：`table`（检查项/状态/结果）+ `steps`（版本→changelog→tag→产物）。让「哪步做了、哪步待办、产物在哪」一眼可见。
-
-## 反模式
-
-- 别跳过前置测试就发版。
-- 别在没看仓库惯例的情况下凭空定版本/格式。
-- 别把「打了 tag」当成「发完了」——产物和说明都要落到位。
+---
+name: omd-release
+description: "发布：走完仓库的发布流程——版本号、changelog、测试、打 tag、构建——并产出发布检查清单。触发词：release / 发布 / 发版 / 打 tag / 打版本 / changelog。"
+---
+
+# oh-my-dsh · Release 发布
+
+按仓库既有惯例走一遍发版流程，产出**可核对清单**。对应 OMC 的 `release` 工具 skill。
+
+## 何时用
+
+- 用户要发版本、打 tag、出 changelog、准备发布产物。
+- 需要把「改完了」推进到「可交付」。
+
+## 发布纪律
+
+1. **摸清惯例**：先 `read`/`grep` 看仓库有没有 CI、`CHANGELOG`、版本规则（semver?）、发布脚本。有 `.omc/RELEASE_RULE.md` 或 `docs/RELEASE.md` 先读它。
+2. **前置检查**：测试全绿、无未提交变更、依赖/构建通过（`pwsh`/`bash` 跑真实命令）。
+3. **版本号**：按语义化版本 bump（major/minor/patch），改到该改的地方（package.json 等）。
+4. **changelog**：按「新增/变更/修复/移除」归类写清改动。
+5. **tag 与产物**：打 tag，出构建产物（如 `pnpm pack` 出 `.tgz`）。
+
+## 与其它模式的关系
+
+- 发布前用 `omd-review` 复核改动，用 `omd-verify` 确认达标。
+- oh-my-dsh 自身的发布流程见 `docs/RELEASE.md`——本 skill 是通用发布纪律，二者不冲突。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出发布清单：`table`（检查项/状态/结果）+ `steps`（版本→changelog→tag→产物）。让「哪步做了、哪步待办、产物在哪」一眼可见。
+
+## 反模式
+
+- 别跳过前置测试就发版。
+- 别在没看仓库惯例的情况下凭空定版本/格式。
+- 别把「打了 tag」当成「发完了」——产物和说明都要落到位。

package/skills/omd-remember/SKILL.md

@@ -1,35 +1,35 @@
----
-name: omd-remember
-description: "记住：把持久化的笔记、决策与事实写入工作区记忆文件，让它们在压缩和后续会话中留存。触发词：remember / 记住 / 记下来 / 别忘 / 存个备忘 / 记录这个决定。"
----
-
-# oh-my-dsh · Remember 跨会话记忆
-
-把**该跨轮/跨会话存续**的信息落到工作区记忆文件，避免被压缩或新会话冲掉。对应 OMC 的 `remember` / `note` 工具 skill。
-
-## 何时用
-
-- 用户说「记住这个」「别忘」「记一下这个决定/约定/事实」。
-- 有需要在后续会话继续用到的决策、约定、环境事实。
-
-## 记忆纪律
-
-1. **落盘**：写到工作区里的记忆文件（如 `OMD_MEMORY.md` 或 `.omd/memory.md`），别只留在对话里——对话会被压缩。
-2. **结构化**：每条含「标签 + 内容 + 日期 + 为什么重要」，便于检索。
-3. **区分**：事实（环境/路径/账号无关的约定）vs 决策（为什么这么选）vs 待办（后续要做的）。
-4. **取用**：新会话开头或遇到「之前说过……」时，先 `read` 记忆文件再答。
-
-## 与其它模式的关系
-
-- `remember` 存的是「跨会话事实」，`omd-wiki` 存的是「成体系的知识」——单条零散事实用 remember，成页文档用 wiki。
-- 记忆文件本身也要遵守 `omd-minimal-code-discipline`：只记值得记的，别堆噪音。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出记忆摘要：`table`（标签/内容摘要/类型/日期）+ `keyvalue`（记忆文件路径）。让「记了什么、存哪了」一眼可见。
-
-## 反模式
-
-- 别把记忆只留在对话正文——不落盘就丢。
-- 别把大段代码/文档当「记忆」塞进去——那该进 wiki 或仓库文件。
-- 别重复记已经存在的条目，先查再写。
+---
+name: omd-remember
+description: "记住：把持久化的笔记、决策与事实写入工作区记忆文件，让它们在压缩和后续会话中留存。触发词：remember / 记住 / 记下来 / 别忘 / 存个备忘 / 记录这个决定。"
+---
+
+# oh-my-dsh · Remember 跨会话记忆
+
+把**该跨轮/跨会话存续**的信息落到工作区记忆文件，避免被压缩或新会话冲掉。对应 OMC 的 `remember` / `note` 工具 skill。
+
+## 何时用
+
+- 用户说「记住这个」「别忘」「记一下这个决定/约定/事实」。
+- 有需要在后续会话继续用到的决策、约定、环境事实。
+
+## 记忆纪律
+
+1. **落盘**：写到工作区里的记忆文件（如 `OMD_MEMORY.md` 或 `.omd/memory.md`），别只留在对话里——对话会被压缩。
+2. **结构化**：每条含「标签 + 内容 + 日期 + 为什么重要」，便于检索。
+3. **区分**：事实（环境/路径/账号无关的约定）vs 决策（为什么这么选）vs 待办（后续要做的）。
+4. **取用**：新会话开头或遇到「之前说过……」时，先 `read` 记忆文件再答。
+
+## 与其它模式的关系
+
+- `remember` 存的是「跨会话事实」，`omd-wiki` 存的是「成体系的知识」——单条零散事实用 remember，成页文档用 wiki。
+- 记忆文件本身也要遵守 `omd-minimal-code-discipline`：只记值得记的，别堆噪音。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出记忆摘要：`table`（标签/内容摘要/类型/日期）+ `keyvalue`（记忆文件路径）。让「记了什么、存哪了」一眼可见。
+
+## 反模式
+
+- 别把记忆只留在对话正文——不落盘就丢。
+- 别把大段代码/文档当「记忆」塞进去——那该进 wiki 或仓库文件。
+- 别重复记已经存在的条目，先查再写。