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-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 的事）。

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

@@ -1,72 +0,0 @@
----
-name: dwy-prd-coarse
-description: 粗粒度产品定义（功能级 PRD）：协作对话敲定产品定位、哲学、目标人群、定价、核心功能详述、非目标，不下到页面级。涉及以下场景使用此 skill（即使没点名 'dwy-prd-coarse'）：用户说『帮我写个 PRD/产品文档』『定义下这个产品』『梳理产品定位和核心功能』『这个产品怎么定价/给谁用』。brainstorming 逐块谈定，产出粗 PRD。区分：本 skill 是功能级总纲（定位/功能/非目标），也是 PRD 的起点——用户笼统说『写个 PRD/产品文档』时默认先从这里（功能级）谈起，定稿后再用 dwy-prd-detailed 下到页面级；只有明确要页面级开发蓝本（元素/文案/状态/输入校验）才直接用 dwy-prd-detailed；完整 0→1 流水线用 dwy-0to1。
----
-
-# dwy-prd-coarse · 粗 PRD
-
-和用户一起敲定**功能级**的产品定义：定位、哲学、人群、定价、核心功能详述。这是后面原型和细 PRD 的总纲——纲领定歪了，后面全白做。颗粒度停在功能层面，**不下到页面级**（页面是细 PRD 的事）。
-
-## 运行模式
-
-上下文自适应，两种调用方式：
-
-- **单独调用（默认）**：用户直接让你写/梳理产品 PRD。从用户描述起步；产物落 `./prd-coarse.md` 或用户指定位置；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑下方「门」即结束。
-- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ 前序产物路径（市场分析）+ 落盘路径（如 `docs/0to1/04-prd-coarse.md`）。**STATE 记账由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
-
-## 输入（定位/定价/功能边界的依据）
-
-定位、定价、差异化、功能边界**不能空想**，要有市场依据 + 技术依据：
-
-- 流水线模式：**必须先 Read 编排器给的市场分析产物**，定位看市场空位、定价对标竞品价、功能边界参考竞品；**再 Read `02-tech-feasibility.md`**（定价受 license/infra 成本约束、核心功能边界受推荐方案能力约束）+ **存在时 Read `03-spike-result.md`**（spike 证伪/受限的能力 → 据此砍功能或写进非目标）。技术上做不到或太贵的，别写进核心功能。
-- 单独模式：有市场分析 / 技术可行性文档就读；没有就先用一两个问题问清目标人群、已知竞品、大致定价区间、核心能力技术上有没有现成方案，别凭空拍脑袋。
-
-## 怎么做（brainstorming 对话法，逐块敲定）
-
-不要一口气甩一份完整 PRD 让用户看。用对话一块一块谈，谈一块定一块，最后才成稿。对话纪律：
-
-- **一次只问一个问题**，优先选择题（A/B/C 带取舍），比开放题好答。
-- 理解清楚后，**提 2-3 个方向带取舍、亮出推荐**那个并说为什么。别替用户默默选，也别什么都「看你」。
-- **分段呈现、逐段确认**：每块（定位 / 哲学 / 人群 / 定价 / 功能）谈完先确认这块对不对，再进下一块。
-- **YAGNI**：用户列的功能里，砍掉不属于核心的，问清是不是 v1 真需要。
-
-按这个顺序逐块敲定（套 `templates/prd-coarse.md` 的章节）：
-
-1. **产品定位** — 一句话说清「给谁、解决什么、凭什么是你」。从市场空位推。
-2. **产品哲学** — 坚持什么、拒绝什么，3-5 条。这是后面所有取舍的判据。
-3. **目标人群** — 具体到能想象出一个真人，别写「所有需要 X 的人」。
-4. **定价策略** — 档位 + 每档含什么 + 对标竞品。**结合竞品价**，不许凭空标价。
-5. **核心功能详述** — 每个功能讲清「是什么、用户拿它干什么、关键规则、边界」。详细到功能层面（输入输出、核心规则、限制），但**不画页面、不定字段长度**。
-6. **非目标** — 明确不做什么，挡住后面无穷的「要不要也加个 X」。
-
-每块谈定后，把结论写进产物对应章节（边谈边落，不要等全谈完才动笔）。
-
-## 产物
-
-落盘粗 PRD（单独默认 `./prd-coarse.md`；流水线按编排器给的路径）。套 `templates/prd-coarse.md`。frontmatter：
-
-```
----
-status: done        # 成稿前 draft，过门后 done
-updated: <date +%Y-%m-%d>
----
-```
-
-成稿要件：六个章节齐全；定位/定价能追溯到市场依据；功能详述到功能级；非目标非空。
-
-## 门（过门确认）
-
-分两层确认：
-
-1. **逐块确认**（对话中已做）：每块谈完即时确认，有异议当场改。
-2. **整体过门**：六块都谈定、产物已落盘且内容完整后（先验证再声称），用 `AskUserQuestion` 把整份粗 PRD 摆给用户：
-   - 摆什么：定位一句话、定价档位、核心功能清单、非目标清单。
-   - 问什么：「粗 PRD 这样定，通过 / 哪块要改 / 换方向？」
-
-## 边界 / 禁止
-
-- **禁止脱离市场依据凭空写**：定位/定价要能追溯到竞品和市场空位。
-- **禁止下到页面级**：不画页面、不定字段长度/行数（那是 dwy-prd-detailed）。停在功能级。
-- **禁止一次甩完整 PRD**：必须 brainstorming 逐块谈、逐块确认。
-- **禁止凭空定价**：每个价格档位都要对标竞品。
-- 这步**不写任何代码**。

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

@@ -1,61 +0,0 @@
----
-status: draft        # draft | done
-updated: <YYYY-MM-DD>
----
-
-# <产品名> · 粗 PRD
-
-> 粗粒度，功能级。定「做什么、给谁、为什么、卖多少钱」，**不下到页面级**（页面级是细 PRD 的事）。每块都和用户分段敲定过、综合了市场分析。
-
-## 产品定位
-
-<一句话说清这是什么、解决谁的什么问题。结合市场分析的市场空位和竞品差异。例：给独立开发者的「单文件部署的轻量监控面板」，主打装起来五分钟、不依赖数据库。>
-
-## 产品哲学
-
-<这产品坚持什么、拒绝什么。3-5 条原则，每条一句。这是后面所有取舍的判据。例：① 默认零配置能跑 ② 数据本地优先 ③ 不做社交/不做会员等级。>
-
-## 目标人群（画像）
-
-<谁会用、什么场景下用、现在用什么替代。具体到能想象出一个真人，别写「所有需要 X 的人」。>
-
-| 维度 | 内容 |
-|---|---|
-| 主画像 | <身份 + 一句话场景> |
-| 次画像 | <可选> |
-| 现在怎么解决 | <替代方案：手动 / 竞品 / 不解决> |
-| 切入的痛点 | <最痛的那一个> |
-
-## 定价策略
-
-<免费 / 一次性买断 / 订阅 / 增值。给出价格档位和每档包含什么。**必须结合市场分析的竞品定价**，说清为什么这么定。>
-
-| 档位 | 价格 | 包含 | 对标竞品 |
-|---|---|---|---|
-| <免费/基础> | <¥> | <功能边界> | <竞品同档> |
-| <进阶> | <¥> | <多了什么> | <竞品同档> |
-
-## 核心功能详述（功能级）
-
-<列核心功能，每个功能讲清「是什么、用户拿它干什么、关键规则」。详细到功能层面——输入输出、核心规则、边界都说清，但**不画页面、不定字段长度**（那是细 PRD）。一次性想全的功能，不在 v1 也先记下，标清优先级。>
-
-### 功能 1：<名称>
-
-- **用户拿它干什么**：<一句话>
-- **核心规则**：<关键逻辑、限制、约束>
-- **优先级**：<v1 必须 / 后续>
-
-### 功能 2：<名称>
-
-- **用户拿它干什么**：
-- **核心规则**：
-- **优先级**：
-
-<按需继续，功能 3、4……>
-
-## 非目标（明确不做什么）
-
-<刻意不做的清单，越明确越好。挡住后面无穷的「要不要也加个 X」。每条一句话，可带一句为什么不做。>
-
-- 不做 <X>：<理由，如 偏离产品哲学第 N 条 / 留给后续版本 / 不是目标人群的需求>
-- 不做 <Y>：

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

@@ -1,76 +0,0 @@
----
-name: dwy-prd-detailed
-description: 页面级细 PRD：对着高保真原型逐页写到能照着写代码——每页元素清单、文案字数上限/行数、每种状态、每个输入的前后端双层长度上限、跳转和边界。涉及以下场景使用此 skill（即使没点名 'dwy-prd-detailed'）：用户说『把 PRD 写细一点/到页面级』『写详细的产品需求文档』『把每个页面的元素和交互列清楚』『定义各字段的校验规则』。区分：本 skill 是页面级开发蓝本（细到元素/字数/状态/校验），前提是功能级总纲已定（最好有高保真原型）；用户只笼统说『写个 PRD/产品文档』、还没有功能级定义时，先用 dwy-prd-coarse 而非本 skill；功能级定位/定价/非目标也用 dwy-prd-coarse；完整 0→1 流水线用 dwy-0to1。
----
-
-# dwy-prd-detailed · 细 PRD（页面级）
-
-对着高保真原型**逐页**写到**页面级**的 PRD。颗粒度要细到开发能照着写代码：每个页面有哪些元素、每条文案的字数上限和行数、每种状态、每个输入的长度上限、每个边界和跳转。这是开发的蓝本，空一处后面就要返工一次。
-
-## 运行模式
-
-上下文自适应，两种调用方式：
-
-- **单独调用（默认）**：用户直接让你写细 PRD。从用户给的原型/页面或描述起步；产物落 `./prd-detailed.md` 或用户指定位置；**不读写 STATE.md、不依赖 `docs/0to1/`**。做完跑下方「门」即结束。
-- **流水线调用**：`dwy-0to1` 调用，指令含「流水线模式」+ 前序产物路径（粗 PRD + 高保真原型目录）+ 落盘路径（如 `docs/0to1/05-prd-detailed.md`）。**STATE 记账由 dwy-0to1 负责，本 skill 不碰 STATE.md**。
-
-## 输入（对着原型逐页写）
-
-- **逐页打开高保真原型的每个 HTML** — 细 PRD 一页对一页地写，原型画了什么就写什么。原型是事实依据，**不对着原型 = 空对空，禁止**。
-- 读粗 PRD（功能规则总纲）。
-- 确认目标端，输入约束按端定（移动端键盘、桌面粘贴等）。
-- 单独模式：用户没给原型就先问清有没有原型/设计稿可对照；实在没有就基于用户描述的页面逐页写，但要提醒「没有原型底稿，状态/极端 case 容易漏」。
-
-## 怎么做（具体步骤）
-
-套 `templates/prd-detailed.md`，**每个页面一节**，每节写全这几块：
-
-1. **页面名 + 用途 + 入口/出口** — 这页让用户干什么、从哪进来、各动作去哪。
-2. **元素 & 区块清单** — 对着原型把每个区块、每个元素列全（顶栏、列表、按钮、计数器…），标清各自规则（如「正文空时发布按钮置灰」）。
-3. **列表项文案约束** — 每条会展示用户内容的地方，定：**字数上限 / 行数 / 溢出处理**（折叠？`…` 截断？展开？）。对着原型里画的超长文本态定。
-4. **各状态** — 空 / 加载中 / 错误 / 无数据 / 无权限 / 超长 / 极端数据，每种写清表现。原型已画全，这里逐一文字化。
-5. **输入校验（长度上限，前后端双层）** — 见下方专节，**这是硬规范**。
-6. **交互 & 跳转** — 点什么去哪、二次确认、成功后路由。动效在这里用文字描述（原型没做动画）。
-7. **边界** — 零结果、网络失败、超长、并发、空输入……每个都写清怎么处理。
-
-## 特别提醒：所有用户输入必须限长（前端 + 后端双层）
-
-dwy 全局规范硬要求——**凡接收用户输入的地方都要限长，前端即时反馈 + 后端防绕过，缺一不可**。细 PRD 里每个输入框 / textarea / 列表 / 分页都要写清：
-
-| 位置 | 必须写明 |
-|---|---|
-| `input` / `textarea` / 富文本 | 字数上限（前端 `maxlength` + schema 兜底防粘贴绕过；后端再校验返回 422） |
-| 列表项展示用户内容 | 字数上限 + 行数 + 溢出处理 |
-| 分页 | `page_size` 默认值 + **上限**（防 DoS） |
-| 文件 / 图片上传 | 数量上限 + 单个大小上限 + **图片额外校验像素尺寸**（防 decompression bomb） |
-| Query / Path / Header | 长度上限 |
-
-按业务语义定数：用户名几十字符、描述几百、正文几千、图片几 MB。**禁止任一字段无上限就过门。**
-
-## 产物
-
-落盘细 PRD（单独默认 `./prd-detailed.md`；流水线按编排器给的路径）。套 `templates/prd-detailed.md`（含一个填好的示例页 + 空白页模板）。frontmatter：
-
-```
----
-status: done
-updated: <date +%Y-%m-%d>
----
-```
-
-成稿要件：原型里每个页面都有对应一节；每页七块齐全；每个输入都有前后端双层长度上限；每页的状态覆盖空/加载/错误/超长。落盘后**逐页核对原型**——原型有的页面 PRD 是否都写了、是否有输入漏写上限，再声称完成（先验证再声称）。
-
-## 门（过门确认）
-
-用 `AskUserQuestion` 把细 PRD 摆给用户：
-- 摆什么：页面清单（与原型对齐）、关键约束（各输入长度上限、各列表折叠规则）、状态覆盖情况。
-- 问什么：「细 PRD 这样定够细吗？通过 / 哪页要补 / 哪个约束要调？」
-
-要改就改，直到用户确认。
-
-## 边界 / 禁止
-
-- **禁止脱离原型空写**——一页对一页，原型是事实依据。
-- **禁止颗粒度停在功能级**——必须到页面级：具体元素、具体字数、具体行数、具体状态。
-- **禁止任一用户输入无长度上限**（前端 + 后端双层），分页无 `page_size` 上限，图片不校验像素——违反 dwy 全局硬规范。
-- **禁止漏状态**——空/加载/错误/超长/极端，每页都要覆盖到。

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 的事。