create-dwy 0.15.0 → 0.16.0

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

@@ -1,25 +1,37 @@
 ---
 name: dwy-stage-launch
-description: "【dwy·立项阶段】产品 0 到 1 的第一阶段编排。触发场景：用户说『走立项流程 / 做立项 / 只想先把立项做完 / 验证这个想法值不值得做 / 想法收敛+竞品+需求验证+POC+MVP 一条龙』，要把模糊想法跑过三道闸门确认值不值得立项时。可独立触发——只想做立项不进后续，就触发我。"
+description: "【dwy·立项阶段】产品 0 到 1 的第一阶段编排。触发场景：用户说『走立项流程 / 做立项 / 只想先把立项做完 / 验证这个想法值不值得做 / 想法收敛+竞品+需求验证+商业分析+POC+MVP 一条龙』，要把模糊想法跑过闸门确认值不值得立项时。可独立触发——只想做立项不进后续，就触发我。"
 ---
 
 ## 职责（单一·编排层）
-按序调度立项阶段的原子 skill，串起三道闸门，不掺产出内容。核心原则：**廉价验证在前、昂贵投入在后**。需求验证是总闸门，过不了不进任何后续重活。
+按序调度立项阶段的原子 skill，串起闸门，不掺产出内容。核心原则：**廉价验证在前、昂贵投入在后**。需求验证是总闸门，过不了不进任何后续重活。
 
 ## 前置校验（开工前读 state）
 - 读 `.dwy/prod/[项目]/state.json`
-- 立项是首阶段，无上游依赖；若 `state.json` 不存在则由本阶段初始化
+- **先检 `schema_version`**：缺失或低于当前版本 → 按 `dwy-product-launcher/references/state-and-contract.md`「schema 版本与迁移」升级 state 再继续
+- 立项是首阶段，无上游依赖；若 `state.json` 不存在则由本阶段初始化（写 `schema_version = "3"`）
 
 ## 编排顺序（带闸门）
-1. **dwy-ideate** — 想法收敛
+1. **dwy-explore** — 想法探索收敛。用 YC forcing questions 逼清楚做什么、值不值，并收敛成结构化想法定义（产出 `想法收敛.md` + `confirmed.idea`，含 `mode` = startup/builder）。想不清楚或明显不值 → 建议停下重想，不硬推；想清楚才进下一步
 2. **dwy-competitor** — 竞品分析
 3. **dwy-validate（闸 1·总闸门）** — 需求验证。**没人要即停整个流程**，不进任何后续
-4. **dwy-poc（闸 2）** — 仅闸 1 过才做。技术可行性验证，**做不出即砍**
-5. **dwy-mvp（闸 3）** — 仅闸 2 过才做。MVP 范围裁剪，**功能 ≤ 7 个**
+4. **dwy-commercial（商业闸门）** — 仅闸 1 过才做。商业模式 + 变现 + 定价 + 单位经济 + GTM 获客 + 可行性结论。**startup 模式下商业不可行即停**；**builder 模式跳过**（不评估、不挡）
+5. **dwy-poc（闸 2）** — 仅商业闸过（或 builder 跳过）才做。技术可行性验证，**做不出即砍**
+6. **dwy-mvp（闸 3）** — 仅闸 2 过才做。MVP 范围裁剪，**功能 ≤ 7 个**
 
-每道闸门未过 → 立即中断本阶段，回写 state 标记停止原因，不静默跳过。
+> 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.poc` / `confirmed.mvp_features` 均写入
-- 用户明确确认立项
-- 回写 `state.json`：`current_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

@@ -8,15 +8,24 @@ description: "【dwy·需求版本阶段】产品 0 到 1 的第二阶段编排
 
 ## 前置校验（开工前读 state）
 - 读 `.dwy/prod/[项目]/state.json`
-- 校验上游完整：`confirmed.mvp_features` 必须存在（立项阶段三闸全过）
-- 缺失 → 报错中断，提示先跑 dwy-stage-launch
+- **先检 `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 范围 + 开发顺序
+- PRD + V1.0 范围 + 开发顺序确认（standard 问用户 / auto 自动判定）
 - `confirmed.prd` / `confirmed.version_plan` / `confirmed.tasks` 均写入
-- 回写 `state.json`：`current_stage = "design"`
+- 回写 `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

@@ -8,14 +8,23 @@ description: "【dwy·上架迭代阶段】产品 0 到 1 的第五阶段编排
 
 ## 前置校验（开工前读 state）
 - 读 `.dwy/prod/[项目]/state.json`
-- 校验上游完整：`confirmed.dev_progress` 必须存在（当前版本全模块测试通过）
-- 缺失 → 报错中断，提示先跑 dwy-stage-dev
+- **先检 `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` 进入下一轮版本编排
+- 回写 `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

@@ -12,11 +12,21 @@ description: "【dwy·任务拆解】产品 0 到 1 需求规划阶段。触发
 
 ## 实现
 [包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
-读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+读其 `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

@@ -9,17 +9,26 @@ description: "【dwy·TDD开发】产品 0 到 1 开发阶段。触发场景：
 ## 输入（从哪读）
 - state.json 的 `confirmed.tasks`、`confirmed.architecture`、`confirmed.dev_progress`
 - `.dwy/prod/[项目]/02-需求规划/开发任务拆解.md`
-- `.dwy/prod/[项目]/03-设计与架构/技术架构.md`、`数据库设计.md`、`接口契约.md`
+- `.dwy/prod/[项目]/04-架构设计/技术架构.md`、`数据库设计.md`、`接口契约.md`
 
 ## 实现
 [包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
-读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+读其 `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 重构。测试通过自动进下一模块。
+每任务循环：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> = todo|done`（逐模块维护）
+- 落到：项目源码目录 + 各任务单元测试 + `.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

@@ -7,12 +7,13 @@ description: "【dwy·需求市场验证】产品 0 到 1 总闸门（闸1）。
 验证需求真实存在 + 有市场，给出 pass/fail 结论。**总闸门**：过不了流程直接停，不进后续。
 
 ## 输入（从哪读）
-- state.json 的 `confirmed.idea`、`confirmed.competitors`
+- 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` 会自动装），不要自己用内置能力顶替。
 

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

@@ -13,6 +13,7 @@ description: "【dwy·版本规划】产品 0 到 1 需求规划阶段。触发
 ## 实现
 [包装型] 用全局本地 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` 会自动装），不要自己用内置能力顶替。
 

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

@@ -1,21 +0,0 @@
----
-name: dwy-ideate
-description: "【dwy·想法收敛】产品 0 到 1 立项第一步。触发场景：用户说『我有个想法 / 帮我把这个点子理清楚 / 想做个 XX / 收敛想法 / 立项 / ideate』，要把模糊念头通过苏格拉底式反问发散+收敛成清晰可执行的产品想法时。"
----
-
-## 职责（单一）
-把用户模糊的初始念头，通过苏格拉底式反问发散+收敛，产出一份清晰的产品想法定义。
-
-## 输入（从哪读）
-- 用户口述的初始想法（首个原子，无上游产出）
-
-## 实现
-[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
-读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
-- 本 skill 依赖的外部 skill：`brainstorming`（对应 `~/.dwy/skills/brainstorming/`）
-- 若 `~/.dwy/skills/brainstorming/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
-
-## 产出契约（硬约束）
-- 落到：`.dwy/prod/[项目]/01-立项/想法收敛.md`
-- 固定章节：核心问题 / 目标用户 / 价值主张 / 关键假设 / 边界与不做什么
-- 回写 state.json：`confirmed.idea`

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-0to1/SKILL.md

@@ -1,113 +0,0 @@
----
-name: dwy-0to1
-description: 端到端「0→1 产品孵化」编排器。用户丢一个产品想法进来，按九步带门流水线**逐步编排调用**同系列单点 skill：dwy-market-analysis（需求/市场）→ dwy-tech-feasibility（技术可行性）→（可选）dwy-spike（真机实测）→ dwy-prd-coarse（粗 PRD）→ dwy-prototype（低保真+高保真原型）→ dwy-prd-detailed（细 PRD）→ dwy-version-plan（版本规划）→ dwy-tdd-dev（逐版本 TDD 开发），每步卡用户确认门、产物落盘 docs/0to1/、用 STATE.md 做唯一真相源支持断点续传。涉及以下场景**必须**使用此 skill（即使用户没点名 'dwy-0to1'）：用户说『我想做个 X』『帮我把这个想法做成产品』『从 0 到 1 做个 XX』『帮我孵化这个想法』，或丢一个产品概念让我判断值不值得做、怎么落地；用户说『继续做 X』『接着上次的产品』『孵化进度到哪了』时读 STATE 续传/汇报。只想单独做其中一步（只画原型、只写 PRD、只做市场分析等），直接用对应的 dwy-* 单点 skill，不必走整条流水线。核心纪律——每步卡门等用户确认才进下一步，绝不跳步、绝不未确认就写代码，所有产物落盘 docs/0to1/ 以支持断点续传。
----
-
-# dwy-0to1（编排器）
-
-把一个产品想法，按九步带门的流水线推到逐版本 TDD 开发落地。本 skill 是**编排器**：自己不实现各步细节，而是按顺序**委托调用**同系列单点 skill，并独占 STATE 真相源、统一卡门、管跨步顺序。每步落盘 `docs/0to1/`，可中断、可断点续传——这次聊到粗 PRD，下次进来从粗 PRD 接着聊。
-
-**核心纪律**：每步有明确产物、卡用户确认门、落盘。门没过不许进下一步，更不许提前写代码。
-
-> 单点能力可独立使用：用户只想画个原型 / 写个 PRD / 做个市场分析，直接用对应的 `dwy-*` skill 即可，不必走整条流水线。本编排器只在「完整 0→1 / 继续上次孵化」时启用。
-
-## 第一件事：读 STATE，决定从哪开始（断点续传）
-
-**每次进入本 skill，先做这步，不要直接开干。**
-
-1. `Glob docs/0to1/STATE.md`（相对当前项目根）。
-2. **存在** → Read 它，看 `current_step` 和「进度」表、「下一步」：
-   - 用 `AskUserQuestion` 跟用户确认：「上次做到 Step N（名称），下一步是 X。从这接着 / 改某步 / 整个重开？」
-   - 按用户选择定位到对应步骤。
-3. **不存在** → 这是新想法：
-   - 先 `Read templates/STATE.md`，在 `docs/0to1/STATE.md` 建初始 STATE（用 `date +%Y-%m-%d` 取今天填 created/updated，current_step=1）。
-   - `docs/0to1/` 目录不存在就先建。
-   - 从 Step 1 开始。
-
-> STATE.md 是整条流水线的**唯一真相源**。任何一步的状态、决策、产物路径都以它为准。它丢了，可以靠各产物文件名（`01-market.md`…编号即步号）+ frontmatter 重建。
-
-## 门规则（每步通用，强制）
-
-每一步都按「**委托 → 过门 → 记账**」走，缺一不可：
-
-1. **委托调用单点 skill**：用 Skill 工具调对应 `dwy-*`，在调用指令里带「**流水线模式**」+ 前序产物路径 + 落盘路径（见路由表）。被调 skill 负责本步的工作、完成前自检（先验证再声称）、并**自己跑领域门**（`AskUserQuestion` 把产物摆给用户问 通过/改/换方向）。
-2. **过门**：被调 skill 的门**用户点头**了，这步才算过。用户要改 → 让 skill 迭代重做再摆，**没点头不进下一步、更不许写生产代码**。
-3. **记账（编排器独占）**：门过了，**编排器立刻更新 `docs/0to1/STATE.md`**——这步状态改 `done`、gate 列填 `✅ <date>`、产物路径、按 `templates/STATE.md`「关键决策」清单填本步定下的决策（Step1 真需求结论/差异化/核心能力/硬约束、Step2 技术方案、Step3 是否实测/端、Step4 定位/定价、Step8 选定版本/全局架构骨架）、`current_step` 指向下一步、写一句「下一步」。被调 skill **不碰 STATE**，记账只由编排器做，这是一次原子 checkpoint。
-
-红线：**绝不跳步、绝不跳门、绝不在用户确认前写生产代码。**
-
-## 九步流水线（路由）
-
-每步：**委托调用下表的 skill（流水线模式，给前序产物路径 + 落盘路径）→ 过门 → 编排器更新 STATE**。
-
-| # | 步骤 | 委托调用 | 流水线 args（前序 → 落盘） | 产物 |
-|---|------|---------|--------------------------|------|
-| 1 | 需求 & 市场分析 | `dwy-market-analysis` | 无前序 → `docs/0to1/01-market.md` | 01-market.md |
-| 2 | 技术可行性 | `dwy-tech-feasibility` | 读 `01-market.md` → `docs/0to1/02-tech-feasibility.md` | 02-tech-feasibility.md |
-| 3 | 实测（可选） | `dwy-spike` | 读 `02-tech-feasibility.md` → 代码 `docs/0to1/spike/`、结论 `docs/0to1/03-spike-result.md` | 03-spike-result.md + spike/ |
-| 4 | 粗 PRD | `dwy-prd-coarse` | 读 `01-market.md` + `02-tech-feasibility.md`（+ 存在时 `03-spike-result.md`） → `docs/0to1/04-prd-coarse.md` | 04-prd-coarse.md |
-| 5 | 低保真原型 | `dwy-prototype`（`phase=lowfi`） | 读 `04-prd-coarse.md` → `docs/0to1/prototype-lowfi/` | prototype-lowfi/index.html |
-| 6 | 高保真原型 | `dwy-prototype`（`phase=hifi`） | 读 `04-prd-coarse.md` + `prototype-lowfi/` → `docs/0to1/prototype-hifi/` | prototype-hifi/ |
-| 7 | 细 PRD | `dwy-prd-detailed` | 读 `04-prd-coarse.md` + `prototype-hifi/` → `docs/0to1/05-prd-detailed.md` | 05-prd-detailed.md |
-| 8 | 版本规划 | `dwy-version-plan` | 读 `05-prd-detailed.md` → `docs/0to1/06-version-plan.md` | 06-version-plan.md |
-| 9 | 逐版本 TDD 开发 | `dwy-tdd-dev` | 读 `06-version-plan.md` + `05-prd-detailed.md` + STATE 选定版本 → 实施计划 `docs/0to1/plans/vN-<slug>.md`，代码进项目源码 | plans/ + 代码 |
-
-**Step 3 分支（编排器据 STATE 决策路由）**：
-- Step 2 过门时记的「是否实测」= **否** → Step 3 不调 `dwy-spike`，进度表标 `skipped(无需实测)`，`current_step` 直接到 4。
-- = **是** → 调 `dwy-spike`；它会先问做哪一端，编排器把答案记进 STATE 的 `target_platform`（Step 5/6/9 都按这个端走）。实测不通过 → `current_step` 回 2 重选方案。
-
-**Step 5/6 同一个 skill 两道门**：`dwy-prototype` 在低保真（`phase=lowfi`）、高保真（`phase=hifi`）各调一次、各卡一道门，目的不同（验流程 vs 做底稿），别合并。
-
-**Step 9 循环**：对 STATE「选定版本」里的每个版本依次调 `dwy-tdd-dev` 走完，编排器更新「版本开发进度」表；全部版本完，Step 9 标 `done`，给交付报告。每版完成的 commit 由 `dwy-tdd-dev` 按 Git 提交规范执行（敏感扫描 + 格式 + 禁 AI 署名），不裸 commit。
-
-## 产物目录（项目内 docs/0to1/）
-
-```
-docs/0to1/
-  STATE.md                    # 断点真相源（编排器独占读写）
-  01-market.md                # Step1 需求/市场/竞品/差异化
-  02-tech-feasibility.md      # Step2 方案对比 + 推荐
-  03-spike-result.md          # Step3 实测结论（不是代码）
-  spike/                      # Step3 丢弃式 POC（仅需实测时）
-  04-prd-coarse.md            # Step4 粗 PRD
-  prototype-lowfi/index.html  # Step5 低保真原型
-  prototype-hifi/             # Step6 高保真原型（按端套壳）
-  05-prd-detailed.md          # Step7 细 PRD（页面级）
-  06-version-plan.md          # Step8 版本规划
-  plans/
-    v1-<slug>.md              # Step9 每版本一份实施计划
-```
-
-各产物文件 frontmatter 由对应 skill 写（`status` / `updated`）；STATE 丢失时靠文件名编号 + frontmatter 重建。
-
-## 关键边界 / 禁止
-
-- **编排器只编排、不实现**：各步的「怎么做」在对应 `dwy-*` skill 里，本文件只管顺序、门、STATE。被调 skill 不碰 STATE，记账只由编排器做。
-- **spike 是丢弃式**（Step 3）：实测代码隔离在 `docs/0to1/spike/`，只为验证核心流程跑不跑得通。开发期（Step 9）**只继承结论，不继承 spike 代码**——TDD 铁律是没失败测试不写生产代码，spike 不算。
-- **两个原型卡不同门**：低保真（Step 5）验流程方向、高保真（Step 6）做细 PRD 底稿，目的不同别合并。**例外**：单页小工具可合并成一轮；CLI / 后端 / 库类**无 GUI** 产品，原型步**优先降级**为「终端会话 mock / API 契约示例」——产出了降级产物就在 STATE 标 `done(降级:无GUI)`；**只有连 mock/契约都没意义时才直接跳过**（标 `skipped(无GUI)`）。详见 `dwy-prototype` 的降级表。
-- **自包含 + 可增强**：本编排器只依赖同系列 `dwy-*` skill，不依赖 gstack / superpowers 插件。Step 9 的 `dwy-tdd-dev` 已内置 spec/code 双审 + 版本级 code-review，等价覆盖 `dwy-dev-qa` 核心；需要更全面的系统级 QA 时才额外委托 `dwy-dev-qa` 或 `/code-review`，避免重复审查。
-- **流水线边界**：交付止于「可运行代码 + 交付报告」。**上线 / 部署 / 市场验证是流水线边界外的人工动作**——Step1「真需求结论」的真正验证靠上线后人工度量。要再迭代就重进本 skill：方向变回 Step 1、产品调整回 Step 4、只加版本回 Step 8。
-- **不跳步、不跳门、不提前写代码**（见「门规则」）。
-
-## 文件结构
-
-```
-.claude/skills/dwy-0to1/
-├── SKILL.md                       ← 本文件（编排骨架 + STATE 协议 + 门规则 + 路由）
-└── templates/
-    └── STATE.md                   ← 状态文件模板（编排器独占）
-```
-
-九步的执行细则与产物模板已拆到同级独立 skill，可单独触发，也被本编排器按路由表委托调用：
-
-```
-开发流程/
-├── dwy-market-analysis/           ← Step1 需求/市场分析
-├── dwy-tech-feasibility/          ← Step2 技术选型可行性
-├── dwy-spike/                     ← Step3 丢弃式实测
-├── dwy-prd-coarse/                ← Step4 粗 PRD（含 templates/prd-coarse.md）
-├── dwy-prototype/                 ← Step5+6 低保真+高保真原型
-├── dwy-prd-detailed/              ← Step7 细 PRD（含 templates/prd-detailed.md）
-├── dwy-version-plan/              ← Step8 版本规划（含 templates/version-plan.md）
-└── dwy-tdd-dev/                   ← Step9 逐版本 TDD 开发（含 templates/impl-plan.md）
-```

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-0to1/templates/STATE.md

@@ -1,56 +0,0 @@
----
-project: <产品名>
-slug: <kebab-slug>
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-current_step: 1
-target_platform: none       # Step3 选定后改: ios | android | desktop | web | none
----
-
-# <产品名> · 0→1 孵化状态
-
-> 本文件是整条流水线的唯一真相源。每过一个门必须更新它。
-
-## 进度
-
-| 步 | 名称 | 状态 | 产物 | gate |
-|---|------|------|------|------|
-| 1 | 需求&市场分析 | pending | 01-market.md | |
-| 2 | 技术可行性 | pending | 02-tech-feasibility.md | |
-| 3 | 实测spike | pending | 03-spike-result.md | |
-| 4 | 粗PRD | pending | 04-prd-coarse.md | |
-| 5 | 低保真原型 | pending | prototype-lowfi/ | |
-| 6 | 高保真原型 | pending | prototype-hifi/ | |
-| 7 | 细PRD | pending | 05-prd-detailed.md | |
-| 8 | 版本规划 | pending | 06-version-plan.md | |
-| 9 | 开发 | pending | plans/ | |
-
-<!-- 状态枚举：pending | in-progress | awaiting-approval | done | skipped(原因) -->
-<!-- gate 列：门过了填 ✅ + 日期（如 ✅ 2026-06-02）；待用户确认填 ⏳ -->
-
-## 关键决策
-
-<!-- 每步定下的、后续步骤要用的决策都记在这里 -->
-- 真需求结论：<Step1，做 / 不做 / 调整方向>
-- 差异化打法：<Step1>
-- 核心能力/最大技术风险：<Step1，最该被 Step2 验证的技术核心>
-- 硬约束：<Step1/2，合规/PII/实时性/规模水位 → 约束选型；无则写 无>
-- 技术方案：<Step2 选定的库/方案>
-- 是否实测：<Step3，是(端=xxx) / 否>
-- 端：<Step3 选定：ios|android|desktop|web|none>
-- 产品定位：<Step4>
-- 定价策略：<Step4>
-- 全局数据模型/架构骨架：<Step8，核心实体+关系+架构方向>
-- 选定版本：<Step8，可多个，如 v1+v2>
-
-## 版本开发进度（Step 9）
-
-| 版本 | 实施计划 | 状态 | code-review |
-|------|---------|------|-------------|
-| v1 | plans/v1-<slug>.md | pending | — |
-
-<!-- 版本状态：pending | in-progress | done。code-review：— / 进行中 / ✅全绿 -->
-
-## 下一步
-
-<一句话写清：从哪步、哪个子项接着干。例：继续 Step4，讨论粗 PRD 的定价策略部分。>

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-dev-qa/SKILL.md

@@ -1,117 +0,0 @@
----
-name: dwy-dev-qa
-description: "功能开发完成后的通用质量保障流程。触发条件：完成新功能、修复 bug、重构代码后，准备提交前。"
----
-
-# 开发完成后质量保障流程
-
-功能开发完成后，按以下 9 步流程逐步执行。**不可跳步，不可调换顺序。**
-
-## 流程总览
-
-```
-功能完成 → 构建验证 → 写测试 → 跑测试 → Code Review → 修复问题 → 性能优化 → 文档同步 → 集成测试 → 输出报告
-```
-
-## 第 1 步：构建验证
-
-确认代码能编译通过，没有语法错误或类型错误。
-
-执行项目的构建命令（查看 `package.json` scripts 或 `Makefile` 确定具体命令）。
-
-**不通过 → 修复编译错误，不进入下一步。**
-
-## 第 2 步：编写测试用例
-
-为本次新增/修改的代码编写测试：
-
-- 新组件/模块：至少覆盖核心功能、关键输入输出
-- 新函数：覆盖正常输入、边界条件、异常输入
-- Bug 修复：先写复现 bug 的测试用例，确认失败，再确认修复后通过
-- 只测新增/修改的部分，不给未改动的代码补测试
-
-## 第 3 步：运行测试
-
-执行项目的测试命令，确认所有测试通过。
-
-**有失败 → 修复代码或测试，不进入下一步。**
-
-## 第 4 步：Code Review
-
-审查本次所有变更（代码 + 测试），检查：
-
-- [ ] 逻辑正确性：边界条件、竞态风险、空值处理
-- [ ] 安全性：XSS、注入、硬编码凭证、敏感数据泄露
-- [ ] 向后兼容：已有 API 是否被破坏（参数重命名/删除、返回值结构变更）
-- [ ] 代码风格：是否符合项目规范
-- [ ] 测试质量：测试是否真正验证了功能
-
-输出 Review 问题清单。
-
-## 第 5 步：修复 Review 问题
-
-逐条修复第 4 步发现的问题。每修一条，跑相关测试确认无回归。
-
-**有未修复的问题 → 不进入下一步。**
-
-## 第 6 步：性能优化
-
-审查本次变更的性能影响：
-
-- [ ] 是否有不必要的重复计算或重复请求
-- [ ] 是否有大数据集缺少分页、虚拟滚动或懒加载
-- [ ] 是否有 N+1 查询或缺少索引
-- [ ] 是否有不必要的深拷贝或大对象序列化
-- [ ] 前端：是否有不必要的重渲染或未做 memo/computed 优化
-
-发现优化点：
-1. 实施优化
-2. 跑测试确认无回归
-3. 如果发现了通用的性能规范不在项目文档中，更新 CLAUDE.md 或 rules
-
-## 第 7 步：文档同步
-
-检查以下文档是否需要更新：
-
-- [ ] **API 文档 / Skills** — 新增或修改了对外接口？更新对应文档
-- [ ] **示例 / Demo** — 新增了用户可感知的功能？补充示例
-- [ ] **项目 CLAUDE.md** — 模块结构、命令、架构发生变化？更新
-- [ ] **导航 / 索引** — 新增了页面或模块？注册到路由和导航
-
-如果项目有专门的文档检查 skill（如 `dwy-docs-check`），调用它自动执行。
-
-## 第 8 步：集成测试
-
-运行全量测试套件 + 构建验证，确认无回归。
-
-**任何失败 → 回到第 5 步修复。**
-
-## 第 9 步：输出报告
-
-向用户输出以下报告，等待审查确认后才能 commit：
-
-```
-## 质量保障报告
-
-### 变更概要
-- 涉及文件：X 个
-- 新增/修改行数：+X / -X
-
-### 测试结果
-- 单元测试：X 通过 / X 失败
-- 集成测试：全量 X 用例通过
-
-### Code Review
-- 发现问题：X 条
-- 已修复：X 条
-- 遗留：0 条
-
-### 性能优化
-- 优化项：（具体优化点，或"无需优化"）
-
-### 文档同步
-- 更新了：（文件列表，或"无需更新"）
-
-### 待用户确认
-- [ ] 确认可以提交
-```

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-market-analysis/SKILL.md

@@ -1,92 +0,0 @@
----
-name: dwy-market-analysis
-description: 需求真伪判断 + 市场/竞品调研 + 差异化建议，给「做不做」结论。涉及以下场景使用此 skill（即使没点名 'dwy-market-analysis'）：用户说『帮我分析下这个需求/想法靠不靠谱』『做个市场分析/竞品调研』『这个方向值不值得做』『帮我看看有没有人做过 X』，或丢一个想法让我判断真伪需求、市场空间、怎么差异化。一次一问的协作对话摸清需求 + WebSearch 拿市场证据，产出市场分析文档。区分：完整 0→1 产品孵化流水线请用 dwy-0to1；只想写代码验证某个技术能不能跑通用 dwy-spike。
----
-
-# dwy-market-analysis · 需求 & 市场分析
-
-跟用户一起把「这是不是真需求」想清楚，再用 WebSearch 扒市场和竞品，给差异化建议和「做不做」结论。伪需求和红海早杀，省掉后面全部白干。
-
-## 运行模式
-
-上下文自适应，两种调用方式：
-
-- **单独调用（默认）**：用户直接丢一个想法让你分析。从用户那句想法起步；产物落用户指定位置，没指定就用 `./market-analysis.md` 或问一句；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑下方「门」即结束，不自动转入别的 skill。
-- **流水线调用**：`dwy-0to1` 通过 Skill 工具调用，指令含「流水线模式」+ 落盘路径（如 `docs/0to1/01-market.md`）。按指令落盘；照常跑「门」；**STATE 记账与进入下一步由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
-
-## 怎么做
-
-两部分：先**协作对话**把需求想清，再叠**市场调研**拿证据。
-
-### 一、协作对话（一次一问，温和把需求摸清）
-
-不是审问，是陪用户把模糊想法捋成清晰需求。纪律：**一条消息只问一个问题**。
-
-1. **探索上下文**：先弄清想法到底是什么、给谁用、解决什么痛点。当前项目有相关文件/代码就先看一眼。
-2. **评估范围，先拆再钻**：想法其实是好几个独立子系统（「做个平台，带聊天 + 存储 + 计费 + 分析」）→ **立刻指出来**，帮用户拆成独立部分，问清谁先做。别急着钻某一块的细节，那等于给一个该拆的项目修地基。
-   - ❌ 用户说「做个带社交的电商平台」→ 直接问「商品详情页要展示哪些字段」
-   - ✅ 先说「这其实是电商 + 社交两个子系统，建议先把电商主链路做通，社交后置。先聚焦电商对吗？」
-3. **一次只问一个问题**（关键纪律）：
-   - 一条消息**只问一个**，别一次甩五个。用 `AskUserQuestion`，**优先做成选择题**（比开放题好答），开放题也行。
-   - 聚焦理解三件事：**目的 / 约束 / 成功标准**。
-   - 一个话题没问透，拆成多条消息分次问，别塞进一条。
-   - ❌ 「目标用户是谁？预算多少？要支持哪些平台？什么时候上线？」（一次四问）
-   - ✅ 「先定目标用户——主要给哪类人用？」（一次一问，等答完再问下一个）
-4. **提 2-3 个差异化方向**：摸清需求后，给 2-3 个不同切入方向，每个带取舍。**亮明推荐哪个、为什么**，别都列出来让用户自己选。
-5. **分段呈现、逐段确认**：把结论拆成几段（需求理解 / 真需求判断 / 差异化建议），一段一段摆，每段问一句「这样对吗」。哪段不对就回去改，别一口气甩完整篇。
-
-### 二、市场 & 竞品调研（WebSearch，对话法没有、这步独有）
-
-对话摸清需求后，拿外部证据验证：
-
-1. **WebSearch 查这个领域**：有哪些现成产品 / 竞品、它们怎么做、市场大概多大、是蓝海还是红海。多关键词搜（中英文都搜，竞品官网 / 测评 / 讨论区）。
-2. **真需求判断**（结合用户回答 + 市场证据）：给三选一结论，**说清依据**——
-   | 结论 | 什么情况 |
-   |------|---------|
-   | 真需求 | 痛点真实、有人在为它付费/费劲找替代，市场有空间 |
-   | 伪需求 | 想当然的「应该有人要」，查不到真实付费意愿或替代行为 |
-   | 需要收窄 | 方向对但太大/太泛，得砍到一个具体人群或场景才成立 |
-3. **差异化建议**：值得做的话，差异化从哪个角度切——功能 / 人群 / 定价 / 体验，挑一两个能立住的，别样样都想赢。
-
-## 产物
-
-落盘市场分析文档（单独模式默认 `./market-analysis.md`；流水线模式按编排器给的路径，如 `docs/0to1/01-market.md`）。顶部 frontmatter：
-
-```markdown
----
-status: done          # 落盘且过门后才填 done；过门前 awaiting-approval
-updated: <date +%Y-%m-%d>
----
-```
-
-正文必含八块：
-
-| 块 | 内容 |
-|----|------|
-| 需求理解 | 想法是什么、给谁用、解决什么痛点（对话捋出来的） |
-| 真需求判断 | 真 / 伪 / 收窄 三选一 + **依据**（用户回答 + 市场证据） |
-| 市场情况 | 领域多大、蓝海还是红海、WebSearch 拿到的关键数据 |
-| 竞品清单 | 表格：谁 / 怎么做 / 优 / 劣 |
-| 差异化建议 | 从哪个角度切（功能/人群/定价/体验），为什么这个角度立得住 |
-| 核心能力/最大技术风险 | 一句话点出最该被技术可行性验证的技术核心（供 dwy-tech-feasibility 锚定调研对象） |
-| 硬约束识别 | 合规 / PII / 实时性 / 规模水位等会反向决定技术选型的硬约束；没有就写「无」 |
-| 做不做建议 | 明确结论 + 一句话理由 |
-
-## 门（过门确认）
-
-落盘后先**自己核一遍**（先验证再声称）：八块齐了吗、真需求判断有依据吗、竞品清单不是空表吗、核心能力/最大技术风险点出来了吗、硬约束识别过了吗（没有也要明写「无」）。核完再声称完成，别说「应该写好了」。
-
-然后 `AskUserQuestion` 把**「做不做 + 怎么差异化」**摆给用户，问：
-
-> 按这个方向继续 / 调整方向 / 放弃？
-
-用户要调整 → 回去改文档重新摆。
-
-## 边界 / 禁止
-
-- **一次只问一个问题**——这是这步的命脉，一条消息甩多问直接破坏对话节奏。
-- **不用对抗式六问诊断**——温和协作，不是审问用户的想法值不值得做。
-- **真需求判断必须带依据**——不能只写「这是真需求」，要有用户回答 + 市场证据支撑。
-- **竞品清单不许是空表**——查不到竞品本身就是信号（要么蓝海要么伪需求），写清是哪种。
-- **做不做建议必须给明确结论**——不和稀泥、不「视情况而定」。该劝退就劝退。
-- 这步**只分析判断，不写任何代码、不碰技术选型**（那是 dwy-tech-feasibility / dwy-spike 的事）。