create-dwy 0.14.7 → 0.16.0

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-release/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: dwy-release
+description: "【dwy·上架迭代】产品 0 到 1 上架迭代阶段（终点）。触发场景：用户说『上架 / 发布上线 / 出上架物料 / 配埋点 / 规划下一版 / release』，要准备上架物料、埋点指标并规划下一版迭代时。"
+---
+
+## 职责（单一）
+产出上架物料 + 埋点指标设计 + 下一版迭代规划。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.acceptance`、`confirmed.prd`、`confirmed.version_plan`
+- `.dwy/prod/[项目]/05-上线交付/验收报告.md`
+- `.dwy/prod/[项目]/02-需求规划/版本路线图.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`release-notes`、`gtm-strategy`、`metrics-dashboard`、`north-star-metric`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/05-上线交付/上架物料.md`、`埋点与指标.md`、`下一版迭代规划.md`
+- 固定章节：
+  - 上架物料.md：发布说明 / GTM 策略 / 渠道文案
+  - 埋点与指标.md：北极星指标 / 埋点清单 / 指标看板设计
+  - 下一版迭代规划.md：数据反馈方向 / 下一版功能候选 / 优先级
+- 回写 state.json：`confirmed.release`（上架物料就绪 + 下一版迭代方向）

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-design/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: dwy-stage-design
+description: "【dwy·设计架构阶段】产品 0 到 1 的第三阶段编排。触发场景：用户说『画原型 + 定架构 / 做设计 / 出原型出架构 / 需求定了开始设计 / 设计和技术架构一起搞』，要把 PRD 先展开成原型、原型定稿后再做技术架构时。可独立触发——需求已定，只想做设计架构，就触发我。"
+---
+
+## 职责（单一·编排层）
+**串行**调度设计架构阶段，不掺产出内容：先原型（内部两轮门控），原型全部确认后才进架构。**架构依赖原型定稿**，原型未定不进架构。
+
+## 前置校验（开工前读 state）
+- 读 `.dwy/prod/[项目]/state.json`
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 上游 `confirmed.prd` / `confirmed.version_plan` 缺失（如单独触发本阶段）→ **不报错**，基于已聊上下文 + 现有产出**轻量补齐**够本阶段用的简版 PRD / 版本范围，写回对应 `confirmed.*` 标注「上下文补齐」。仅当上下文完全不足才提示用户补信息。
+- `run_mode` 缺失 → 默认 `standard`，或按用户当下意图问一次。
+
+## 编排（串行两步）
+1. 调 **dwy-prototype** 走「线框初稿 → 高保真平面图」两轮门控；两轮分别回写 `confirmed.wireframe`、`confirmed.prototype`。
+2. `confirmed.prototype` 写入后，才调 **dwy-architecture** 出技术架构。
+
+子 skill 只向主窗口返回成果摘要，产出落各自文件。
+
+## run_mode 感知
+- `standard`：原型两轮门控照常问用户「线框是否通过 / 高保真是否通过」。
+- `auto`：两轮门控由 AI 自动决策推进、不问用户，仍按「线框定稿 → 高保真 → 架构」顺序串。
+
+## 自动流转（准出后）
+- 回写 `current_stage = "dev"`，按 `run_mode`：`standard` 问「继续 TDD 开发 / 停」、`auto` 直接触发 `dwy-stage-dev`。
+
+## 准出条件（硬约束）
+- 设计与架构**均确认**：`confirmed.prototype` + `confirmed.architecture` 均写入
+- 回写 `state.json`：`current_stage = "dev"`，按 run_mode 流转下一阶段

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-dev/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: dwy-stage-dev
+description: "【dwy·TDD开发阶段】产品 0 到 1 的第四阶段编排。触发场景：用户说『开始开发 / 按 TDD 写代码 / 把 V1.0 开发出来 / 设计定了开始编码 / 多模块并发开发』，要按模块循环用 TDD 把当前版本所有模块做完时。可独立触发——设计架构已定，只想做开发，就触发我。"
+---
+
+## 职责（单一·编排层）
+**任务级 block 分析 + 动态调度**，不掺产出内容。读任务依赖图，无 block 的任务多 Agent 并发、有 block 的串行，逐任务验收推进。
+
+## 前置校验（开工前读 state）
+- 读 `.dwy/prod/[项目]/state.json`
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 上游 `confirmed.prototype` / `confirmed.architecture` / `confirmed.tasks` 缺失（如单独触发本阶段）→ **不报错**，基于已聊上下文 + 现有产出**轻量补齐**够本阶段用的架构/任务拆解结论，写回对应 `confirmed.*` 标注「上下文补齐」。仅当上下文完全不足才提示用户补信息。
+- `run_mode` 缺失 → 默认 `standard`，或按用户当下意图问一次。
+- `auto` 下开发全程自动跑（block 分析 → agent 池 → 逐任务验收 → 覆盖回查）；`standard` 同样自动跑（开发阶段本就无逐模块人工验收），区别仅在准出后是否问「继续上架」。
+
+## 编排（block 分析 → agent 池调度）
+
+### 第一步·block 分析（硬约束，先做）
+调度前**必须先分析每个任务的前后 block 关系**（由任务 Interfaces 推出：`Consumes`=被谁 block、`Produces`=block 谁）。判定铁律：
+- **无 block 的任务 → 多 Agent 并行**
+- **有 block 的任务 → 串行**，被 block 的下游必须等其所有前置 block 任务 done 才能启动
+- 与 `ai-tools/CLAUDE.md`「任务执行前必须先分析 block；无 block 的任务用多 Agent 并行」一致
+
+### 第二步·agent 池调度
+- 按 block 分析结果建 **ready 队列**（所有前置 block 已 done 的任务，即当前无 block 的）
+- 多个子 Agent 并发领取 ready 队列任务，每个 agent 调 **dwy-tdd-dev** 跑单任务 RED→GREEN→REFACTOR
+- 任务 done → 解锁被它 block 的下游 → 下游 block 全清进 ready → 空闲 agent 继续领；任务多时吞吐高
+- **冲突隔离**：改同一批文件的并行任务各自独立 git worktree，完成后按 block 顺序合并；无文件交叠的并行任务无需隔离
+- 落地用 Claude Code 原生 Agent 工具并发派发 + worktree
+
+### 第三步·逐任务验收闭环（防漏需求）
+- 每个任务 done 时，承做 agent 走闭环：**核验**（对照验证标准跑通，未过保持 `todo` 不跳过）→ **标记** `confirmed.dev_progress.<module>.<task> = done` → **记日志**（`09-开发日志.md` 一行：任务/验证结果/关键决策）→ **独立提交**（该任务源码+测试单独 commit，一任务一 commit，并发时各自在 worktree 内提交）
+- worktree 内提交后，编排层按 block 顺序合并各任务分支
+
+### 第四步·合并后全量收口闸（硬约束，编排层独占执行）
+
+并发的根本问题：各 agent 在**自己 worktree、自己领任务那一刻的代码态**下自报「全绿」，但它们并发提交、互相看到的是中间失败态——**单任务绿是必要不充分**，真实准出态只能由「全部分支合并后、在同一棵统一工作树上、一次性跑的全量」定义。所以所有任务分支合并完成后、覆盖回查之前，**必须由编排层自己跑一道收口闸**，不派给任何承做 agent（杜绝「自述全绿」）：
+
+1. **统一工作树**：确认所有任务分支已按 block 顺序合并到主干，在合并后的统一工作树上执行（不在任何子 worktree 内）。
+2. **跑全量**：在合并后代码上**一次性跑全量单测 + 构建打包**（含项目级类型检查——类型错应在 build/打包这条线暴露）。**命令读项目上下文 + 基线自行判定**（前端/后端/全栈各异），不写死具体命令。目标=**消除合并后才暴露的报错，产物可运行**。
+3. **失败 → 编排层修复 + 重跑整闸**：任何失败由编排层走 systematic-debugging 修（典型来源：跨任务共享类型/接口签名变更、共享 fixture、合并冲突遗留），**修完重跑整道闸**（不是只跑挂的那条），循环到**一次性全绿**才算过。此闸是硬闸，`auto` 模式也必须修到绿，不跳过。
+4. **记录**：收口结果记 `09-开发日志.md` 一行（跑了什么、修了什么）。
+
+### 第五步·收尾覆盖回查
+- 收口闸全绿后，对照 `开发任务拆解.md` 任务清单 + PRD 页面/功能逐项点检，确认无遗漏任务、无「标 done 实则未实现」
+- 发现缺口 → 补任务再跑（补完重过第四步收口闸），不直接进 ship
+
+## 自动流转（准出后）
+- 回写 `current_stage = "ship"`，按 `run_mode`：`standard` 问「继续上架迭代 / 停」、`auto` 直接触发 `dwy-stage-ship`。
+
+## 准出条件（硬约束）
+- 当前版本（V1.0）**合并后全量收口闸一次性全绿**（全量单测 + 构建打包通过，非各 agent 自报）+ 覆盖回查无遗漏
+- `confirmed.dev_progress` 全 done（任务级记录 `<module>.<task>`）
+- 回写 `state.json`：`current_stage = "ship"`，按 run_mode 流转下一阶段

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-launch/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: dwy-stage-launch
+description: "【dwy·立项阶段】产品 0 到 1 的第一阶段编排。触发场景：用户说『走立项流程 / 做立项 / 只想先把立项做完 / 验证这个想法值不值得做 / 想法收敛+竞品+需求验证+商业分析+POC+MVP 一条龙』，要把模糊想法跑过闸门确认值不值得立项时。可独立触发——只想做立项不进后续，就触发我。"
+---
+
+## 职责（单一·编排层）
+按序调度立项阶段的原子 skill，串起闸门，不掺产出内容。核心原则：**廉价验证在前、昂贵投入在后**。需求验证是总闸门，过不了不进任何后续重活。
+
+## 前置校验（开工前读 state）
+- 读 `.dwy/prod/[项目]/state.json`
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 立项是首阶段，无上游依赖；若 `state.json` 不存在则由本阶段初始化（写 `schema_version = "3"`）
+
+## 编排顺序（带闸门）
+1. **dwy-explore** — 想法探索收敛。用 YC forcing questions 逼清楚做什么、值不值，并收敛成结构化想法定义（产出 `想法收敛.md` + `confirmed.idea`，含 `mode` = startup/builder）。想不清楚或明显不值 → 建议停下重想，不硬推；想清楚才进下一步
+2. **dwy-competitor** — 竞品分析
+3. **dwy-validate（闸 1·总闸门）** — 需求验证。**没人要即停整个流程**，不进任何后续
+4. **dwy-commercial（商业闸门）** — 仅闸 1 过才做。商业模式 + 变现 + 定价 + 单位经济 + GTM 获客 + 可行性结论。**startup 模式下商业不可行即停**；**builder 模式跳过**（不评估、不挡）
+5. **dwy-poc（闸 2）** — 仅商业闸过（或 builder 跳过）才做。技术可行性验证，**做不出即砍**
+6. **dwy-mvp（闸 3）** — 仅闸 2 过才做。MVP 范围裁剪，**功能 ≤ 7 个**
+
+> dwy-explore 与 dwy-validate 分工：explore 定性逼问给**方向**（做什么、给谁、最窄切入），validate 定量验证给**证据**（搜索量/竞品/访谈），不重复。
+> dwy-commercial 在 validate 之后：先确认「有人真要」，再判断「能跑通商业」。startup 模式 fail 即停；builder 模式（练手/学习）跳过不挡。
+
+每道闸门未过 → 立即中断本阶段，回写 state 标记停止原因，不静默跳过。**硬闸门不受 run_mode 影响**：auto 下闸门未过同样停。商业闸门仅对 startup 模式是硬闸门，builder 模式自动放行。
+
+## run_mode 感知
+- `dwy-explore` 末尾问得的 `run_mode` 决定本阶段内的非闸门门控：`standard` 照常问用户、`auto` 自动决策推进。
+- 闸门（validate/commercial/poc/mvp）是硬约束，两种模式都按结果停或过（commercial 仅 startup 模式硬）。
+
+## 自动流转（准出后）
+- 闸全过 + 立项确认 → 回写 `current_stage = "prd"`，按 `run_mode` 流转：`standard` 问「继续做需求版本 / 停」、`auto` 直接触发 `dwy-stage-prd`。
+
+## 准出条件（硬约束）
+- 闸全过：`confirmed.validation` / `confirmed.commercial` / `confirmed.poc` / `confirmed.mvp_features` 均写入（`commercial` 在 builder 模式为 skipped/pass=true）
+- 立项确认（standard 问用户；auto 自动判定，但闸门未过仍停）
+- 回写 `state.json`：`current_stage = "prd"`，按 run_mode 流转下一阶段

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-prd/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: dwy-stage-prd
+description: "【dwy·需求版本阶段】产品 0 到 1 的第二阶段编排。触发场景：用户说『写 PRD / 出需求文档 / 做需求版本规划 / 拆版本拆任务 / 立项过了开始写需求』，要把已立项的 MVP 展开成 PRD、切版本、排开发顺序时。可独立触发——立项已在别处做完，只想做需求版本，就触发我。"
+---
+
+## 职责（单一·编排层）
+按序调度需求版本阶段的原子 skill，不掺产出内容。把立项结论展开成可开发的需求与版本切分。
+
+## 前置校验（开工前读 state）
+- 读 `.dwy/prod/[项目]/state.json`
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 上游 `confirmed.mvp_features` 缺失（如单独触发本阶段）→ **不报错**，基于已聊上下文 + 现有产出**轻量补齐**一份够用的 MVP 范围，写回 `confirmed.mvp_features` 标注「上下文补齐」。
+- **安全边界**：补的是 MVP 范围，**禁止**凭空标 `confirmed.validation`/`confirmed.poc` 的 `pass=true`——若想做真实立项验证，仍需跑 dwy-stage-launch。
+- `run_mode` 缺失（没跑过 explore）→ 默认 `standard`，或按用户当下意图问一次。
+
+## 编排顺序
+1. **dwy-prd** — 写产品需求文档
+2. **dwy-version** — 版本规划（V1.0 / V1.1 …路线图）
+3. **dwy-tasks** — 任务拆分 + 开发顺序
+
+## run_mode 感知
+- `standard`：PRD / V1.0 范围 / 开发顺序照常问用户确认。
+- `auto`：基于上下文自动决策，不问用户。
+
+## 自动流转（准出后）
+- 回写 `current_stage = "design"`，按 `run_mode`：`standard` 问「继续做设计架构 / 停」、`auto` 直接触发 `dwy-stage-design`。
+
+## 准出条件（硬约束）
+- PRD + V1.0 范围 + 开发顺序确认（standard 问用户 / auto 自动判定）
+- `confirmed.prd` / `confirmed.version_plan` / `confirmed.tasks` 均写入
+- 回写 `state.json`：`current_stage = "design"`，按 run_mode 流转下一阶段

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-stage-ship/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: dwy-stage-ship
+description: "【dwy·上架迭代阶段】产品 0 到 1 的第五阶段编排。触发场景：用户说『验收上线 / 发版上架 / 开始迭代 / 代码写完了走验收发布 / 确定下个版本方向』，要把已开发完的版本走完验收+发布并定迭代方向时。可独立触发——开发已完成，只想做验收上线，就触发我。"
+---
+
+## 职责（单一·编排层）
+按序调度上架迭代阶段的原子 skill，不掺产出内容。验收把关 → 发布上线 → 收口迭代方向。
+
+## 前置校验（开工前读 state）
+- 读 `.dwy/prod/[项目]/state.json`
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 上游 `confirmed.dev_progress` 缺失（如单独触发本阶段）→ **不报错**，基于已聊上下文 + 现有源码/产出**轻量补齐**够本阶段用的开发完成结论，写回 `confirmed.dev_progress` 标注「上下文补齐」。仅当上下文完全不足才提示用户补信息。
+- `run_mode` 缺失 → 默认 `standard`，或按用户当下意图问一次。
+
+## 编排顺序
+1. **dwy-acceptance** — 验收（对照 PRD 与验收标准把关）
+2. **dwy-release** — 发布上线
+
+## run_mode 感知
+- `standard`：验收结论、迭代方向照常问用户。
+- `auto`：验收自动判定；但**发布上线是高风险不可逆操作 → 仍停下让用户确认**（auto 不绕高风险不可逆动作），确认后再 release。
+
+## 自动流转（准出后）
+- 当前版本标记完成。若有下一版本，回写 `current_stage = "prd"` 进入下一轮版本编排：`standard` 问「继续做下一版 / 停」、`auto` 直接触发 `dwy-stage-prd`（下一版本无高风险闸门时连跑）。
+- 无下一版本 → 流程正常结束（ship 是末阶段）。
+
+## 准出条件（硬约束）
+- 上线完成（release 前的高风险确认两种模式都做）+ 下一版迭代方向已定
+- `confirmed.acceptance` / `confirmed.release` 均写入
+- 回写 `state.json`：当前版本标记完成；若有下一版本，`current_stage` 复位到 `prd`，按 run_mode 流转

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-tasks/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: dwy-tasks
+description: "【dwy·任务拆解】产品 0 到 1 需求规划阶段。触发场景：用户说『拆任务 / 拆解开发任务 / 排开发计划 / 写实施计划 / tasks』，要把 V1.0 版本范围拆成可执行的开发任务清单时。"
+---
+
+## 职责（单一）
+把 V1.0 版本范围拆成可执行、可验证的开发任务清单。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.version_plan`、`confirmed.prd`
+- `.dwy/prod/[项目]/02-需求规划/版本路线图.md`、`PRD.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方法论产出，落到下方「产出契约」。
+- **AI 自主拆解**：架构阶段文档（`技术架构.md`/`数据库设计.md`/`接口契约.md` + `PRD.md`/`版本路线图.md`）已建好，AI 据此**自行判断**模块怎么切、方案怎么选，按 writing-plans 方法论直接产出，不再逐点弹 `AskUserQuestion` 找用户拍板。仅当文档间出现**实质冲突或硬缺口**（无法据现有文档推断）时才向用户确认。
+- 本 skill 依赖的外部 skill：`writing-plans`（对应 `~/.dwy/skills/writing-plans/`）
+- 若 `~/.dwy/skills/writing-plans/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/02-需求规划/开发任务拆解.md`
+- 固定章节：
+  - **模块划分**：按业务域/Features 内聚分模块
+  - **任务清单（拆到 TDD 步）**：每个任务带
+    - `Files`：精确文件路径（Create / Modify / Test）
+    - `Interfaces`：`Consumes`（用前序任务的精确签名）+ `Produces`（后续任务依赖的函数名/参数/返回类型）——任务依赖图的数据来源
+    - `Steps`：2-5 分钟一步的 RED→GREEN→REFACTOR（写失败测试 → 跑挂 → 最小实现 → 跑过 → commit），每步含**真实内容**
+    - 一个**可独立测试的交付物** + 验证标准（精确命令 + 期望输出）
+    - **No Placeholders**：禁 TBD / 「加校验」「处理边界」这类空泛，禁引用任何任务都没定义的类型/函数
+  - **任务依赖图**：由各任务 Interfaces 的 Consumes/Produces 推出（到任务级，不只模块级）
+- 任务粒度 = 「能带自己测试周期、值得新 reviewer 独立卡验收的最小单元」；setup/配置/脚手架折叠进它服务的任务，不单列
+- 回写 state.json：`confirmed.tasks`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-tdd-dev/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: dwy-tdd-dev
+description: "【dwy·TDD开发】产品 0 到 1 开发阶段。触发场景：用户说『开始开发 / 写代码 / TDD 开发 / 按任务开发 / 实现功能 / tdd』，要按模块循环 RED→GREEN→REFACTOR 开发并自动推进时。单元测试归此阶段。"
+---
+
+## 职责（单一）
+按模块循环 RED→GREEN→REFACTOR 开发，测试通过自动进下一模块（无人工逐模块验收）。单元测试归此阶段。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.tasks`、`confirmed.architecture`、`confirmed.dev_progress`
+- `.dwy/prod/[项目]/02-需求规划/开发任务拆解.md`
+- `.dwy/prod/[项目]/04-架构设计/技术架构.md`、`数据库设计.md`、`接口契约.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方法论产出，落到下方「产出契约」。
+- **AI 自主开发**：架构阶段文档（`技术架构.md`/`数据库设计.md`/`接口契约.md`）+ `开发任务拆解.md` 已建好，AI 据此**自行**按模块循环 RED→GREEN→REFACTOR，测试通过自动进下一模块，不再逐点弹 `AskUserQuestion` 找用户拍板。仅当文档间出现**实质冲突或硬缺口**（无法据现有文档推断）时才向用户确认。
+- 本 skill 依赖的外部 skill：`test-driven-development`、`systematic-debugging`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+每任务循环：RED 写失败测试 → GREEN 最小实现通过 → REFACTOR 重构。
+
+**逐任务验收闭环（一任务一闭环，按序执行）**：每个任务 done 时——
+1. **核验**：对照该任务在拆解时定的验证标准（精确命令 + 期望输出）跑通过；未过保持 `todo`，不得跳过
+2. **标记**：`confirmed.dev_progress.<module>.<task> = done`
+3. **记录**：`09-开发日志.md` 记一行（任务 / 验证结果 / 关键决策）
+4. **独立提交**：该任务的源码 + 测试**单独 commit**（一任务一 commit，不攒一坨），message 带任务标识；多 agent 并发时各自在自己 worktree 内提交
+
+**逐任务绿 = 必要不充分**：本闭环跑的是「该任务、在自己 worktree、领任务那一刻代码态」下的测试，并发时各 agent 互相看到的是中间失败态。它**不替代**合并后的全量收口——真实准出态只能由「全部分支合并后、统一工作树、一次性跑的全量单测 + 构建打包」定义，那道**合并后全量收口闸由编排层 `dwy-stage-dev` 独占执行**（见其第四步），承做 agent 不自行下「全量已绿」结论。
+
+## 产出契约（硬约束）
+- 落到：项目源码目录 + 各任务单元测试 + `.dwy/prod/[项目]/09-开发日志.md`
+- 固定章节（开发日志）：任务进度 / 验证结果 / 关键决策 / 遇到的问题与解法
+- 回写 state.json：`confirmed.dev_progress.<module>.<task> = todo|done`（逐任务维护）

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-validate/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: dwy-validate
+description: "【dwy·需求市场验证】产品 0 到 1 总闸门（闸1）。触发场景：用户说『验证需求 / 这需求是真的吗 / 有没有市场 / 需求验证 / 市场验证 / validate』，要在投入开发前确认需求真实存在且有市场时。这是总闸门，过不了流程直接停。"
+---
+
+## 职责（单一）
+验证需求真实存在 + 有市场，给出 pass/fail 结论。**总闸门**：过不了流程直接停，不进后续。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.idea`（含 explore 已定性逼出的 core_problem、key_assumptions——本 skill 把它变成定量验证）、`confirmed.competitors`
+- `.dwy/prod/[项目]/01-立项/想法收敛.md`、`竞品分析.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`market-sizing`、`sentiment-analysis`、`interview-script`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+验证方式三选一：
+- 搜索量/竞品热度（AI 自动）
+- 落地页测点击
+- 5 个目标用户访谈
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/需求市场验证.md`
+- 固定章节：验证方式 / 证据数据 / 市场判断 / **pass/fail 结论（含理由）**
+- 回写 state.json：`confirmed.validation`（含 `pass` 布尔字段）
+- **fail 时流程必须中断，不进闸2**

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-version/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: dwy-version
+description: "【dwy·版本规划】产品 0 到 1 需求规划阶段。触发场景：用户说『版本规划 / 排版本 / 版本路线图 / V1 做啥 V2 做啥 / roadmap』，要把 PRD 需求按版本切片排路线图时。准出复查 V1.0 范围不膨胀。"
+---
+
+## 职责（单一）
+把 PRD 需求按版本切片，排出版本路线图。准出复查 V1.0 范围没膨胀。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.prd`、`confirmed.mvp_features`
+- `.dwy/prod/[项目]/02-需求规划/PRD.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`outcome-roadmap`、`prioritize-features`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/02-需求规划/版本路线图.md`
+- 固定章节：版本切片（V1.0/V1.x/V2.0…）/ 各版本目标 / V1.0 范围准出复查
+- **V1.0 范围超出 MVP 清单直接告警，强制收敛**
+- 回写 state.json：`confirmed.version_plan`