@hawk2048/oh-my-dsh 0.2.1 → 0.3.3

package/skills/omd-ultrathink/SKILL.md

@@ -1,39 +1,39 @@
----
-name: omd-ultrathink
-description: "深度思考：行动前穷举边界情况、权衡备选方案、预演失败模式。触发词：ultrathink / 深度思考 / 想清楚 / 多想想 / 别急着动手 / 三思；任何工具使用前需要深度推理时。"
----
-
-# oh-my-dsh · Ultrathink 深度推理
-
-动手前把问题想透：穷举边界、权衡备选、预演失败，**先想清楚再调用工具**。对应 OMC 的 `ultrathink` 提示词触发模式。
-
-## 何时用
-
-- 决策影响大或不可逆，值得慢下来想清楚。
-- 用户明确说「先想清楚/别急着动手/多权衡」。
-
-## 推理纪律
-
-1. **定义问题**：先用一句话写清目标与约束（要什么、不要什么、边界在哪）。
-2. **枚举方案**：列出可行的候选，不急着锁第一个。
-3. **穷举边界**：极端输入、空值、并发、失败、回滚、向后兼容……
-4. **预演失败**：每个方案最坏会怎样？什么信号说明它错了？
-5. **决策**：按目标给一个主选 + 一个备选，说明为什么。
-
-关键：**这段推理写在回答正文里**，先不刷工具。想清楚后，要执行再转 `omd-plan` / `omd-execute`。
-
-## 与其它模式的关系
-
-- `ultrathink` 是纯推理，不查代码；要看证据用 `omd-deep-analyze`。
-- 推理结论要落地成步骤转 `omd-plan`；要直接开干转 `omd-execute`。
-- 需求没问清用 `omd-deep-interview`，别在假设上 long 推理。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出决策摘要：方案对比表 + 风险清单 + 主选/备选。让「想过什么、选了谁、为什么」一眼可见。
-
-## 反模式
-
-- 别在没想清楚前就开始 `write`/`edit`——那是边做边猜。
-- 别只列一个方案就下结论，至少给备选。
-- 别把 ultrathink 拖成无限空想：想清楚一轮就产出决策，需要证据就转 deep-analyze。
+---
+name: omd-ultrathink
+description: "深度思考：行动前穷举边界情况、权衡备选方案、预演失败模式。触发词：ultrathink / 深度思考 / 想清楚 / 多想想 / 别急着动手 / 三思；任何工具使用前需要深度推理时。"
+---
+
+# oh-my-dsh · Ultrathink 深度推理
+
+动手前把问题想透：穷举边界、权衡备选、预演失败，**先想清楚再调用工具**。对应 OMC 的 `ultrathink` 提示词触发模式。
+
+## 何时用
+
+- 决策影响大或不可逆，值得慢下来想清楚。
+- 用户明确说「先想清楚/别急着动手/多权衡」。
+
+## 推理纪律
+
+1. **定义问题**：先用一句话写清目标与约束（要什么、不要什么、边界在哪）。
+2. **枚举方案**：列出可行的候选，不急着锁第一个。
+3. **穷举边界**：极端输入、空值、并发、失败、回滚、向后兼容……
+4. **预演失败**：每个方案最坏会怎样？什么信号说明它错了？
+5. **决策**：按目标给一个主选 + 一个备选，说明为什么。
+
+关键：**这段推理写在回答正文里**，先不刷工具。想清楚后，要执行再转 `omd-plan` / `omd-execute`。
+
+## 与其它模式的关系
+
+- `ultrathink` 是纯推理，不查代码；要看证据用 `omd-deep-analyze`。
+- 推理结论要落地成步骤转 `omd-plan`；要直接开干转 `omd-execute`。
+- 需求没问清用 `omd-deep-interview`，别在假设上 long 推理。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出决策摘要：方案对比表 + 风险清单 + 主选/备选。让「想过什么、选了谁、为什么」一眼可见。
+
+## 反模式
+
+- 别在没想清楚前就开始 `write`/`edit`——那是边做边猜。
+- 别只列一个方案就下结论，至少给备选。
+- 别把 ultrathink 拖成无限空想：想清楚一轮就产出决策，需要证据就转 deep-analyze。

package/skills/omd-verify/SKILL.md

@@ -1,44 +1,44 @@
----
-name: omd-verify
-description: "验证：宣称完成前先验证——跑测试/构建、对照验收标准、收集证据（小规模内联，大规模/安全走子代理），失败则迭代。作为 plan→execute→review→verify 的最终阶段；触发词：verify / 验证 / 测试 / 检查 / 跑通。"
----
-
-# oh-my-dsh · Verify 验证
-
-在宣布"完成"之前，**拿出证据**证明它真的符合验收标准。对应 OMC 的 `verify` 工作流（Tier-0 流水线末段：`plan → execute → review → verify`）。
-
-## 何时用
-
-- `execute`/`review` 之后，需要证明"真跑通了、真达标了"。
-- 用户说"验证""测试""检查""跑一遍确认"。
-
-## 验证动作
-
-- **跑测试/构建**：用 `pwsh`（Windows）或 `bash` 执行测试、lint、构建命令；`run_in_background: true` 跑长任务，用 `job_output` 收结果。
-- **对照验收标准**：回到 `plan` 阶段写下的验收标准，逐条核，只允许"通过"或"具体失败"，不允许"应该没问题"。
-- **收集证据**：测试输出、命令退出码、产物文件——把这些作为"已完成"的依据写进回答。
-
-## 按规模选验证者
-
-- **小改动**：直接内联验证（自己跑命令、看输出）。
-- **标准改动**：跑测试 + 对照验收标准。
-- **大/安全敏感改动**：派 `subagent` 验证代理，独立复核，别只信自己一眼。
-
-## 失败则迭代
-
-验证失败不是结束——把失败项回给 `execute`（修）→ `review`（评）→ `verify`（再验），循环直到全绿。这才是 `plan → execute → review → verify` 闭环的意义。
-
-## 与其它阶段的关系
-
-- `verify` 是"证据层"，`review` 是"质量层"；缺一不可。
-- 别把"测试全绿"当唯一标准——还要对照验收标准和真实产物。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出验证结果：验收标准表（逐条通过/失败）+ 测试命令与结果。让"哪些验收过了、哪些还红着"一眼可见。
-
-## 反模式
-
-- 别在没跑测试、没证据时宣布"完成"。
-- 别把 `test.skip`/`.only`、TODO 占位当通过。
-- 验证失败别沉默绕过——要么修，要么把阻塞显式报告出来。
+---
+name: omd-verify
+description: "验证：宣称完成前先验证——跑测试/构建、对照验收标准、收集证据（小规模内联，大规模/安全走子代理），失败则迭代。作为 plan→execute→review→verify 的最终阶段；触发词：verify / 验证 / 测试 / 检查 / 跑通。"
+---
+
+# oh-my-dsh · Verify 验证
+
+在宣布"完成"之前，**拿出证据**证明它真的符合验收标准。对应 OMC 的 `verify` 工作流（Tier-0 流水线末段：`plan → execute → review → verify`）。
+
+## 何时用
+
+- `execute`/`review` 之后，需要证明"真跑通了、真达标了"。
+- 用户说"验证""测试""检查""跑一遍确认"。
+
+## 验证动作
+
+- **跑测试/构建**：用 `pwsh`（Windows）或 `bash` 执行测试、lint、构建命令；`run_in_background: true` 跑长任务，用 `job_output` 收结果。
+- **对照验收标准**：回到 `plan` 阶段写下的验收标准，逐条核，只允许"通过"或"具体失败"，不允许"应该没问题"。
+- **收集证据**：测试输出、命令退出码、产物文件——把这些作为"已完成"的依据写进回答。
+
+## 按规模选验证者
+
+- **小改动**：直接内联验证（自己跑命令、看输出）。
+- **标准改动**：跑测试 + 对照验收标准。
+- **大/安全敏感改动**：派 `subagent` 验证代理，独立复核，别只信自己一眼。
+
+## 失败则迭代
+
+验证失败不是结束——把失败项回给 `execute`（修）→ `review`（评）→ `verify`（再验），循环直到全绿。这才是 `plan → execute → review → verify` 闭环的意义。
+
+## 与其它阶段的关系
+
+- `verify` 是"证据层"，`review` 是"质量层"；缺一不可。
+- 别把"测试全绿"当唯一标准——还要对照验收标准和真实产物。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出验证结果：验收标准表（逐条通过/失败）+ 测试命令与结果。让"哪些验收过了、哪些还红着"一眼可见。
+
+## 反模式
+
+- 别在没跑测试、没证据时宣布"完成"。
+- 别把 `test.skip`/`.only`、TODO 占位当通过。
+- 验证失败别沉默绕过——要么修，要么把阻塞显式报告出来。

package/skills/omd-visual-verdict/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-visual-verdict
-description: "视觉裁决：把截图或渲染输出与参考对照，给出结构化的通过/失败裁决与具体差异。触发词：visual-verdict / 对比截图 / 看下 UI 对不对 / 视觉检查 / 对比这两张图。"
----
-
-# oh-my-dsh · Visual-verdict 视觉 QA
-
-对比渲染产物与参考图，给出**结构化、可执行**的通过/不通过判定。对应 OMC 的 `visual-verdict` skill。
-
-## 何时用
-
-- 有截图/渲染图要跟设计稿或参考图对比。
-- 用户要「UI 哪里不对」「视觉走查」的结论。
-
-## 判定纪律
-
-1. **读图**：用 `read_image` 读待检图与参考图，逐张看。
-2. **逐维度对比**：布局、颜色、字体字号、间距、文本内容、对齐、溢出——每项单独判。
-3. **给具体差异**：不通过项写清「在哪、期望 vs 实际」，能定位到元素就定位。
-4. **出判定**：汇总成 `pass` / `fail`（或 `partial`），并给可执行修复项。
-
-## 与其它模式的关系
-
-- 发现视觉缺陷后，转 `omd-debug` 定位代码、`omd-execute` 修。
-- 有设计稿/参考文档时先用 `omd-external-context` 把参考吃进来再比。
-- 修完再跑一遍本判定，形成闭环。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出判定：`table`（维度/期望/实际/通过?）+ `stat`（通过/失败计数）+ `callout`（总体判定）。让「哪里不对、差多少」一眼可见。
-
-## 反模式
-
-- 别只看一眼就给「差不多」，逐维度核对。
-- 别给「颜色有点不一样」这种模糊结论——说清具体差在哪。
-- 别把「无法判断」伪装成 pass；拿不准就标 partial 并说明原因。
+---
+name: omd-visual-verdict
+description: "视觉裁决：把截图或渲染输出与参考对照，给出结构化的通过/失败裁决与具体差异。触发词：visual-verdict / 对比截图 / 看下 UI 对不对 / 视觉检查 / 对比这两张图。"
+---
+
+# oh-my-dsh · Visual-verdict 视觉 QA
+
+对比渲染产物与参考图，给出**结构化、可执行**的通过/不通过判定。对应 OMC 的 `visual-verdict` skill。
+
+## 何时用
+
+- 有截图/渲染图要跟设计稿或参考图对比。
+- 用户要「UI 哪里不对」「视觉走查」的结论。
+
+## 判定纪律
+
+1. **读图**：用 `read_image` 读待检图与参考图，逐张看。
+2. **逐维度对比**：布局、颜色、字体字号、间距、文本内容、对齐、溢出——每项单独判。
+3. **给具体差异**：不通过项写清「在哪、期望 vs 实际」，能定位到元素就定位。
+4. **出判定**：汇总成 `pass` / `fail`（或 `partial`），并给可执行修复项。
+
+## 与其它模式的关系
+
+- 发现视觉缺陷后，转 `omd-debug` 定位代码、`omd-execute` 修。
+- 有设计稿/参考文档时先用 `omd-external-context` 把参考吃进来再比。
+- 修完再跑一遍本判定，形成闭环。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出判定：`table`（维度/期望/实际/通过?）+ `stat`（通过/失败计数）+ `callout`（总体判定）。让「哪里不对、差多少」一眼可见。
+
+## 反模式
+
+- 别只看一眼就给「差不多」，逐维度核对。
+- 别给「颜色有点不一样」这种模糊结论——说清具体差在哪。
+- 别把「无法判断」伪装成 pass；拿不准就标 partial 并说明原因。

package/skills/omd-wiki/SKILL.md

@@ -1,36 +1,36 @@
----
-name: omd-wiki
-description: "知识库：维护工作区里的轻量 markdown 知识库——创建、更新、交叉链接页面，并让它们与代码保持一致。触发词：wiki / 记到知识库 / 更新文档 / 维护文档 / 写进 wiki。"
----
-
-# oh-my-dsh · Wiki 知识库维护
-
-在**工作区内**维护一套轻量 markdown 知识库，让它与代码同步。对应 OMC 的 `wiki` 工具 skill。
-
-## 何时用
-
-- 用户要把知识/决策/架构沉淀成文档。
-- 已有 wiki/文档目录（如 `docs/`、`wiki/`）需要增改维护。
-
-## 维护纪律
-
-1. **约定位置**：确认知识库存哪（`docs/` 或专用目录），沿用既有结构与命名。
-2. **单页单一主题**：一页讲清一件事，页间用相对链接交叉引用。
-3. **与代码同步**：文档描述的行为/接口要在代码里核对（`grep`/`read`），别写陈旧的。
-4. **精炼**：写「决策 + 为什么 + 关键事实」，别堆过程流水账（配合 `omd-ai-slop-cleaner`）。
-
-## 与其它模式的关系
-
-- `wiki` 存「成体系知识」，`omd-remember` 存「单条跨会话事实」，`omd-skillify` 存「可复用流程」。
-- 文档要反映设计时，先用 `omd-deep-analyze` 把架构吃透再写。
-- 发布前用 `omd-release` 核对文档是否随版本更新。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出文档变更：`table`（页面/新增或更新/要点）+ `keyvalue`（知识库路径）。让「改了哪些页、内容是什么」一眼可见。
-
-## 反模式
-
-- 别把文档写得和代码脱节——写完核对一遍。
-- 别一页塞十个主题，拆开并交叉链接。
-- 别重复已有内容，先 `read` 现有页面再增补。
+---
+name: omd-wiki
+description: "知识库：维护工作区里的轻量 markdown 知识库——创建、更新、交叉链接页面，并让它们与代码保持一致。触发词：wiki / 记到知识库 / 更新文档 / 维护文档 / 写进 wiki。"
+---
+
+# oh-my-dsh · Wiki 知识库维护
+
+在**工作区内**维护一套轻量 markdown 知识库，让它与代码同步。对应 OMC 的 `wiki` 工具 skill。
+
+## 何时用
+
+- 用户要把知识/决策/架构沉淀成文档。
+- 已有 wiki/文档目录（如 `docs/`、`wiki/`）需要增改维护。
+
+## 维护纪律
+
+1. **约定位置**：确认知识库存哪（`docs/` 或专用目录），沿用既有结构与命名。
+2. **单页单一主题**：一页讲清一件事，页间用相对链接交叉引用。
+3. **与代码同步**：文档描述的行为/接口要在代码里核对（`grep`/`read`），别写陈旧的。
+4. **精炼**：写「决策 + 为什么 + 关键事实」，别堆过程流水账（配合 `omd-ai-slop-cleaner`）。
+
+## 与其它模式的关系
+
+- `wiki` 存「成体系知识」，`omd-remember` 存「单条跨会话事实」，`omd-skillify` 存「可复用流程」。
+- 文档要反映设计时，先用 `omd-deep-analyze` 把架构吃透再写。
+- 发布前用 `omd-release` 核对文档是否随版本更新。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出文档变更：`table`（页面/新增或更新/要点）+ `keyvalue`（知识库路径）。让「改了哪些页、内容是什么」一眼可见。
+
+## 反模式
+
+- 别把文档写得和代码脱节——写完核对一遍。
+- 别一页塞十个主题，拆开并交叉链接。
+- 别重复已有内容，先 `read` 现有页面再增补。