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-tech-feasibility/SKILL.md

@@ -1,105 +0,0 @@
----
-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 干的事。

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

@@ -1,64 +0,0 @@
----
-name: dwy-version-plan
-description: 产品版本规划：基于细 PRD 把产品切成可交付版本（v1 最小闭环 → v2 → v3…），每版写包含功能、依赖、可验证的验收标准，按价值增量切不按技术层切。涉及以下场景使用此 skill（即使没点名 'dwy-version-plan'）：用户说『帮我规划版本/迭代』『这个产品先做哪些功能、怎么分版本』『切个 v1 最小可用版本』『排个版本路线』。区分：本 skill 切版本+定验收；具体某版本的 TDD 实现用 dwy-tdd-dev；完整 0→1 流水线用 dwy-0to1。
----
-
-# dwy-version-plan · 版本规划
-
-基于细 PRD 把产品切成若干可交付版本：v1 最小可用闭环 → v2 → v3…，每个版本是一个能独立交付的增量。
-
-## 运行模式
-
-上下文自适应，两种调用方式：
-
-- **单独调用（默认）**：用户直接让你规划版本。从用户给的 PRD/功能清单或描述起步；产物落 `./version-plan.md` 或用户指定位置；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑下方「门」即结束。
-- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ 前序产物路径（细 PRD）+ 落盘路径（如 `docs/0to1/06-version-plan.md`）。**STATE 记账（含选定版本、版本进度表）由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
-
-## 输入（切版本的依据）
-
-- **细 PRD 是切版本的唯一依据**：每个版本包含哪些功能，必须能映射回 PRD 的具体页面 / 功能，不能凭空加。
-- 看目标端和产品定位，版本节奏按端和定位定。
-- 单独模式：用户没给细 PRD 就先问清有哪些功能/页面、核心价值是什么，再切。
-
-## 怎么做（具体步骤）
-
-套 `templates/version-plan.md`，按下面思路切：
-
-0. **先勾勒全局数据模型 + 架构骨架（跨版本一次性）** — 切版本前先定核心实体、实体间关系、2-3 句架构方向（分层 / 存储 / 关键边界）。这是所有版本共用的地基，先定好才能避免 v1 把表结构 / 架构画死、v2 被迫 DB 迁移。轻量草图即可，不下到字段类型级（那是 Step9 实施计划的事）。
-1. **找 v1 最小闭环** — 从 PRD 里挑出「能跑通核心价值的最小一条路径」。用户能完整走完一次主流程、拿到核心价值，就是 v1。砍掉一切锦上添花。
-   - ✅ 笔记 App v1 = 新建 / 编辑 / 列表 / 删除，一条闭环
-   - ❌ v1 塞进多端同步、协作、AI 摘要、主题皮肤——这些进 v2+
-2. **后续版本按价值增量切** — v2、v3 每个加一组**能独立交付**的功能。不要按技术层切（「v1 做后端、v2 做前端」是错的，那不是可交付增量）。
-3. **大胆切大版本** — AI 写代码效率高，单版本可以比传统排期装更多。判据是「这一版能不能独立交付、独立验收」，不是「工时够不够一个 sprint」。能合并成一个能交付的闭环就别拆碎。
-4. **写清依赖** — 哪个版本依赖前序版本的产物 / 数据结构。一般 v2 依赖 v1，但要显式写出来依赖的是什么（如「v2 的搜索依赖 v1 已落地的笔记表结构」）。
-5. **每版写验收标准** — 这一版做完，怎么算「真的做完了」。要可验证：列出用户能完成的动作 + 可观测的结果，开发的完成前验证就照这个核对。
-
-每个版本一节，写全：**目标（一句话）/ 包含功能（对应 PRD 哪些页面 / 功能）/ 依赖前序版本 / 验收标准**。
-
-## 产物
-
-落盘版本规划（单独默认 `./version-plan.md`；流水线按编排器给的路径）。套 `templates/version-plan.md`（含版本总览 + 每版本一节 + 一个填好的示例）。frontmatter：
-
-```
----
-status: done
-updated: <date +%Y-%m-%d>
----
-```
-
-成稿要件：全局数据模型 / 架构骨架已勾勒；每个版本的「包含功能」都能映射回细 PRD 的具体页面 / 功能；v1 是最小可用闭环；依赖关系写清；每版有可验证的验收标准。落盘后核对：把版本里列的功能逐条回查细 PRD，确认没有 PRD 里没有的功能、也没把核心闭环拆散到多个版本，再声称完成（先验证再声称）。
-
-## 门（过门确认）
-
-用 `AskUserQuestion` 把版本建议摆给用户：
-- 摆什么：各版本一句话目标 + 包含的主要功能 + 依赖关系（建议方案）。
-- 问什么：「**这次做哪几个版本？（可多选）**」选项给 v1 / v2 / v3… 让用户勾选要一起做的版本，外加「调整切法」。
-
-用户选定后，要改切法就改，直到确认。
-
-## 边界 / 禁止
-
-- **禁止脱离细 PRD 凭空加功能**——版本里每个功能都要能指回 PRD 某页 / 某功能。
-- **禁止按技术层切版本**（后端版 / 前端版）——每个版本必须是能独立交付、独立验收的增量。
-- **禁止把核心闭环拆碎**——v1 必须自己就能跑通核心价值，不能「v1 只有界面没逻辑」。
-- **禁止漏依赖和验收标准**——每版都要写清依赖什么、怎么算做完。

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

@@ -1,72 +0,0 @@
----
-status: draft        # draft | done
-updated: <YYYY-MM-DD>
----
-
-# <产品名> · 版本规划
-
-> 基于细 PRD 把产品切成可交付版本。v1 = 最小可用闭环，往后每版是能独立交付、独立验收的增量。每个版本的功能都要能映射回细 PRD 的具体页面 / 功能。
-
-## 全局数据模型 / 架构骨架
-
-> 跨版本一次性定的地基，避免 v1 把结构画死、v2 被迫迁移。轻量草图，不下到字段类型级。
-
-- **核心实体**：<实体 A、实体 B…，各一句话职责>
-- **实体关系**：<A 1:N B、B M:N C… 关键关系>
-- **架构方向**：<2-3 句：分层 / 存储选型 / 关键边界，如「前端 SPA + REST 后端 + Postgres；鉴权走 JWT；文件走对象存储」>
-
-## 版本总览
-
-| 版本 | 一句话目标 | 依赖 |
-|------|-----------|------|
-| v1 | <最小可用闭环目标> | 无 |
-| v2 | <在 v1 上加的价值增量> | v1 |
-| v3 | <下一个增量> | v2 |
-
----
-
-## 示例（填好的样板，照这个颗粒度写每一版）
-
-### v1：能写能看的笔记闭环
-
-- **目标**：用户能新建、编辑、查看、删除笔记，一条完整可用闭环。
-- **包含功能**（对应细 PRD 页面 / 功能）：
-  - 笔记列表页（PRD 页面 1）：列表展示、空态、下拉刷新
-  - 新建 / 编辑页（PRD 页面 2）：标题 + 正文输入（含前后端长度上限）、保存
-  - 删除（PRD 页面 1 的滑动删除 + 二次确认）
-- **依赖前序版本**：无（首版）。
-- **验收标准**：
-  - [ ] 新建一条笔记 → 列表出现该笔记
-  - [ ] 编辑后 → 列表与详情内容同步更新
-  - [ ] 删除 + 确认 → 列表移除该笔记
-  - [ ] 正文超 5000 字 → 前端截断 + 提示，后端拒绝返回 422
-  - [ ] 全量测试通过、构建 exit 0
-
-### v2：搜索 + 标签
-
-- **目标**：笔记多起来后能快速找到。
-- **包含功能**（对应细 PRD 页面 / 功能）：
-  - 搜索页（PRD 页面 3）：关键词搜索、结果高亮、零结果态
-  - 标签（PRD 页面 2 的标签选择 + 页面 1 的标签筛选）
-- **依赖前序版本**：v1（依赖 v1 已落地的笔记表结构与列表页）。
-- **验收标准**：
-  - [ ] 输入关键词 → 匹配的笔记按相关度返回，命中词高亮
-  - [ ] 无匹配 → 显示零结果态文案
-  - [ ] 给笔记打标签 → 列表可按标签筛选
-  - [ ] 全量测试通过、构建 exit 0
-
----
-
-## 空白版本模板（每个真实版本复制一份填）
-
-### vN：<版本名>
-
-- **目标**：<一句话，这一版让用户能完成什么>
-- **包含功能**（对应细 PRD 页面 / 功能）：
-  - <功能 A>（PRD 页面 X）
-  - <功能 B>（PRD 页面 Y）
-- **依赖前序版本**：<无 / vM，依赖 vM 的什么产物或数据结构>
-- **验收标准**（可验证、对得上「用户能完成的动作 + 可观测结果」）：
-  - [ ] <动作 → 可观测结果>
-  - [ ] <用户输入的长度上限边界 → 预期行为>
-  - [ ] 全量测试通过、构建 exit 0