create-dwy 0.14.7 → 0.16.0

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

@@ -1,50 +0,0 @@
----
-name: dwy-publish
-description: "部署应用、发布版本、发布 SDK 的通用发版入口。触发条件：用户说“部署”“发版”“发布”“release”“publish”“bump version”时。先根据仓库上下文判断目标是应用部署还是 SDK 发版，再分别读取对应流程文件执行。"
----
-
-# 发布入口
-
-通用发布 skill。默认进入本 skill 前，测试已经完成。
-
-## 第 0 步：读取仓库发布上下文
-
-执行前先从仓库里定位发布相关信息。
-
-优先查看这些信息源：
-
-- `package.json`、`pyproject.toml`、`Cargo.toml`、`Makefile`、发布脚本
-- `.github/workflows/`、CI 配置、Docker 构建文件
-- `README.md`、发布文档、变更日志
-- 现有 tag 格式、历史 release commit、历史 workflow 运行方式
-
-如果仍然无法判断发布方式或版本来源，停止并要求用户明确，不猜命令。
-
-## 第 1 步：先判断发布类型
-
-先确认：
-
-1. 发布哪个应用或包
-2. 目标是应用部署还是 SDK 发版
-3. 目标版本号是什么；如果用户没给，判断是 `major` / `minor` / `patch`
-
-归类规则：
-
-- **应用部署**：目标是某个服务、站点、容器、镜像、二进制或线上环境
-- **SDK 发版**：目标是 npm、PyPI、私有包仓库或对外库版本
-
-多包场景按仓库已有依赖关系、workspace 拓扑、历史发布顺序执行，不自定顺序。
-
-## 第 2 步：读取对应流程文件
-
-- **应用部署**：读取 `references/application-release.md`
-- **SDK 发版**：读取 `references/sdk-release.md`
-
-不要把两条流程混在一起执行。先判类型，再只读对应流程文件。
-
-## 通用约束
-
-- 禁止在未读清仓库发布上下文时猜发布命令
-- 禁止测试未完成就进入本发布流程
-- 禁止构建失败后继续发布
-- 禁止发布失败后对当前状态含糊表述

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-publish/references/application-release.md

@@ -1,106 +0,0 @@
-# 应用部署流程
-
-适用：发布目标是某个服务、站点、容器、镜像、二进制或线上环境。
-
-## 主流程
-
-流程骨架：
-
-1. `bump`
-2. `CHANGELOG`
-3. `build`
-4. `deploy`
-5. `verify env`
-
-## 1. 判断是否需要 bump
-
-不要一上来改版本号。先判断这次部署是否需要 bump：
-
-- **需要 bump**：带显式版本号的应用发布、镜像 tag 升级、二进制版本升级、对外可见版本变化
-- **可不 bump**：纯重发、仅重跑 workflow、仅补环境配置、仅回滚到已有构建
-- **拿不准**：调用 `dwy-semver` 决定升级位和新版本号
-
-如果需要 bump：
-
-1. 读取当前版本
-2. 算出新版本号
-3. 修改版本文件、镜像 tag 或其他版本来源
-
-不要用会自动 commit 的版本命令。直接编辑版本来源，保持提交边界可控。
-
-## 2. 写 CHANGELOG
-
-判断完 bump 后，再处理 `CHANGELOG`。
-
-- **需要正式版本发布**：必须写
-- **仅部署且无版本变化**：按项目约定决定是否跳过
-
-处理顺序：
-
-1. 找上一个 release tag
-2. 查看 `git log <last-tag>..HEAD --oneline`
-3. 按 `feat` / `fix` / `refactor` / `chore` 分组
-4. 写入 `CHANGELOG.md` 或项目指定的 release notes 文件
-
-如果仓库已有自动生成命令，优先使用；没有再手写。
-
-`CHANGELOG` 未完成，不继续。
-
-## 3. 确认测试已完成并执行 build
-
-本流程不重复跑测试，只确认当前变更已经过项目要求的测试。
-
-然后执行 build，确保发布产物可生成。
-
-构建失败则停止。
-
-## 4. 决定 deploy 入口
-
-不要把 deploy 写死成某种命令。根据仓库上下文自行判断：
-
-- 是推镜像、发二进制、跑部署脚本，还是触发 CI/CD
-- 是 GitHub Actions、其他 CI，还是本地脚本
-- 是否需要先 commit、tag、push 才能触发部署
-
-判断标准示例：
-
-- 存在明确 workflow、触发方式、部署 job，且部署由 CI 完成 → 走 CI
-- 仓库里有明确部署脚本、命令或运维入口 → 走本地部署流程
-
-## 5. 执行 deploy
-
-如果是 CI 驱动：
-
-1. 提交 release 相关文件
-2. 按项目规则创建 tag；如果不是 tag 触发，则按配置触发 workflow
-3. 推送分支和 tag
-4. 观察部署运行状态直到成功或失败
-
-如果是本地驱动：
-
-1. 提交 release 相关文件
-2. 按项目规则创建 tag
-3. 推送分支和 tag
-4. 执行本地部署命令
-
-失败则停止，并给出失败阶段和关键报错。
-
-## 6. verify env
-
-部署完成后，按仓库约定验证环境已生效。可用信号包括：
-
-- 健康检查
-- 版本接口
-- 页面访问
-- 运行日志
-- 镜像 tag
-- 发布平台状态
-- 其他项目约定信号
-
-验证失败，部署不算完成。
-
-## 禁止事项
-
-- 禁止跳过“是否需要 bump”的判断
-- 禁止先部署后补 `CHANGELOG`
-- 禁止把环境验证替换成包仓库验证

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-publish/references/sdk-release.md

@@ -1,93 +0,0 @@
-# SDK 发版流程
-
-适用：发布目标是 npm、PyPI、私有包仓库或对外库版本。
-
-## 主流程
-
-流程骨架：
-
-1. `bump`
-2. `CHANGELOG`
-3. `build`
-4. `publish package`
-5. `verify registry`
-
-## 1. 判断是否需要 bump
-
-SDK 发版默认需要判断版本升级。
-
-- **需要 bump**：正式发布新版本、预发布版本、修复发布产物并重发
-- **拿不准**：调用 `dwy-semver` 决定升级位和新版本号
-
-执行顺序：
-
-1. 读取当前版本
-2. 算出新版本号
-3. 修改版本文件
-
-不要用会自动 commit 的版本命令。直接编辑版本文件。
-
-## 2. 写 CHANGELOG
-
-SDK 发版必须写 `CHANGELOG`。
-
-处理顺序：
-
-1. 找上一个 release tag
-2. 查看 `git log <last-tag>..HEAD --oneline`
-3. 按 `feat` / `fix` / `refactor` / `chore` 分组
-4. 写入 `CHANGELOG.md` 或项目指定的 release notes 文件
-
-如果仓库已有自动生成命令，优先使用；没有再手写。
-
-`CHANGELOG` 未完成，不继续。
-
-## 3. 确认测试已完成并执行 build
-
-本流程不重复跑测试，只确认当前变更已经过项目要求的测试。
-
-然后执行 build，确保包产物可生成。
-
-构建失败则停止。
-
-## 4. 决定 publish 入口
-
-根据仓库上下文判断：
-
-- **CI 发布**：workflow、release job、tag push、workflow_dispatch、release please、cibuildwheel
-- **本地发布**：`pnpm publish`、`uv publish`、`twine upload` 或其他本地发包命令
-
-## 5. 执行 publish package
-
-如果是 CI 驱动：
-
-1. 提交 release 相关文件
-2. 按项目规则创建 tag；如果不是 tag 触发，则按配置触发 workflow
-3. 推送分支和 tag
-4. 观察发布运行状态直到成功或失败
-
-如果是本地驱动：
-
-1. 提交 release 相关文件
-2. 按项目规则创建 tag
-3. 推送分支和 tag
-4. 执行本地发包命令
-
-失败则停止，并给出失败阶段和关键报错。
-
-## 6. verify registry
-
-发布完成后，确认目标仓库中的新版本已可见。验证方式包括：
-
-- npm：`npm view <pkg> version`
-- PyPI：`pip index versions <pkg>` 或项目定义的检查命令
-- 私有仓库：项目约定的版本查询方式
-- GitHub Release：确认 release/tag 已生成
-
-验证失败，发版不算完成。
-
-## 禁止事项
-
-- 禁止跳过版本升级判断
-- 禁止先发包后补 `CHANGELOG`
-- 禁止把包仓库验证替换成环境健康检查

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: 描述>"
-```