@hawk2048/oh-my-dsh 0.2.1 → 0.3.2

package/skills/omd-tdd/SKILL.md

@@ -1,37 +1,37 @@
----
-name: omd-tdd
-description: "测试驱动开发：先写会失败的测试，再做最小实现，然后重构（红-绿-重构）。触发词：tdd / 测试驱动 / 先写测试 / red-green / 红绿重构；或想用测试驱动开发时。"
----
-
-# oh-my-dsh · TDD 测试驱动开发
-
-严格按 **red → green → refactor** 循环驱动实现：先有失败测试，再有最小实现，最后重构。对应 OMC 的 `tdd` 提示词触发模式。
-
-## 何时用
-
-- 用户明确要 TDD、`tdd`、先写测试、红绿重构。
-- 功能有清晰的可验证行为（输入→输出），适合先定测试。
-
-## 循环纪律
-
-1. **Red（红）**：先写一个**会失败**的测试，用它能跑的真实命令（`pwsh`/`bash` 的测试命令，或项目既有测试框架）。
-2. **Green（绿）**：写**最小**实现让测试通过，不做多余设计。
-3. **Refactor（重构）**：测试全绿后再清理重复、改善命名与结构，保持全绿。
-
-用 `todo_write` 跟踪「当前用例 → 红灯 → 绿灯 → 重构」这条链；每个用例走完一轮再进下一个。
-
-## 与其它模式的关系
-
-- 已有一份 `omd-plan` 方案时，按方案里的验收标准逐条写测试（测试即验收标准的可执行化）。
-- TDD 是 `omd-execute` 的一种实现纪律：实现由测试驱动，而不是写完再补测试。
-- 卡住时让 `omd-deep-analyze` 分析「为什么这个测试过不了」，再回来实现。
-
-## 收尾：HUD
-
-用 `omd-hud` 汇报红绿状态：当前用例、测试数（通过/失败）、覆盖到的验收点。让「哪些已验证、哪些还红着」一眼可见。
-
-## 反模式
-
-- 别先写实现再补测试——那是「补测」，不是 TDD。
-- 别跳过红灯直接进入实现：先确认测试真的失败，证明它有效。
-- 别在红灯时重构：先让测试绿，再谈整洁。
+---
+name: omd-tdd
+description: "测试驱动开发：先写会失败的测试，再做最小实现，然后重构（红-绿-重构）。触发词：tdd / 测试驱动 / 先写测试 / red-green / 红绿重构；或想用测试驱动开发时。"
+---
+
+# oh-my-dsh · TDD 测试驱动开发
+
+严格按 **red → green → refactor** 循环驱动实现：先有失败测试，再有最小实现，最后重构。对应 OMC 的 `tdd` 提示词触发模式。
+
+## 何时用
+
+- 用户明确要 TDD、`tdd`、先写测试、红绿重构。
+- 功能有清晰的可验证行为（输入→输出），适合先定测试。
+
+## 循环纪律
+
+1. **Red（红）**：先写一个**会失败**的测试，用它能跑的真实命令（`pwsh`/`bash` 的测试命令，或项目既有测试框架）。
+2. **Green（绿）**：写**最小**实现让测试通过，不做多余设计。
+3. **Refactor（重构）**：测试全绿后再清理重复、改善命名与结构，保持全绿。
+
+用 `todo_write` 跟踪「当前用例 → 红灯 → 绿灯 → 重构」这条链；每个用例走完一轮再进下一个。
+
+## 与其它模式的关系
+
+- 已有一份 `omd-plan` 方案时，按方案里的验收标准逐条写测试（测试即验收标准的可执行化）。
+- TDD 是 `omd-execute` 的一种实现纪律：实现由测试驱动，而不是写完再补测试。
+- 卡住时让 `omd-deep-analyze` 分析「为什么这个测试过不了」，再回来实现。
+
+## 收尾：HUD
+
+用 `omd-hud` 汇报红绿状态：当前用例、测试数（通过/失败）、覆盖到的验收点。让「哪些已验证、哪些还红着」一眼可见。
+
+## 反模式
+
+- 别先写实现再补测试——那是「补测」，不是 TDD。
+- 别跳过红灯直接进入实现：先确认测试真的失败，证明它有效。
+- 别在红灯时重构：先让测试绿，再谈整洁。

package/skills/omd-team/SKILL.md

@@ -1,96 +1,96 @@
----
-name: omd-team
-description: "团队多智能体编排：运行分阶段流水线（team-plan → team-prd → team-exec → team-verify → team-fix 循环），以 DSH workflow 脚本 + 子代理扇出实现。需要团队编排、多智能体流水线或跨子系统特性时使用；触发词：team / 团队 / 多智能体流水线。"
----
-
-# oh-my-dsh · Team 分阶段流水线
-
-把一个大任务拆成五个阶段的流水线，每个阶段由专门的子代理负责，阶段之间像流水线一样传递产物。对应 OMC 的 Team 模式。
-
-## 何时用
-
-- 需求横跨多个子系统（后端 + 前端 + 测试 + 文档）。
-- 用户说"团队""team""多智能体""流水线""pipeline"。
-- 任务有清晰的阶段依赖：先规划，再出规格，再实现，再验证，再修复。
-
-## 五阶段模型
-
-```
-team-plan → team-prd → team-exec → team-verify → team-fix (loop)
-```
-
-| 阶段 | 产出 | 责任人 |
-|------|------|--------|
-| plan | 任务分解：子系统、依赖、验收标准 | 规划代理 |
-| prd | 精确规格：接口、schema、数据流、边界 | 规格代理 |
-| exec | 各子系统的实现 | 多个执行代理（并行） |
-| verify | 测试、评审、与验收标准逐条对照 | 验证代理 |
-| fix | 修复验证发现的缺陷，循环直到全绿 | 修复代理 |
-
-## 用 workflow 工具驱动
-
-`workflow` 是团队流水线的首选载体：一个 JS 脚本编排多个子代理，支持 `pipeline`（无阶段屏障的流水线）和 `parallel`（屏障）。每个阶段用一个子代理，产物用结构化 JSON 在阶段间传递。
-
-```js
-// workflow 脚本骨架（meta 走参数，不是代码）
-const plan = await agent(
-  `你是规划代理。把任务拆成带依赖和验收标准的任务清单。任务：${args.task}`,
-  { label: 'team-plan', phase: 'plan', schema: { type: 'object', properties: {
-    tasks: { type: 'array', items: { type: 'object', properties: {
-      id: { type: 'string' }, title: { type: 'string' },
-      dependsOn: { type: 'array', items: { type: 'string' } },
-      acceptance: { type: 'string' } },
-      required: ['id','title','acceptance'] } } } } }
-);
-
-const prd = await agent(
-  `你是规格代理。基于这份任务清单产出精确实现规格（接口/schema/边界）。\n${JSON.stringify(plan)}`,
-  { label: 'team-prd', phase: 'prd' }
-);
-
-// exec：按依赖并行执行，无屏障
-const results = await pipeline(plan.tasks, async (prev, task) => {
-  return await agent(
-    `你是执行代理。按规格实现任务 #${task.id}「${task.title}」。\n规格：${prd}\n前序产物：${JSON.stringify(prev)}`,
-    { label: `exec-${task.id}`, phase: 'exec' }
-  );
-});
-
-// verify：对照验收标准逐条验证
-const verdict = await agent(
-  `你是验证代理。对照验收标准验证实现，返回每个任务的通过/缺陷清单。\n实现：${JSON.stringify(results)}\n验收标准：${JSON.stringify(plan.tasks)}`,
-  { label: 'team-verify', phase: 'verify' }
-);
-
-// fix loop：只要还有缺陷就继续修，上限 3 轮
-let fixing = verdict;
-for (let round = 0; round < 3 && fixing.openIssues.length; round++) {
-  fixing = await agent(
-    `你是修复代理。修复这些缺陷并重新验证。\n${JSON.stringify(fixing.openIssues)}`,
-    { label: `team-fix-${round}`, phase: 'fix' }
-  );
-}
-
-return { plan, prd, results, final: fixing };
-```
-
-要点：
-
-- `meta` 的 `phases` 声明 `[{title:'plan'},{title:'prd'},{title:'exec'},{title:'verify'},{title:'fix'}]`，进度条按阶段推进。
-- `agent()` 的 `schema` 用「对象根 + type/properties/required/items」约束子代理返回结构化 JSON；不写 `schema` 则拿到纯文本。
-- `pipeline(items, ...stages)` 让每个任务独立流过各阶段、阶段间无屏障；`parallel(thunks)` 用于必须集齐全部结果才能继续的屏障。
-- 脚本里没有文件系统/网络/计时器，只有 `agent`/`pipeline`/`parallel`/`phase`/`log`/`args` —— 所有实际工作由子代理完成，脚本只负责编排。
-
-## 不用 workflow 时（轻量版）
-
-任务不大、阶段不复杂时，直接在主会话里手动走五阶段：用 `subagent` 依次委托 plan → prd → exec（多个 `subagent` 在同一轮并行启动）→ verify → fix，产物在主会话里自己串联。
-
-## 收尾：HUD
-
-每个阶段结束后，按 `omd-hud` 输出一段内联 `dsh-ui` 仪表盘：阶段状态表 + 进度条 + 下一个动作。别等全跑完才汇报。
-
-## 反模式
-
-- 别把 plan 和 prd 合并成一个代理：plan 管"拆什么"，prd 管"怎么做对"。
-- exec 之间如果有依赖，用 `pipeline` 传前序产物，而不是让它们各自重读仓库。
-- fix loop 必须有上限和"全绿"判据，否则无限循环。
+---
+name: omd-team
+description: "团队多智能体编排：运行分阶段流水线（team-plan → team-prd → team-exec → team-verify → team-fix 循环），以 DSH workflow 脚本 + 子代理扇出实现。需要团队编排、多智能体流水线或跨子系统特性时使用；触发词：team / 团队 / 多智能体流水线。"
+---
+
+# oh-my-dsh · Team 分阶段流水线
+
+把一个大任务拆成五个阶段的流水线，每个阶段由专门的子代理负责，阶段之间像流水线一样传递产物。对应 OMC 的 Team 模式。
+
+## 何时用
+
+- 需求横跨多个子系统（后端 + 前端 + 测试 + 文档）。
+- 用户说"团队""team""多智能体""流水线""pipeline"。
+- 任务有清晰的阶段依赖：先规划，再出规格，再实现，再验证，再修复。
+
+## 五阶段模型
+
+```
+team-plan → team-prd → team-exec → team-verify → team-fix (loop)
+```
+
+| 阶段 | 产出 | 责任人 |
+|------|------|--------|
+| plan | 任务分解：子系统、依赖、验收标准 | 规划代理 |
+| prd | 精确规格：接口、schema、数据流、边界 | 规格代理 |
+| exec | 各子系统的实现 | 多个执行代理（并行） |
+| verify | 测试、评审、与验收标准逐条对照 | 验证代理 |
+| fix | 修复验证发现的缺陷，循环直到全绿 | 修复代理 |
+
+## 用 workflow 工具驱动
+
+`workflow` 是团队流水线的首选载体：一个 JS 脚本编排多个子代理，支持 `pipeline`（无阶段屏障的流水线）和 `parallel`（屏障）。每个阶段用一个子代理，产物用结构化 JSON 在阶段间传递。
+
+```js
+// workflow 脚本骨架（meta 走参数，不是代码）
+const plan = await agent(
+  `你是规划代理。把任务拆成带依赖和验收标准的任务清单。任务：${args.task}`,
+  { label: 'team-plan', phase: 'plan', schema: { type: 'object', properties: {
+    tasks: { type: 'array', items: { type: 'object', properties: {
+      id: { type: 'string' }, title: { type: 'string' },
+      dependsOn: { type: 'array', items: { type: 'string' } },
+      acceptance: { type: 'string' } },
+      required: ['id','title','acceptance'] } } } } }
+);
+
+const prd = await agent(
+  `你是规格代理。基于这份任务清单产出精确实现规格（接口/schema/边界）。\n${JSON.stringify(plan)}`,
+  { label: 'team-prd', phase: 'prd' }
+);
+
+// exec：按依赖并行执行，无屏障
+const results = await pipeline(plan.tasks, async (prev, task) => {
+  return await agent(
+    `你是执行代理。按规格实现任务 #${task.id}「${task.title}」。\n规格：${prd}\n前序产物：${JSON.stringify(prev)}`,
+    { label: `exec-${task.id}`, phase: 'exec' }
+  );
+});
+
+// verify：对照验收标准逐条验证
+const verdict = await agent(
+  `你是验证代理。对照验收标准验证实现，返回每个任务的通过/缺陷清单。\n实现：${JSON.stringify(results)}\n验收标准：${JSON.stringify(plan.tasks)}`,
+  { label: 'team-verify', phase: 'verify' }
+);
+
+// fix loop：只要还有缺陷就继续修，上限 3 轮
+let fixing = verdict;
+for (let round = 0; round < 3 && fixing.openIssues.length; round++) {
+  fixing = await agent(
+    `你是修复代理。修复这些缺陷并重新验证。\n${JSON.stringify(fixing.openIssues)}`,
+    { label: `team-fix-${round}`, phase: 'fix' }
+  );
+}
+
+return { plan, prd, results, final: fixing };
+```
+
+要点：
+
+- `meta` 的 `phases` 声明 `[{title:'plan'},{title:'prd'},{title:'exec'},{title:'verify'},{title:'fix'}]`，进度条按阶段推进。
+- `agent()` 的 `schema` 用「对象根 + type/properties/required/items」约束子代理返回结构化 JSON；不写 `schema` 则拿到纯文本。
+- `pipeline(items, ...stages)` 让每个任务独立流过各阶段、阶段间无屏障；`parallel(thunks)` 用于必须集齐全部结果才能继续的屏障。
+- 脚本里没有文件系统/网络/计时器，只有 `agent`/`pipeline`/`parallel`/`phase`/`log`/`args` —— 所有实际工作由子代理完成，脚本只负责编排。
+
+## 不用 workflow 时（轻量版）
+
+任务不大、阶段不复杂时，直接在主会话里手动走五阶段：用 `subagent` 依次委托 plan → prd → exec（多个 `subagent` 在同一轮并行启动）→ verify → fix，产物在主会话里自己串联。
+
+## 收尾：HUD
+
+每个阶段结束后，按 `omd-hud` 输出一段内联 `dsh-ui` 仪表盘：阶段状态表 + 进度条 + 下一个动作。别等全跑完才汇报。
+
+## 反模式
+
+- 别把 plan 和 prd 合并成一个代理：plan 管"拆什么"，prd 管"怎么做对"。
+- exec 之间如果有依赖，用 `pipeline` 传前序产物，而不是让它们各自重读仓库。
+- fix loop 必须有上限和"全绿"判据，否则无限循环。

package/skills/omd-ultragoal/SKILL.md

@@ -1,46 +1,46 @@
----
-name: omd-ultragoal
-description: "持久目标：持久的多目标工作流——把一个大成果拆成多个子目标，各自 checkpoint 到工作区工件，并维护台账让进度跨回合、跨会话存活。触发词：ultragoal / 持久目标 / 多目标 / 长期目标 / 带台账推进。"
----
-
-# oh-my-dsh · Ultragoal 持久多目标
-
-把一个**大结果**拆成多个子目标，逐个推进，每个子目标都写 checkpoint 工件 + 记台账，保证进度**跨轮、跨会话可恢复可审计**。对应 OMC 的 `ultragoal`。
-
-## 何时用
-
-- 目标太大、要跨很多轮、不能一次做完，且要能"接着上次继续"。
-- 用户说"ultragoal""持久目标""多目标""长期目标""带台账""可恢复地推进"。
-
-## 拆解 + checkpoint + 台账
-
-```
-create_goal(总目标) → 拆子目标(各有验收标准) → [实现子目标 → 验证 → 写checkpoint] × N → 全部完成
-```
-
-1. **总目标**：`create_goal` 写总 objective（可验收）。
-2. **拆子目标**：用 `todo_write` 列出子目标，每个子目标一条、带验收标准，可并行的并行推进。
-3. **每个子目标闭环**：实现 → 验证（对照该子目标的验收标准）→ **写 checkpoint 工件**：把进度、证据、产物路径写进工作区文件。
-4. **台账**：维护一个 ledger 文件（如 `ULTRA_GOAL.md`），持续记录「子目标状态 / 完成证据 / 下一步 / 阻塞」，跨轮、跨会话都能据此恢复。
-5. **收尾**：全部子目标完成 + 验证通过 → `update_goal complete`。
-
-## 工件约定
-
-- checkpoint：每个子目标完成后，落一个带验收证据的工件（测试输出、产物文件路径、结论）。
-- ledger：单一事实源，会话恢复后先读它，再继续——别只靠记忆。
-
-## 与其它模式的关系
-
-- `autopilot` = 单领导直推一个目标到底；`ultragoal` = 多子目标 + 显式 checkpoint/台账，强调**持久与可恢复**。
-- 每个子目标内部仍可走 `execute` → `review` → `verify`。
-- 需要"每个完成都必须验证、不许半成品"时，叠加 `ralph` 的强验证纪律。
-
-## 收尾：HUD
-
-用 `omd-hud` 输出：子目标进度表（状态/验收/checkpoint）+ 台账状态。让"哪些子目标完成、哪些还欠证据"可见。
-
-## 反模式
-
-- 别把大目标一次硬做——先拆子目标。
-- 别不写 checkpoint 就指望跨轮恢复——工件是恢复的唯一依据。
-- 别在子目标没验证时就标完成。
+---
+name: omd-ultragoal
+description: "持久目标：持久的多目标工作流——把一个大成果拆成多个子目标，各自 checkpoint 到工作区工件，并维护台账让进度跨回合、跨会话存活。触发词：ultragoal / 持久目标 / 多目标 / 长期目标 / 带台账推进。"
+---
+
+# oh-my-dsh · Ultragoal 持久多目标
+
+把一个**大结果**拆成多个子目标，逐个推进，每个子目标都写 checkpoint 工件 + 记台账，保证进度**跨轮、跨会话可恢复可审计**。对应 OMC 的 `ultragoal`。
+
+## 何时用
+
+- 目标太大、要跨很多轮、不能一次做完，且要能"接着上次继续"。
+- 用户说"ultragoal""持久目标""多目标""长期目标""带台账""可恢复地推进"。
+
+## 拆解 + checkpoint + 台账
+
+```
+create_goal(总目标) → 拆子目标(各有验收标准) → [实现子目标 → 验证 → 写checkpoint] × N → 全部完成
+```
+
+1. **总目标**：`create_goal` 写总 objective（可验收）。
+2. **拆子目标**：用 `todo_write` 列出子目标，每个子目标一条、带验收标准，可并行的并行推进。
+3. **每个子目标闭环**：实现 → 验证（对照该子目标的验收标准）→ **写 checkpoint 工件**：把进度、证据、产物路径写进工作区文件。
+4. **台账**：维护一个 ledger 文件（如 `ULTRA_GOAL.md`），持续记录「子目标状态 / 完成证据 / 下一步 / 阻塞」，跨轮、跨会话都能据此恢复。
+5. **收尾**：全部子目标完成 + 验证通过 → `update_goal complete`。
+
+## 工件约定
+
+- checkpoint：每个子目标完成后，落一个带验收证据的工件（测试输出、产物文件路径、结论）。
+- ledger：单一事实源，会话恢复后先读它，再继续——别只靠记忆。
+
+## 与其它模式的关系
+
+- `autopilot` = 单领导直推一个目标到底；`ultragoal` = 多子目标 + 显式 checkpoint/台账，强调**持久与可恢复**。
+- 每个子目标内部仍可走 `execute` → `review` → `verify`。
+- 需要"每个完成都必须验证、不许半成品"时，叠加 `ralph` 的强验证纪律。
+
+## 收尾：HUD
+
+用 `omd-hud` 输出：子目标进度表（状态/验收/checkpoint）+ 台账状态。让"哪些子目标完成、哪些还欠证据"可见。
+
+## 反模式
+
+- 别把大目标一次硬做——先拆子目标。
+- 别不写 checkpoint 就指望跨轮恢复——工件是恢复的唯一依据。
+- 别在子目标没验证时就标完成。

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 并说明原因。