create-dwy 0.13.1 → 0.13.3

package/templates/claude-global/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-prototype/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: dwy-prototype
+description: 画产品原型（低保真 + 高保真两阶段）：低保真用灰阶可点线框验流程和信息架构；高保真按端套壳、真实内容、画全状态（空/加载/错误/超长），作为细 PRD 底稿。涉及以下场景**必须**使用此 skill（即使没点名 'dwy-prototype'）：用户说『帮我画个原型/线框图』『做个低保真/高保真原型』『把这个页面/流程画出来看看』『做个可点的 mockup』。HTML 产出、浏览器可看。区分：本 skill 画的是验证产品形态的原型（丢弃式/底稿），不是上线代码；要写生产级前端代码用 frontend-design；完整 0→1 流水线用 dwy-0to1。
+---
+
+# dwy-prototype · 产品原型（低保真 + 高保真）
+
+把产品画成能看能点的原型。两个阶段、两个不同目的：
+
+- **低保真**：灰阶可点线框，验**「是不是用户要的流程和信息架构」**——不验视觉，快是第一目标。
+- **高保真**：按端套壳、真实内容、全状态都画出来，①让用户确认视觉和交互细节 ②**作为细 PRD 的底稿**。
+
+## 运行模式
+
+上下文自适应，两种调用方式：
+
+- **单独调用（默认）**：用户直接让你画原型。**先问要哪个阶段**——「低保真验流程，还是高保真做视觉/底稿？」（或两者都要就先低保真再高保真）。从用户描述/已有 PRD 起步；产物落 `./prototype-lowfi/`、`./prototype-hifi/` 或用户指定位置；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑对应阶段的「门」即结束。
+- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ `phase=lowfi|hifi` + 前序产物路径 + 落盘路径。按 `phase` 只做指定阶段（编排器会在低保真、高保真各调一次、各卡一道门）；**STATE 记账由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
+
+## 输入（画什么的依据）
+
+- 流水线模式：读编排器给的粗 PRD 拿核心功能；高保真阶段还要看已验过的低保真原型（在它基础上长出来）和目标端。
+- 单独模式：有 PRD/低保真就读；没有就先问清要画哪些页面/流程、做哪一端。
+
+---
+
+## 阶段一：低保真原型
+
+用最快的方式画出可点的灰阶线框，让用户在浏览器点一遍确认走向对不对。这阶段是丢弃式的，**别在好不好看上浪费一分钟**。
+
+### 怎么做
+
+1. 从核心功能拎出**主流程**（用户从进入到完成核心任务走的那条线）。
+2. 列出这条线上的页面 + 页面间跳转关系。低保真只覆盖主流程，边角页面先不画。
+3. 写**一个 HTML 文件**画出来，规范：
+   - **灰阶**：只用黑白灰，方框 + 边框代表区块。
+   - **真实文案占位**：按钮、标题写真实文字（「发布」「登录」），别用色块代替文字、别 lorem。
+   - **可点跳转**：用锚点 / 简单 JS 切换 div 模拟页面跳转，能点着走完整条流程。
+   - **无颜色、无动画、无样式打磨**：不配色、不做圆角阴影、不写过渡动效。
+   - **丢弃式**：只为这轮验证，过门后不进开发，别当代码维护。
+4. 画完自己在浏览器点一遍，确认整条主流程能走通、没断点，再交给用户。
+
+### 降级（无 GUI 产品 / 单页小工具）
+
+| 产品形态 | 这阶段怎么办 |
+|---|---|
+| CLI 工具 | 降级为**终端会话 mock**：写一段「用户敲什么命令 → 终端回显什么」的示例对话（纯文本/markdown），验证命令设计和输出格式 |
+| 后端 / 库 / SDK | 降级为 **API 契约示例**：列核心接口的请求/响应示例，验证接口形状和调用方式 |
+| 完全无 UI（守护进程等） | 跳过原型（流水线模式标 `skipped(无GUI)`） |
+| 单页小工具 | 低保真和高保真**合并成一轮**，一次画到位 |
+
+降级产物仍落原型目录（如 `cli-session.md` / `api-contract.md`）。
+
+### 产物 + 门
+
+- 路径：`prototype-lowfi/index.html`（单独默认 `./prototype-lowfi/`；流水线按编排器给的路径）。
+- HTML 顶部注释：`<!-- phase: lowfi | status: done | updated: <date +%Y-%m-%d> -->`
+- 落盘后**先自己在浏览器验证能点通**再声称完成（先验证再声称）。
+- 让用户**在浏览器打开点一遍**（给完整文件路径）。用 `AskUserQuestion`：摆主流程页面清单 + 跳转走向，问「流程对不对、是不是想要的信息架构？通过 / 哪步要改 / 流程重排？」要改就**迭代这个 HTML**再让用户看，直到点头。
+
+---
+
+## 阶段二：高保真原型
+
+把低保真验过的流程，做成**像成品一样的高保真原型**。它不是「好看一点的低保真」，是细 PRD 的事实依据——**底稿越具体、越覆盖极端情况，细 PRD 越能细到照着写代码**。
+
+### 怎么做
+
+1. 确定端，**按端套壳**：
+
+   | 端 | 套壳 |
+   |---|---|
+   | iOS | 手机视口（如 390×844）+ iPhone 设备框 |
+   | 安卓 | 手机视口 + 安卓设备框 |
+   | 桌面 | 窗口框（标题栏 + 内容区） |
+   | Web | 响应式，画关键断点（移动 / 桌面至少两套） |
+
+2. 用**真实内容**填充——真实文案、真实数据、真实头像占位图，**不是 lorem**。
+3. **每个页面把全状态都画出来**（这是底稿价值所在，别只画「正常态」）：
+   - 空状态（列表为空、首次进入）
+   - 加载中（骨架屏 / loading）
+   - 错误（网络失败、请求出错）
+   - 超长文本（标题/正文塞到最长，看怎么折叠/截断）
+   - 极端数据（数字很大、列表很多项、零结果）
+4. **仍然不做动画**——动效留到开发期，在细 PRD 里用文字描述（如「点赞后图标放大回弹 200ms」）。
+5. 用 **HTML** 写（AI 生成 + 浏览器直接看最快），可上颜色、上真实视觉风格。
+6. 按页面 / 状态拆多文件，方便逐页对照写细 PRD。
+
+### 产物 + 门
+
+- 路径：`prototype-hifi/`（多文件，如 `home.html`、`home-empty.html`、`publish.html`、`publish-error.html`），建一个 `index.html` 或 `README.md` 做导航。
+- 每个 HTML 顶部注释：`<!-- phase: hifi | page: <页面名> | state: <normal/empty/error...> | updated: <date +%Y-%m-%d> -->`
+- 落盘后**自己在浏览器逐页看一遍**，确认全状态都画了、套壳对、内容真实，再声称完成。
+- 让用户**在浏览器逐页看**（给完整路径和导航）。用 `AskUserQuestion`：摆页面清单 + 每页画了哪些状态 + 套的什么端壳，问「视觉和交互细节确认吗？通过 / 哪页要改 / 哪个状态没覆盖到？」要改就迭代直到确认。
+
+---
+
+## 边界 / 禁止
+
+- **低保真禁止上颜色、做动画、打磨样式、用 lorem 假文、多文件工程化**——只验流程，一个丢弃式 HTML 搞定，快为先。
+- **高保真禁止用 lorem 假数据、禁止只画正常态**——真实内容 + 空/加载/错误/超长/极端全状态，才能当细 PRD 底稿。
+- **两阶段都不做动画**——动效留到开发期，用文字写进细 PRD。
+- **高保真不改流程方向**——流程在低保真已定，要改回低保真重画，别在高保真里偷偷改信息架构。
+- **原型不是上线代码**——验证产品形态用；写生产级前端代码是 frontend-design 的事。

package/templates/claude-global/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-spike/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: dwy-spike
+description: 丢弃式技术验证（spike/POC）：写最简代码只验核心流程跑不跑得通，让用户真机测，只产结论不留代码。涉及以下场景使用此 skill（即使没点名 'dwy-spike'）：用户说『先写个 demo 验证下这个技术行不行』『做个 POC/spike 试试』『这个第三方 API/算法/性能能不能满足』『真机跑跑看能不能通』。代码隔离丢弃，产出实测结论（可行/不可行/换方案）。区分：本 skill 真写代码实测；只做纸面选型对比用 dwy-tech-feasibility；正式 TDD 开发落地用 dwy-tdd-dev；完整 0→1 流水线用 dwy-0to1。
+---
+
+# dwy-spike · 丢弃式技术实测
+
+写一个最简版本只验证核心流程跑不跑得通，让用户真机测。这步**只产结论，不产代码**——spike 是丢弃式 POC，用完即弃。
+
+## 运行模式
+
+上下文自适应，两种调用方式：
+
+- **单独调用（默认）**：用户直接让你验证某技术行不行。从用户描述的技术风险点起步；spike 代码放 `./spike/`、结论落 `./spike-result.md`（或用户指定）；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑下方「门」即结束。
+- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ 前序产物路径（技术可行性）+ 落盘路径（代码 `docs/0to1/spike/`、结论 `docs/0to1/03-spike-result.md`）。**STATE 记账（含 target_platform 记录）由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
+
+## 输入（验什么）
+
+- 单独模式：从用户描述拎出要验的技术风险点；不清楚就问一句「主要担心哪个环节跑不通」。
+- 流水线模式：读编排器给的技术可行性产物，看「是否实测建议」和选定方案，确定要验的风险点。
+
+## 怎么做
+
+1. **先确定做哪一端**（决定 spike 写哪个平台）。用 `AskUserQuestion`：
+
+   > 这个产品主要做哪一端？iOS / 安卓 / 桌面 / Web
+
+   端没定，spike 写哪个平台都是赌。（流水线模式下编排器会把选定的端记进 STATE。）
+
+2. **写最简单的 spike（探针）**：
+   - 只验**核心流程跑不跑得通**——那个技术风险点（新算法能不能算对、第三方 API 行为符不符合预期、性能够不够、硬件能不能集成）。
+   - 砍到不能再砍：一条主链路，没 UI 美化、没边界处理、没配置项、没错误兜底。
+   - 能验证流程就行，**别追求质量、别写测试**。
+
+3. **代码隔离在 spike 目录**（单独 `./spike/`、流水线 `docs/0to1/spike/`）：
+   - 全部 spike 代码只放这个目录，跟正式工程隔开。
+   - 目录里放个 `README` 一行字标清：**这是丢弃式 POC，正式开发不继承这里的代码。**
+
+4. **让用户真机测核心流程**：
+   - 把 spike 跑起来，让用户在**真实环境/真机**上走一遍核心流程。
+   - 收集结果：通了 / 没通 / 哪卡住了 / 性能数字。
+
+## 产物
+
+落盘实测结论（单独默认 `./spike-result.md`；流水线按编排器给的路径）。frontmatter：
+
+```markdown
+---
+status: done
+updated: <date +%Y-%m-%d>
+---
+```
+
+正文**记结论，不是代码**：
+
+| 块 | 内容 |
+|----|------|
+| 验的是什么 | 这次 spike 要验证的核心流程/技术风险点 |
+| 端 | iOS / 安卓 / 桌面 / Web |
+| 实测结论 | 核心流程**通 / 不通**，真机表现、关键性能数字 |
+| 踩了什么 | 实测中暴露的坑、限制、意外行为 |
+| 技术裁决 | **确认可行 / 不可行 / 要换方案**，一句话定性 |
+
+❌ 把 spike 源码贴进结论文档
+✅ 只写「核心流程通了，端到端 1.2s，第三方 API 偶发 429 需退避重试」这类结论
+
+## 门（过门确认）
+
+落盘后先**自己核一遍**（先验证再声称）：结论是「通/不通」的明确定性吗、技术裁决给了吗、没把代码当结论塞进去吧。
+
+然后 `AskUserQuestion` 摆**实测结论**，问：
+
+> 技术验证通过，可以往下走？还是没通过，回去换方案？
+
+## 边界 / 禁止
+
+- **spike 是丢弃式**——只验流程，验完就扔。正式开发（dwy-tdd-dev）**只继承结论、不继承 spike 代码**。
+- **TDD 铁律**：正式开发没有失败测试不写生产代码。spike 代码没测试、没质量，**绝不能**当成开发起点直接往上加。
+- **spike 不写测试、不追求质量**——能跑通核心流程就够，别在这步过度工程。
+- **产物记结论不记代码**——结论文档里写「行/不行/为什么」，源码留在 spike 目录，不进结论文档。
+- 选端是**第一件事**，必须先问再写 spike。

package/templates/claude-global/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-tdd-dev/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: dwy-tdd-dev
+description: 按 TDD 把一个版本/功能落地成代码：写实施计划（bite-size Task）→ 红-绿-重构 → 每个 Task 两阶段审查（spec + code）→ 版本级 code-review 修到全绿 → 完成前验证。涉及以下场景使用此 skill（即使没点名 'dwy-tdd-dev'）：用户说『用 TDD 帮我实现这个』『按测试驱动开发这个功能/版本』『写实施计划再开发』『把这版做出来』。铁律：没失败测试不写生产代码。区分：本 skill 是开发实现；开发完的质量保障流程用 dwy-dev-qa；完整 0→1 流水线用 dwy-0to1。
+---
+
+# dwy-tdd-dev · 逐版本 TDD 开发
+
+把一个版本（或一个功能）落地：写实施计划 → TDD 开发 → 每个 Task 两阶段审查 → 整版本 code-review 修到全绿 → 完成前验证。
+
+> 代码进项目源码，**不进 `docs/0to1/`**；只有实施计划落 `plans/`。
+
+## 运行模式
+
+上下文自适应，两种调用方式：
+
+- **单独调用（默认）**：用户直接让你按 TDD 实现某功能/版本。从用户描述或指定的需求文档起步；实施计划落 `./plans/<slug>.md` 或用户指定位置，代码进项目源码；**不读写 STATE.md、不依赖 `docs/0to1/`**。一个版本走完跑下方「完成前验证」并给交付报告。
+- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ 前序产物路径（版本规划 + 细 PRD）+ 实施计划落盘路径（如 `docs/0to1/plans/vN-<slug>.md`）+ 本次要做哪几个版本。**STATE 的版本进度记账由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
+
+## 输入
+
+- 版本规划：确认要做哪个/哪几个版本、各版本包含什么、验收标准。
+- 细 PRD：页面 / 功能的事实依据，写实施计划时对着它。
+- 技术方案、端：对齐技术栈。
+- 单独模式：用户没给 PRD/版本规划就先问清这次要实现什么、验收标准是什么。
+
+## 总流程（对要做的每个版本循环）
+
+```
+版本 vN：
+  1. 写实施计划 → 落 plans/vN-<slug>.md
+  2. 逐 Task TDD 开发（红-绿-重构）
+     每个 Task 做完 → 两阶段审查（spec → code）→ 有问题回修再审 → 全绿才算这个 Task 完成
+  3. 整版本所有 Task 完 → 版本级 code-review → 修完所有问题（全绿）
+  4. 完成前验证（真跑测试 / 构建，拿到证据）
+  5. 进下一个版本
+全部版本完 → 给用户交付报告
+```
+
+---
+
+## 1. 写实施计划
+
+为当前版本写一份**假设执行者完全不懂这个代码库**的计划：列清每个 Task 动哪些文件、给出实际代码、怎么测、按 TDD 拆成 checkbox 步骤。DRY、YAGNI、TDD、频繁提交。
+
+套 `templates/impl-plan.md`：
+
+- 开头：**Goal**（一句话）/ **Architecture**（2-3 句方案）/ **Tech Stack**（关键技术栈，对齐技术方案）。
+- 再拆**一串 Task**，每个 Task 颗粒度「小到一步只做一个动作（2-5 分钟）」：
+  - `Files:` — 列清 Create / Modify（带行号）/ Test 的**确切路径**。
+  - 5 个 checkbox 步骤，强制 TDD 顺序：
+    1. 写失败测试（贴实际测试代码）
+    2. 运行看到失败（给确切命令 + 预期失败输出）
+    3. 最小实现（贴实际实现代码）
+    4. 运行看到通过（给确切命令 + 预期 PASS）
+    5. commit（优先走 `dwy-git-commit`：敏感扫描 + 规范 message + 禁 AI 署名；该 skill 不在则至少做敏感扫描 + 规范 message，给确切命令）
+
+**禁止占位符**——以下都是计划失败，绝不允许：
+
+- ❌「TODO」「待补充」「类似 Task N」「加适当的错误处理」「为上面写测试」（不给实际代码）
+- ❌ 引用了任何 Task 里都没定义过的类型 / 函数 / 方法
+- ✅ 每个改代码的步骤都贴出完整代码；每个运行步骤都给确切命令 + 预期输出
+
+写完自检：① 版本验收标准每条都能指到某个 Task ② 全文搜一遍上面的占位符红旗 ③ 后面 Task 用的类型 / 方法名和前面定义的一致（Task 3 叫 `clearLayers()`、Task 7 叫 `clearFullLayers()` 就是 bug）。有问题就地改。
+
+落盘 `plans/vN-<slug>.md`，frontmatter：
+
+```
+---
+status: in-progress
+updated: <date +%Y-%m-%d>
+version: vN
+---
+```
+
+## 2. TDD 开发（红-绿-重构铁律）
+
+```
+没有失败测试，不写一行生产代码
+```
+
+每个 Task 按红-绿-重构走，**一步都不能省**：
+
+| 阶段 | 动作 | 强制 |
+|------|------|------|
+| 🔴 RED | 写一个最小失败测试（测真实行为，别测 mock） | — |
+| 🔴 验证 RED | 跑测试，**亲眼看到它失败** | 失败原因必须是「功能没实现」，不是手滑 typo。测试直接过了 = 测错了东西，重写 |
+| 🟢 GREEN | 写**最小**实现让它过（别提前加没要求的功能） | — |
+| 🟢 验证 GREEN | 跑测试，**亲眼看到它通过**，且其它测试不挂、输出干净无 warning | 没看到通过不算过 |
+| 🔵 REFACTOR | 绿了之后才重构：去重、改名、抽 helper，保持全绿 | 重构不加新行为 |
+
+**核心原则**：没亲眼看测试失败，就不知道它测的是不是对的东西。
+
+常见借口都是自欺，一律「删掉，重来」：
+
+- 「先写代码回头补测试」→ 后补的测试一上来就过，证明不了任何东西
+- 「太简单不用测」→ 简单代码也会坏，写个测试 30 秒
+- 「我手动测过了」→ 手动测不成系统、不可复跑、压力下会漏 case
+- 「已经花了 X 小时删了可惜」→ 沉没成本，留着不可信的代码才是技术债
+
+改 bug 同理：**先写一个复现 bug 的失败测试**，再按红-绿修。不写测试不修 bug。
+
+## 3. 每个 Task 两阶段审查
+
+每个 Task 实现完（已 commit），按顺序做两道审查，**顺序不能反**：
+
+### 3.1 spec 审查（先做）— 验「做对了没、有没有多做」
+
+不看实现者的自述，**亲自读实现的代码**，逐条对版本 / Task 要求核对：
+
+- **漏做**：要求的功能都实现了吗？有没有声称实现其实没写的？
+- **多做**：有没有做要求之外的东西？过度设计、塞「顺手加的」功能？
+- **理解偏差**：是不是把需求理解歪了、解错了问题、对的功能用了错的方式？
+
+结论二选一：`✅ spec 通过` / `❌ 发现问题：<逐条列，带 文件:行>`。有问题 → 回修 → **再审一遍**，直到 ✅。
+
+### 3.2 code 质量审查（spec ✅ 后才做）— 验「建得好不好」
+
+对这个 Task 的改动（`git diff BASE..HEAD`）审：
+
+- 职责单一、单元能独立理解和测试、按计划的文件结构落地、本次改动没把文件撑得过大
+- 错误处理、类型安全、DRY 不过度抽象、边界 case
+- 测试测的是真实行为不是 mock、覆盖边界、全绿
+
+### 3.3 审查分级与状态机
+
+审查问题按严重度分级，决定何时修：
+
+| 级别 | 处理 |
+|------|------|
+| **Critical**（bug / 安全 / 数据丢失 / 功能坏） | **立即修** |
+| **Important**（架构问题 / 缺功能 / 错误处理差 / 测试缺口） | **进下一步前修** |
+| **Minor**（代码风格 / 优化点 / 文档润色） | 记下，可later |
+
+实现者报告状态机（控制循环用）：
+
+| 状态 | 含义 → 怎么办 |
+|------|------|
+| `DONE` | 完成 → 进 spec 审查 |
+| `DONE_WITH_CONCERNS` | 完成但有疑虑 → 先读疑虑，涉及正确性 / 范围的先处理再审 |
+| `BLOCKED` | 卡住做不下去 → 补上下文 / 换更强模型 / 拆小 Task / 升级给用户，**别让它原样重试** |
+| `NEEDS_CONTEXT` | 缺信息 → 补齐缺的上下文再继续 |
+
+**两道审查全 ✅、Critical/Important 全修完、且本 Task 已 commit（步骤 5，走 dwy-git-commit），这个 Task 才算完成，进下一个 Task。** commit 是 Task 的硬收尾——别把多个 Task 攒着不提交，漏 commit 等于 Task 没完成。
+
+> **自包含 + 可增强**：上面这套 spec / code 审查逻辑已内嵌，能独立跑。如果检测到项目里有 `/code-review` 命令或 `dwy-dev-qa` skill，Task 级或下面版本级的 code-review 可委托给它们做增强（更全面），没有就用内嵌逻辑。
+
+## 4. 版本级 code-review（修到全绿才进下一版本）
+
+一个版本**所有 Task 做完**后，对整个版本做一次完整 code-review：
+
+```bash
+BASE_SHA=<本版本第一个 commit 之前>
+HEAD_SHA=$(git rev-parse HEAD)
+git diff --stat $BASE_SHA..$HEAD_SHA
+```
+
+审查范围（对整版本 diff）：
+
+- **计划对齐**：实现和实施计划 / 版本验收标准一致吗？偏差是合理改进还是问题？计划的功能都在吗？
+- **代码质量**：职责分离、错误处理、类型安全、DRY 不过度抽象、边界 case
+- **架构**：设计合理、性能可接受、安全、和周边代码集成干净
+- **测试**：测真实行为、覆盖边界、全绿
+- **production**：schema 变更有迁移、向后兼容、文档齐、无明显 bug
+
+输出：Strengths / Issues（Critical / Important / Minor，每条带 文件:行 + 为什么 + 怎么修）/ Assessment。
+
+**按级别修**：Critical + Important **全部修完**，每修一条跑相关测试确认无回归。Minor 记下。
+
+> 项目有 `/code-review` 命令或 `dwy-dev-qa` skill → 委托它做版本级审查（增强）；没有就用上面内嵌逻辑。
+
+**修完所有 Critical / Important（全绿）才进下一个版本。** 还有未修的 Critical/Important 就停在这一版。
+
+## 5. 完成前验证（声称做完前，先拿证据）
+
+```
+没有刚跑出来的验证证据，不许声称「版本做完了」
+```
+
+声称这一版完成 / 进下一版 / 给交付报告**之前**，对照版本验收标准逐条验，**亲自跑命令看输出**：
+
+| 要声称 | 必须有 | 不算数 |
+|------|------|------|
+| 测试通过 | 刚跑的测试命令输出：0 失败 | 「应该过了」「上次跑过」 |
+| 构建通过 | 构建命令 exit 0 | 「lint 过了」「日志看着没问题」 |
+| bug 修了 | 跑原始复现测试：通过 | 「改了代码，估计好了」 |
+| 验收达标 | 逐条核对验收标准 checklist | 「测试过了就算完」 |
+
+红旗——出现就停下先去验证：用了「应该 / 大概 / 似乎」、还没跑命令就说「搞定 / 完美 / 做完了」、准备 commit / 进下一版却没验证、信了 agent 的「成功」自述没自己核对。
+
+**先跑命令 → 读完整输出 → 再下结论。** 不可逆操作（强推等）和声称完成，这条不许精简。
+
+## 产物
+
+- `plans/vN-<slug>.md` — 每个版本一份实施计划。
+- 实际代码 + 测试 — **进项目源码**，频繁 commit。
+
+## 交付报告（全部版本做完）
+
+给用户交付报告：做了哪几个版本、各版本测试 / 构建结果（带证据）、code-review 全绿、代码落在哪、遗留的 Minor 项清单。
+
+> 单版本内部修复用最小回归（仅相关测试）；改了共享工具 / 导出入口 / 基础设施，按影响面扩大到包级全量回归。
+
+## 边界 / 禁止
+
+- **禁止没有失败测试就写生产代码**——红-绿-重构铁律，违反就删掉重来。
+- **禁止跳审查**——spec 和 code 两道都要，且 spec 在前 code 在后，顺序不能反。
+- **禁止带未修的 Critical / Important 进下一个 Task 或下一个版本。**
+- **禁止 Task 未 commit 就开下一个 Task**——红-绿-审查全过后必须当场 commit（走 dwy-git-commit），不许把多个 Task 的改动攒到最后一次性提交。
+- **禁止没跑验证就声称完成**——「应该过了」不算证据，必须有刚跑的命令输出。
+- **禁止实施计划留占位符**（TODO / 待补充 / 类似 Task N）——每步给实际代码 + 确切命令。
+- **禁止把代码写进 `docs/0to1/`**——只有实施计划进 `plans/`，代码进项目源码。
+- **禁止在 main / master 上直接动手**（按项目分支规范走）。

package/templates/claude-global/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-tdd-dev/templates/impl-plan.md

@@ -0,0 +1,115 @@
+---
+status: in-progress    # in-progress | done
+updated: <YYYY-MM-DD>
+version: vN
+---
+
+# <版本名> 实施计划
+
+> 假设执行者完全不懂这个代码库：每个 Task 写清动哪些文件、给出实际代码、确切命令 + 预期输出。DRY、YAGNI、TDD、频繁提交。每步是一个动作（2-5 分钟），用 `- [ ]` checkbox 跟踪。
+
+**Goal**：<一句话，这个版本要建成什么>
+
+**Architecture**：<2-3 句说清方案：模块怎么分、数据怎么流>
+
+**Tech Stack**：<关键技术 / 库，对齐选定的技术方案>
+
+---
+
+## 示例 Task（填好的样板，照这个颗粒度写每个 Task）
+
+### Task 1：笔记正文长度校验（前后端双层）
+
+Files:
+- Create: `src/validators/note.ts`
+- Modify: `src/api/notes.ts:40-58`
+- Test: `tests/validators/note.test.ts`
+
+- [ ] **步骤 1：写失败测试**
+
+```typescript
+import { validateNoteBody } from '@/validators/note'
+
+test('超过 5000 字的正文返回校验错误', () => {
+  const body = 'a'.repeat(5001)
+  const result = validateNoteBody(body)
+  expect(result.ok).toBe(false)
+  expect(result.error).toBe('正文最多 5000 字')
+})
+
+test('5000 字以内的正文通过', () => {
+  const result = validateNoteBody('a'.repeat(5000))
+  expect(result.ok).toBe(true)
+})
+```
+
+- [ ] **步骤 2：运行看到失败**
+
+Run: `pnpm vitest run tests/validators/note.test.ts`
+Expected: FAIL —「validateNoteBody is not a function」（模块还没建）
+
+- [ ] **步骤 3：最小实现**
+
+```typescript
+// src/validators/note.ts
+const MAX_BODY = 5000
+
+export function validateNoteBody(body: string): { ok: boolean; error?: string } {
+  if (body.length > MAX_BODY) {
+    return { ok: false, error: '正文最多 5000 字' }
+  }
+  return { ok: true }
+}
+```
+
+- [ ] **步骤 4：运行看到通过**
+
+Run: `pnpm vitest run tests/validators/note.test.ts`
+Expected: PASS（2 passed），其它测试不受影响
+
+- [ ] **步骤 5：commit（走 `dwy-git-commit`：敏感扫描 + 规范 message + 禁 AI 署名）**
+
+```bash
+git add src/validators/note.ts tests/validators/note.test.ts
+git commit -m "feat: 笔记正文 5000 字长度校验"
+```
+
+---
+
+## 空白 Task 模板（每个真实 Task 复制一份填）
+
+### Task N：<名称>
+
+Files:
+- Create: `<确切路径>`
+- Modify: `<确切路径:起止行>`
+- Test: `<确切测试路径>`
+
+- [ ] **步骤 1：写失败测试**（贴实际测试代码，测真实行为）
+
+```
+<测试代码>
+```
+
+- [ ] **步骤 2：运行看到失败**
+
+Run: `<确切测试命令>`
+Expected: FAIL — <预期失败原因，必须是「功能没实现」>
+
+- [ ] **步骤 3：最小实现**（只写让测试过的最小代码）
+
+```
+<实现代码>
+```
+
+- [ ] **步骤 4：运行看到通过**
+
+Run: `<确切测试命令>`
+Expected: PASS，其它测试不挂、输出无 warning
+
+- [ ] **步骤 5：commit（走 `dwy-git-commit`：敏感扫描 + 规范 message + 禁 AI 署名）**
+
+```bash
+git add <文件>
+git commit -m "<type: 描述>"
+```

package/templates/claude-global/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-tech-feasibility/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: dwy-tech-feasibility
+description: 技术可行性与选型调研：为产品核心能力找 1-3 个成熟开源方案做对比，给推荐 + 是否需要实测建议，绝不手撸已有轮子。涉及以下场景使用此 skill（即使没点名 'dwy-tech-feasibility'）：用户说『这个功能用什么技术实现』『帮我做技术选型/可行性分析』『有没有现成的库做 X』『这个能力技术上可行吗』。WebSearch 找方案 + 四项对比表（能力覆盖/成熟度/适配度/坑）+ 敢下判断的推荐。区分：本 skill 是选型可行性调研（纸面对比）；要真写代码跑通用 dwy-spike；要推荐整套项目技术栈用 dwy-tech-stack；完整 0→1 流水线用 dwy-0to1。
+---
+
+# dwy-tech-feasibility · 技术可行性
+
+找 1-3 个成熟方案实现产品核心能力，**绝不手撸**。选对省半年，选错返工到死。同时判断要不要先写代码实测核心风险。
+
+## 运行模式
+
+上下文自适应，两种调用方式：
+
+- **单独调用（默认）**：用户直接问某能力怎么实现 / 选什么技术。从用户描述的能力起步；产物落 `./tech-feasibility.md` 或用户指定位置；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑下方「门」即结束。
+- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ 前序产物路径（市场分析）+ 落盘路径（如 `docs/0to1/02-tech-feasibility.md`）。按指令读前序、写指定路径；**STATE 记账由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
+
+## 输入（核心能力从哪来）
+
+- 单独模式：从用户描述里拎出要实现的核心能力；不清楚就先问一句产品要做什么。
+- 流水线模式：读编排器给的市场分析产物，拿到**核心能力 / 最大技术风险假设**和**硬约束**（合规/PII/实时性/规模水位）——硬约束直接决定哪些方案能选。
+
+技术调研只围绕**核心能力**转，别给还没定的边角功能选型。
+
+## 怎么做
+
+铁律：**先搜后造**，优先成熟开源方案，禁止手写已有主流方案的功能。
+
+### 一、WebSearch 找方案（1-3 个）
+
+1. 拆出产品的**核心技术能力**（如「实时语音转文字」「PDF 解析」「本地向量检索」），逐个搜主流实现。
+2. 搜的标准（沿用 dwy「优先成熟开源方案」）：
+   - npm / PyPI / GitHub **stars > 1k**
+   - **近期有维护**（近半年有 commit / release）
+   - 社区主流，不是冷门小众
+3. 每个能力列 **1-3 个**候选方案，别只列一个（没对比说不清推荐）。
+
+### 二、目标技术栈没有合适库 → 跨语言参考
+
+目标语言/栈里搜不到合适方案，但**别的语言有成熟库** → 推荐那个库**供参考实现**，讲清两件事：
+- 怎么参考：照它的核心算法/数据结构思路自己实现，还是直接调（子进程 / FFI / 服务化）。
+- 怎么移植：关键逻辑在哪、移植难点是什么。
+
+- ❌ 目标是 Python 但只有 Rust 有成熟库 → 直接说「没方案，自己写」
+- ✅ 「核心算法 Rust 的 `xxx`（stars 8k）最成熟。两条路：① 用 PyO3 包成 Python 扩展直接调；② 照它的 `core/` 算法思路用 Python 重写，难点在 SIMD 那段。推荐 ①，省事且不丢性能。」
+
+### 三、每个方案给四项 + 推荐
+
+每个候选方案列：
+
+| 项 | 说什么 |
+|----|--------|
+| 能力覆盖 | 核心能力它能做到几成，缺什么 |
+| 成熟度 | stars / 维护活跃度 / 生产案例 |
+| 适配度 | 跟产品技术栈、部署形态合不合、**能否满足硬约束**（合规/实时性/规模） |
+| 坑 | 已知限制、license、性能/体积代价 |
+
+最后给 **推荐方案 + 理由**（敢下判断，别全列让用户猜），并说明推荐方案**如何满足硬约束**；若某硬约束无方案可满足，明确标红为风险。
+
+### 四、判断要不要写代码实测
+
+| 判断 | 信号 | 建议 |
+|------|------|------|
+| **建议实测** | 有技术风险/不确定：新算法、硬件集成、性能未知、第三方 API 行为不明、跨语言移植没把握 | 接 dwy-spike 先写丢弃式 POC 验核心流程 |
+| **跳过实测** | 技术成熟无悬念、方案有大量生产案例、就是常规 CRUD/调 API | 直接进开发，不必 spike |
+
+把建议写进产物，给用户拍板。
+
+## 产物
+
+落盘技术可行性文档（单独默认 `./tech-feasibility.md`；流水线按编排器给的路径）。frontmatter：
+
+```markdown
+---
+status: done          # 落盘且过门后才填 done；过门前 awaiting-approval
+updated: <date +%Y-%m-%d>
+---
+```
+
+正文必含：
+
+| 块 | 内容 |
+|----|------|
+| 核心能力清单 | 产品要实现哪几项关键技术能力 |
+| 方案对比表 | 每个能力 1-3 个候选，列 能力覆盖/成熟度/适配度/坑 |
+| 跨语言参考 | 如有：推荐别的语言的库 + 怎么参考/移植 |
+| 推荐方案 | 选哪个 + 理由（敢下判断）+ 如何满足硬约束 |
+| 是否实测建议 | 建议实测（说清验什么风险）/ 跳过（说清为什么无悬念） |
+
+## 门（过门确认）
+
+落盘后先**自己核一遍**（先验证再声称）：每个核心能力都有候选吗、对比表四项填全了吗、推荐有理由吗、实测建议明确吗。
+
+然后 `AskUserQuestion` 摆**方案对比 + 推荐**，问：
+
+> 选哪个方案？要不要先写代码实测核心流程再往下走？
+
+让用户同时定下「技术方案」和「是否实测」两件事。
+
+## 边界 / 禁止
+
+- **绝不手撸已有主流方案**——搜得到成熟库就用/参考，搜不到才自己写，且要在产物里写清「调研了哪些、为何都不用」。
+- **每个核心能力至少给候选，不能空着说「自己实现」**——除非确认无任何开源方案。
+- **推荐必须带理由，不和稀泥**——不「都可以，看你」。
+- **目标栈无库时别直接放弃**——先看跨语言有没有成熟方案可参考/移植。
+- 这步**只调研和选型，不写实现代码**。要验证可行性是 dwy-spike 干的事。