@hawk2048/oh-my-dsh 0.2.0 → 0.3.2

package/skills/omd-hud/SKILL.md

@@ -1,79 +1,80 @@
----
-name: omd-hud
-description: "HUD: render live orchestration progress as an inline dsh-ui dashboard — stat cards, progress bars, timeline, and a subagent-status table. Use to show real-time progress of any oh-my-dsh mode (plan/execute/review/verify/team/autopilot/ralph/deep-interview/ralplan/research/autoresearch/ultragoal/tdd/deepsearch/deep-analyze/ultrathink/ai-slop-cleaner/debug/release/remember/cancel/minimal-code-discipline/external-context/visual-verdict/skillify/wiki/help/doctor)."
----
-
-# oh-my-dsh · HUD 实时进度仪表盘
-
-把编排进度渲染成内联 `dsh-ui` 仪表盘，嵌在回答正文里。对应 OMC 的 HUD 状态栏。渲染语法见 `genui` skill——本节只讲编排场景该怎么摆。
-
-## 何时用
-
-任何 oh-my-dsh 模式跑起来后，**每个阶段/每轮结束**都输出一段 HUD，让用户一眼看到：目标、进度、子代理状态、下一步。别等全跑完才汇报。
-
-## 仪表盘骨架
-
-一个 HUD 块由「标题 + stat 概览 + 进度 + 子代理状态表 + 下一步」组成：
-
-```dsh-ui
-{"title":"Autopilot · 重构认证模块","gap":14,"items":[
-  {"type":"row","wrap":true,"items":[
-    {"type":"stat","label":"目标轮次","value":"3 / 6"},
-    {"type":"stat","label":"子代理","value":"2 运行中"},
-    {"type":"stat","label":"通过 / 缺陷","value":"14 / 2"}
-  ]},
-  {"type":"progress","label":"整体进度","value":62},
-  {"type":"table","columns":["代理","任务","状态"],
-   "rows":[["team-plan","拆解任务","done"],["exec-auth","实现认证","running"],["exec-ui","实现界面","queued"]]},
-  {"type":"callout","tone":"info","title":"下一步","content":"等待 exec-auth 完成后进入 verify 阶段"}
-]}
-```
-
-## 每个模式用什么组件
-
-| 模式 | 推荐组件 |
-|------|---------|
-| Plan | `table`（任务/依赖/验收）+ `steps`（流水线位置） |
-| Execute | `progress`（todo 进度）+ `table`（子代理状态） |
-| Review | `table`（issues：位置/严重度/状态）+ `stat`（通过/缺陷） |
-| Verify | `table`（验收标准逐条通过/失败）+ `stat`（通过计数） |
-| Team | `steps`（五阶段）+ `table`（阶段→状态）+ `progress` |
-| Autopilot | `stat`（轮次/进度）+ `progress` + `todo` 进度 |
-| Ralph | `stat`（通过/缺陷/轮次）+ `timeline`（fix loop 轨迹） |
-| Deep Interview | `keyvalue`/`table`（维度→已澄清/待澄清）+ `progress`（澄清度） |
-| Ralplan | `table`（草案/分歧/裁决）+ `stat`（已裁决/未决） |
-| Research | `table`（结论/证据/来源）+ `stat`（来源计数） |
-| Autoresearch | `stat`（轮次/评分）+ `table`（差距清单） |
-| Ultragoal | `table`（子目标→状态/checkpoint）+ `progress` |
-| TDD | `steps`（红绿重构）+ `table`（用例→状态） |
-| Deepsearch | `table`（符号/文件/行号/角色） |
-| Deep-analyze | `table`（视角/发现）+ `table`（方案权衡） |
-| Ultrathink | `table`（方案对比）+ `list`（风险） |
-| AI-slop-cleaner | `table`（删除条目/前后字数） |
-| Doctor | `table`（检查项/状态/证据） |
-| Debug | `timeline`（复现→定位→修复→验证）+ `table`（根因/修复/回归） |
-| Release | `table`（检查项/状态）+ `steps`（版本→changelog→tag→产物） |
-| Remember | `table`（标签/摘要/类型）+ `keyvalue`（记忆文件路径） |
-| Cancel | `table`（对象/动作/结果）+ `callout`（恢复方式） |
-| Minimal-code-discipline | `table`（文件/改动/必要性）+ `stat`（净增删行） |
-| External-context | `table`（来源/关键事实）+ `list`（引用 URL） |
-| Visual-verdict | `table`（维度/期望/实际/通过?）+ `stat`（通过/失败） |
-| Skillify | `keyvalue`（新 skill/路径）+ `table`（步骤/触发词） |
-| Wiki | `table`（页面/增改/要点）+ `keyvalue`（知识库路径） |
-| Help | `table`（分类/技能/用途）+ `table`（命令→模式） |
-
-## 常用组件速查（详见 genui）
-
-- `stat`: `{"type":"stat","label":"…","value":"…","delta":"+12%"}`（`-` 开头自动红、`+` 绿）
-- `progress`: `{"type":"progress","label":"…","value":62}`
-- `table`: `{"type":"table","columns":[…],"rows":[[…]]}`
-- `steps` / `timeline`: 流程与轨迹
-- `badge` / `callout`: 状态徽标与提示
-- `mermaid`: 阶段流程图/依赖图
-
-## 纪律
-
-- HUD 是**进度快照**，不是最终总结——每个阶段/每轮都更新，状态要真实（运行中的写 running，别虚报 done）。
-- 状态词统一：`done` / `running` / `queued` / `failed`。
-- HUD 块照常穿插在文字前后，组件就是回答的一部分，不是单独的工具调用。
-- 别在 HUD 里塞巨量数据——只放「决策所需」的关键指标。
+---
+name: omd-hud
+description: "HUD：把编排进度渲染成内联 dsh-ui 仪表盘——统计卡片、进度条、时间线与子代理状态表。用于实时展示任意 oh-my-dsh 模式的进度（plan/execute/review/verify/team/autopilot/ralph/deep-interview/ralplan/research/autoresearch/ultragoal/pyramid/tdd/deepsearch/deep-analyze/ultrathink/ai-slop-cleaner/debug/release/remember/cancel/minimal-code-discipline/external-context/visual-verdict/skillify/wiki/help/doctor）。"
+---
+
+# oh-my-dsh · HUD 实时进度仪表盘
+
+把编排进度渲染成内联 `dsh-ui` 仪表盘，嵌在回答正文里。对应 OMC 的 HUD 状态栏。渲染语法见 `genui` skill——本节只讲编排场景该怎么摆。
+
+## 何时用
+
+任何 oh-my-dsh 模式跑起来后，**每个阶段/每轮结束**都输出一段 HUD，让用户一眼看到：目标、进度、子代理状态、下一步。别等全跑完才汇报。
+
+## 仪表盘骨架
+
+一个 HUD 块由「标题 + stat 概览 + 进度 + 子代理状态表 + 下一步」组成：
+
+```dsh-ui
+{"title":"Autopilot · 重构认证模块","gap":14,"items":[
+  {"type":"row","wrap":true,"items":[
+    {"type":"stat","label":"目标轮次","value":"3 / 6"},
+    {"type":"stat","label":"子代理","value":"2 运行中"},
+    {"type":"stat","label":"通过 / 缺陷","value":"14 / 2"}
+  ]},
+  {"type":"progress","label":"整体进度","value":62},
+  {"type":"table","columns":["代理","任务","状态"],
+   "rows":[["team-plan","拆解任务","done"],["exec-auth","实现认证","running"],["exec-ui","实现界面","queued"]]},
+  {"type":"callout","tone":"info","title":"下一步","content":"等待 exec-auth 完成后进入 verify 阶段"}
+]}
+```
+
+## 每个模式用什么组件
+
+| 模式 | 推荐组件 |
+|------|---------|
+| Plan | `table`（任务/依赖/验收）+ `steps`（流水线位置） |
+| Execute | `progress`（todo 进度）+ `table`（子代理状态） |
+| Review | `table`（issues：位置/严重度/状态）+ `stat`（通过/缺陷） |
+| Verify | `table`（验收标准逐条通过/失败）+ `stat`（通过计数） |
+| Team | `steps`（五阶段）+ `table`（阶段→状态）+ `progress` |
+| Autopilot | `stat`（轮次/进度）+ `progress` + `todo` 进度 |
+| Ralph | `stat`（通过/缺陷/轮次）+ `timeline`（fix loop 轨迹） |
+| Deep Interview | `keyvalue`/`table`（维度→已澄清/待澄清）+ `progress`（澄清度） |
+| Ralplan | `table`（草案/分歧/裁决）+ `stat`（已裁决/未决） |
+| Research | `table`（结论/证据/来源）+ `stat`（来源计数） |
+| Autoresearch | `stat`（轮次/评分）+ `table`（差距清单） |
+| Ultragoal | `table`（子目标→状态/checkpoint）+ `progress` |
+| Pyramid | `stat`（结论位置/要点数/MECE 缺口）+ `table`（层→原状/改后）+ `callout`（下一步） |
+| TDD | `steps`（红绿重构）+ `table`（用例→状态） |
+| Deepsearch | `table`（符号/文件/行号/角色） |
+| Deep-analyze | `table`（视角/发现）+ `table`（方案权衡） |
+| Ultrathink | `table`（方案对比）+ `list`（风险） |
+| AI-slop-cleaner | `table`（删除条目/前后字数） |
+| Doctor | `table`（检查项/状态/证据） |
+| Debug | `timeline`（复现→定位→修复→验证）+ `table`（根因/修复/回归） |
+| Release | `table`（检查项/状态）+ `steps`（版本→changelog→tag→产物） |
+| Remember | `table`（标签/摘要/类型）+ `keyvalue`（记忆文件路径） |
+| Cancel | `table`（对象/动作/结果）+ `callout`（恢复方式） |
+| Minimal-code-discipline | `table`（文件/改动/必要性）+ `stat`（净增删行） |
+| External-context | `table`（来源/关键事实）+ `list`（引用 URL） |
+| Visual-verdict | `table`（维度/期望/实际/通过?）+ `stat`（通过/失败） |
+| Skillify | `keyvalue`（新 skill/路径）+ `table`（步骤/触发词） |
+| Wiki | `table`（页面/增改/要点）+ `keyvalue`（知识库路径） |
+| Help | `table`（分类/技能/用途）+ `table`（命令→模式） |
+
+## 常用组件速查（详见 genui）
+
+- `stat`: `{"type":"stat","label":"…","value":"…","delta":"+12%"}`（`-` 开头自动红、`+` 绿）
+- `progress`: `{"type":"progress","label":"…","value":62}`
+- `table`: `{"type":"table","columns":[…],"rows":[[…]]}`
+- `steps` / `timeline`: 流程与轨迹
+- `badge` / `callout`: 状态徽标与提示
+- `mermaid`: 阶段流程图/依赖图
+
+## 纪律
+
+- HUD 是**进度快照**，不是最终总结——每个阶段/每轮都更新，状态要真实（运行中的写 running，别虚报 done）。
+- 状态词统一：`done` / `running` / `queued` / `failed`。
+- HUD 块照常穿插在文字前后，组件就是回答的一部分，不是单独的工具调用。
+- 别在 HUD 里塞巨量数据——只放「决策所需」的关键指标。

package/skills/omd-minimal-code-discipline/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-minimal-code-discipline
-description: "Minimal-code-discipline: make the smallest correct diff — existence-first, reuse before writing, shortest correct change. Use when the user says minimal / 最小改动 / YAGNI / 别过度设计 / 只改必要的 / 能复用就复用."
----
-
-# oh-my-dsh · Minimal-code-discipline 最小改动纪律
-
-用**最短的正确 diff** 达成目标：先确认已有，能复用就复用，不写投机抽象。对应 OMC 的 `minimal-code-discipline`（YAGNI-ladder 写作时纪律）。
-
-## 何时用
-
-- 用户要求「最小改动」「别过度设计」「只改必要的」。
-- 任何改代码的场景，作为默认写作纪律兜底。
-
-## 纪律阶梯
-
-1. **存在优先**：动手前先 `grep`/`glob` 确认有没有现成实现、工具函数、约定——已存在的就不写。
-2. **复用优先**：能调已有函数/类型/配置就别重写。
-3. **最短正确 diff**：只改达成目标必须改的那几行，不顺手重构、不格式化无关代码。
-4. **YAGNI**：不为「以后可能要」提前抽象；需要时再提炼，提炼要有第二个使用点作依据。
-
-## 与其它模式的关系
-
-- `omd-execute` 的实现阶段应默认套用本纪律，避免 diff 膨胀。
-- `omd-review` 要专门盯「超出必要范围的改动」。
-- 与 `omd-ai-slop-cleaner` 互补：一个管「改得少」，一个管「写得干净」。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出改动范围：`table`（文件/改动/是否必要/能否更小）+ `stat`（净增删行数）。让「改了多少、为什么不能再小」一眼可见。
-
-## 反模式
-
-- 别为了「整洁」顺手改与目标无关的代码。
-- 别在没有第二个使用点时就抽象出通用层。
-- 别把「最小」当成「偷懒跳过必要处理」——正确性优先于行数。
+---
+name: omd-minimal-code-discipline
+description: "最小改动纪律：做最小而正确的改动——先确认存在、能复用就不新写、最短的正确修改。触发词：minimal / 最小改动 / YAGNI / 别过度设计 / 只改必要的 / 能复用就复用。"
+---
+
+# oh-my-dsh · Minimal-code-discipline 最小改动纪律
+
+用**最短的正确 diff** 达成目标：先确认已有，能复用就复用，不写投机抽象。对应 OMC 的 `minimal-code-discipline`（YAGNI-ladder 写作时纪律）。
+
+## 何时用
+
+- 用户要求「最小改动」「别过度设计」「只改必要的」。
+- 任何改代码的场景，作为默认写作纪律兜底。
+
+## 纪律阶梯
+
+1. **存在优先**：动手前先 `grep`/`glob` 确认有没有现成实现、工具函数、约定——已存在的就不写。
+2. **复用优先**：能调已有函数/类型/配置就别重写。
+3. **最短正确 diff**：只改达成目标必须改的那几行，不顺手重构、不格式化无关代码。
+4. **YAGNI**：不为「以后可能要」提前抽象；需要时再提炼，提炼要有第二个使用点作依据。
+
+## 与其它模式的关系
+
+- `omd-execute` 的实现阶段应默认套用本纪律，避免 diff 膨胀。
+- `omd-review` 要专门盯「超出必要范围的改动」。
+- 与 `omd-ai-slop-cleaner` 互补：一个管「改得少」，一个管「写得干净」。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出改动范围：`table`（文件/改动/是否必要/能否更小）+ `stat`（净增删行数）。让「改了多少、为什么不能再小」一眼可见。
+
+## 反模式
+
+- 别为了「整洁」顺手改与目标无关的代码。
+- 别在没有第二个使用点时就抽象出通用层。
+- 别把「最小」当成「偷懒跳过必要处理」——正确性优先于行数。

package/skills/omd-plan/SKILL.md

@@ -1,51 +1,51 @@
----
-name: omd-plan
-description: "Plan: explore first with non-mutating reads/search/static analysis, then produce a concrete implementation plan (task breakdown with dependencies + acceptance criteria + file-level changes). No implementation. Use as the first stage of the plan→execute→review→verify pipeline, or when the user asks to 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: persistent verify/fix loops with no silent partials. Use the native ralph tool for explicit fresh-agent iteration, or the manual goal+verify loop otherwise. Use when the task must complete fully with verification, or the user says 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 必须设上限，且必须有"全绿"这个明确退出条件。