create-dwy 0.15.0 → 0.16.1

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

@@ -1,119 +0,0 @@
----
-status: draft        # draft | done
-updated: <YYYY-MM-DD>
----
-
-# <产品名> · 细 PRD（页面级）
-
-> 对着高保真原型逐页写。细到能照着写代码：每个元素、每条文案约束、每种状态、每个输入的长度上限、每个跳转。这是开发的蓝本。
-
-## 页面索引
-
-| # | 页面 | 对应原型文件 | 入口 |
-|---|------|-------------|------|
-| 1 | <页面名> | `prototype-hifi/<file>.html` | <从哪进来> |
-| 2 | | | |
-
-## 全局约定
-
-<跨页面共用的约束，写一次后面引用，别每页重复。例：列表分页 page_size 默认 20、上限 100；所有 toast 文案上限 30 字；时间统一 YYYY-MM-DD HH:mm。>
-
----
-
-## 示例页（填好的样板，照这个颗粒度写每一页）
-
-### 页面 2：发布动态
-
-- **用途**：用户写一条动态并发布。
-- **入口 / 出口**：首页右下「+」进入；发布成功 → 回首页并置顶新动态；取消 → 返回首页不保存。
-
-**元素 & 区块清单**
-
-| 区块 | 元素 | 说明 |
-|---|---|---|
-| 顶栏 | 取消按钮 / 标题「发布」/ 发布按钮 | 正文为空时发布按钮置灰禁用 |
-| 正文区 | 多行 textarea | 占位文案「分享点什么…」 |
-| 图片区 | 缩略图九宫格 + 加号 | 最多 9 张，加号在满 9 张时隐藏 |
-| 字数 | 右下角计数 `0/2000` | 实时更新，超限标红 |
-
-**列表项 / 文案约束**
-
-| 内容 | 上限 | 行数 | 溢出处理 |
-|---|---|---|---|
-| 动态正文（列表态展示） | 2000 字 | 列表最多 6 行 | 超 6 行折叠，尾部「全文」展开 |
-| 图片说明（可选） | 100 字 | 1 行 | 超出 `…` 截断 |
-
-**各状态**
-
-| 状态 | 表现 |
-|---|---|
-| 空 | textarea 显示占位文案，发布按钮置灰 |
-| 加载中（发布请求） | 发布按钮转 loading，禁止重复点 |
-| 成功 | toast「已发布」→ 回首页 |
-| 错误（网络失败） | toast「发布失败，请重试」，正文不清空 |
-| 超长（贴入超 2000 字） | 截断到 2000 + 计数标红 + toast「最多 2000 字」 |
-
-**输入校验（长度上限，前后端双层）**
-
-| 字段 | 前端限制 | 后端校验 | 超限行为 |
-|---|---|---|---|
-| 正文 text | `maxlength=2000` + schema 兜底（防粘贴绕过） | 必填，1–2000 字 | 前端截断+提示；后端拒绝返回 422 |
-| 图片 | 最多 9 张，单张 ≤ 5MB | 数量 ≤ 9，大小 ≤ 5MB，**校验像素尺寸防 decompression bomb** | 超出禁止选择 / 后端拒收 |
-
-**交互 & 跳转**
-
-- 点图片缩略图 → 全屏预览，可左右滑。
-- 点取消且正文非空 → 二次确认「放弃这条动态？」。
-- 发布成功 → 路由回首页，新动态置顶高亮 2 秒。
-
-**边界**
-
-- 正文为空 + 无图：发布按钮禁用。
-- 网络失败：保留草稿在内存，不丢用户已输入内容。
-- 零图片：允许纯文字发布。
-
----
-
-## 空白页模板（每个真实页面复制一份填）
-
-### 页面 N：<页面名>
-
-- **用途**：<这页让用户完成什么>
-- **入口 / 出口**：<从哪进来、各动作去哪>
-
-**元素 & 区块清单**
-
-| 区块 | 元素 | 说明 |
-|---|---|---|
-| | | |
-
-**列表项 / 文案约束**
-
-| 内容 | 上限 | 行数 | 溢出处理 |
-|---|---|---|---|
-| | | | |
-
-**各状态**（每种都要写，没有的标「不适用」）
-
-| 状态 | 表现 |
-|---|---|
-| 空 | |
-| 加载中 | |
-| 成功 | |
-| 错误 | |
-| 无权限 | |
-| 超长 / 极端数据 | |
-
-**输入校验（长度上限，前后端双层）**
-
-| 字段 | 前端限制 | 后端校验 | 超限行为 |
-|---|---|---|---|
-| | | | |
-
-**交互 & 跳转**
-
-- <点 X → 去 Y>
-
-**边界**
-
-- <零结果 / 网络失败 / 超长 / 并发……>

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

@@ -1,104 +0,0 @@
----
-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/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-spike/SKILL.md

@@ -1,81 +0,0 @@
----
-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/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-tdd-dev/SKILL.md

@@ -1,212 +0,0 @@
----
-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（按 Git 提交规范：敏感扫描 + 规范 message + 禁 AI 署名；该规范未生效时至少做敏感扫描 + 规范 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（按 Git 提交规范），这个 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（按 Git 提交规范），不许把多个 Task 的改动攒到最后一次性提交。
-- **禁止没跑验证就声称完成**——「应该过了」不算证据，必须有刚跑的命令输出。
-- **禁止实施计划留占位符**（TODO / 待补充 / 类似 Task N）——每步给实际代码 + 确切命令。
-- **禁止把代码写进 `docs/0to1/`**——只有实施计划进 `plans/`，代码进项目源码。
-- **禁止在 main / master 上直接动手**（按项目分支规范走）。

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

@@ -1,115 +0,0 @@
----
-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（按 Git 提交规范：敏感扫描 + 规范 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（按 Git 提交规范：敏感扫描 + 规范 message + 禁 AI 署名）**
-
-```bash
-git add <文件>
-git commit -m "<type: 描述>"
-```