create-dwy 0.14.7 → 0.16.0

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-acceptance/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: dwy-acceptance
+description: "【dwy·验收测试】产品 0 到 1 上架迭代阶段。触发场景：用户说『验收 / 验收测试 / 跑集成测试 / E2E 测试 / 上线前测试 / acceptance』，要在上架前做集成/E2E/兼容/合规验收并查文档与代码实际差距时。不重复单元测试。"
+---
+
+## 职责（单一）
+集成/E2E/兼容/合规/沙盒验收 + 文档 vs 代码实际差距分析。**不重复单元测试**（单测归 dwy-tdd-dev）。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.dev_progress`、`confirmed.prd`、`confirmed.architecture`
+- 项目源码 + `.dwy/prod/[项目]/02-需求规划/PRD.md`
+- `.dwy/prod/[项目]/04-架构设计/接口契约.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`test-scenarios`、`intended-vs-implemented`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/05-上线交付/验收报告.md`
+- 固定章节：集成/E2E 场景结果 / 兼容性 / 合规与沙盒 / 文档vs代码差距 / 验收结论
+- 回写 state.json：`confirmed.acceptance`（验收结论 / 是否达上线标准）

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-architecture/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: dwy-architecture
+description: "【dwy·技术架构】产品 0 到 1 设计与架构阶段。触发场景：用户说『设计架构 / 出技术方案 / 设计库表 / 定接口契约 / 技术架构 / architecture』，要在开发前定下技术架构、数据库设计和接口契约时。按四层架构（Assembly/Features/BizFoundation/Foundation）+ 统一选型（Python+FastAPI、Vue+Vite）产出。"
+---
+
+## 职责（单一）
+按项目 rules + 下方架构约束，产出技术架构 + 数据库库表设计 + 接口契约。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.prd`、`confirmed.tasks`、`confirmed.prototype`
+- `.dwy/prod/[项目]/02-需求规划/PRD.md`、`开发任务拆解.md`
+- 项目 `.claude/rules/` 下的技术栈与编码规则
+
+## 架构约束（硬）
+
+项目已有 `.claude/rules/` 时**以项目 rules 为准**；项目无明确规定时按本节统一缺省。
+
+### 技术选型（缺省基线，写在架构选项之上）
+
+以下为默认选型基线，**先按此基线落地**；结合上下文（PRD / 选型 / 项目 rules）判断**基线不合适时，必须用 `AskUserQuestion` 跟用户确认后才换**，禁止默默偏离基线、也禁止默默换栈。
+
+- **后端统一 Python + FastAPI**（异步、Pydantic v2、SQLAlchemy 2.0 风格，与 `dwyeapi` 生态对齐）
+  - **Python 虚拟环境用 `uv` 管理**（venv + 依赖 + 运行）
+  - **DB 迁移用 Alembic**（与 SQLAlchemy 2.0 配套）
+  - **配置 / settings 用 pydantic-settings**（与 `dwyeapi` config 对齐）
+  - **认证用 JWT**（与 `dwyeapi` security 的 create_token/decode_token + bcrypt 对齐）
+- **后端有数据库时**：
+  - **关系型数据库用 PostgreSQL**（连接串如 `postgresql+asyncpg://user:pass@localhost:5432/mydb`）
+  - **内存数据库 / 缓存用 Redis**（`redis://localhost:6379/0`）
+  - **用 Docker 部署**（后端 + Postgres + Redis 编排到 `docker-compose.yml`）
+  - **反向代理 / 入口网关用 Nginx**
+- **前端 Vue 用 Vite + TailwindCSS + TypeScript**（`@dwydev/eui` + `@dwydev/ekit` 可选用，不强制）
+  - **包管理器用 pnpm**（与本 monorepo 一致）
+  - **状态管理用 Pinia**
+  - **HTTP 客户端用 axios**（或 `@dwydev/ekit` 的 request）
+  - **E2E 测试用 Playwright**（单测 Vitest 为项目默认）
+- **CI/CD 走 GitHub Actions + OIDC**（发布鉴权用 OIDC，禁长期静态凭据）
+- **基线不适用就先确认**：任一项基线与上下文冲突（如纯前端无需 Docker/DB、要换其他 DB/MQ/中间件、不能用某项）→ 先 `AskUserQuestion` 跟用户确认，确认后在架构文档写明偏离基线的理由
+
+### 四层架构（依赖严格单向向下：Assembly → Features → BizFoundation → Foundation）
+
+| 层 | 职责 | 后端示例 | 前端示例 |
+|---|---|---|---|
+| **装配层 (Assembly)** | 实例化 / 依赖注入 / 路由挂载 / 生命周期，**零业务逻辑** | `src/app/`（main.py 装 Provider/Hook、factories） | `apps/web`（路由、stores、main.ts） |
+| **Features (业务功能层)** | 各业务域领域逻辑，域内 router+service+schema+model **聚在同一目录** | `<域>/`（如 `factor/`、`plan/`、`quota/`） | `features/*`（如 auth、settings） |
+| **业务基础层 (BizFoundation)** | 业务相关但跨业务域复用：鉴权、领域协议/Provider、领域设施 | `auth`、各包 `protocols.py`/`providers` | 跨域复用的业务 composable/store |
+| **业务无关层 (Foundation)** | 与业务完全无关的 kernel | `shared`（DB/Redis/签名/中间件） | `core`（httpClient/格式化/常量） |
+
+### 三条铁律
+- **依赖单向向下，绝不反向**：下层禁止 import 上层；Foundation 禁止 import 任何业务包；跨业务域**不直接互 import**，靠装配层用 Protocol/Hook 桥接。
+- **业务内聚**：一个业务域 = 一个目录，域内 router/service/schema/model 聚在一起。✅ `factor/`（含 router+service+validators）；❌ 顶层 `routers/`+`services/`+`models/` 三个大锅各塞所有域。
+- **装配层是唯一能 import 具体实现的地方**：业务代码只通过 `get_xxx_provider()` 取实例，换实现不改业务代码。
+
+## 实现
+[自写型]
+1. 读项目 `.claude/rules/`，结合上方架构约束产出架构（项目 rules 优先，本约束兜底）
+2. 技术架构：**先按四层归位模块、按业务域聚目录**，再写分层/模块边界/选型理由；选型不确定处走 `AskUserQuestion`
+3. **判有无后端**（读选型/PRD：有 API / 持久化 / 账户体系 → 有后端）：
+   - **有后端** → 必出数据库设计，且**建模到位**：库表清单 / 字段(类型·约束·默认·可空) / 主外键关系 / 索引 / 必要的范式或反范式说明，与接口契约 schema 对齐
+   - **纯前端**（无后端）→ 跳过数据库设计，在 `技术架构.md` 注明「无后端，不涉及库表」
+4. 接口契约：路由、请求/响应 schema（遵循项目响应格式约定）
+5. **走 rules + 约束土建**，不引入约束外的技术栈
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/04-架构设计/技术架构.md`、`接口契约.md`，**有后端时**加 `数据库设计.md`
+- 固定章节：
+  - 技术架构.md：**四层划分 + 各业务域目录结构** / 模块边界 / 技术选型（按缺省基线写明 Python+FastAPI+uv+Alembic+pydantic-settings+JWT、前端 Vue+Vite+TS+Tailwind+pnpm+Pinia+axios+Playwright、CI/CD GitHub Actions OIDC；有 DB 写明 PostgreSQL+Redis+Docker+Nginx；偏离基线处写明原因）/ 选型不明或偏离基线处的 AskUserQuestion 确认记录 / 有无后端结论
+  - 数据库设计.md（**有后端必出**）：库表清单 / 字段定义(类型·约束·默认·可空) / 主外键关系与索引 / 与接口契约对齐
+  - 接口契约.md：接口清单 / 请求响应 schema / 错误码
+- 回写 state.json：`confirmed.architecture`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-commercial/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: dwy-commercial
+description: "【dwy·商业分析】产品 0 到 1 立项阶段（闸1 之后）。触发场景：用户说『商业分析 / 商业模式 / 怎么赚钱 / 变现 / 定价 / 单位经济 / CAC/LTV / GTM 获客 / 商业可行性 / commercial』，要在需求验证后判断商业模式跑不跑得通、能不能赚钱时。startup（创业/产品）模式下是硬闸门：商业不可行即停流程；builder（练手/学习）模式跳过不挡流程。"
+---
+
+## 职责（单一）
+盘商业模式 + 变现路径 + 定价 + 单位经济 + GTM 获客，给商业可行性 **pass/fail** 结论。**startup 模式硬闸门**：过不了流程停，不进闸 2（POC）。**builder 模式跳过**：读 `confirmed.idea.mode`，builder 直接回 skipped、不挡流程、不产出。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.idea`（含 `mode` = startup/builder、`target_user`、`narrowest_wedge`、`value_prop`、`key_assumptions`——变现与定价对着这个人和这点切入定）
+- state.json 的 `confirmed.competitors`（竞品定价、现有变现方式对着它定差异化）
+- `.dwy/prod/[项目]/01-立项/想法收敛.md`、`竞品分析.md`、`需求市场验证.md`
+
+## 模式分流（开工第一步）
+读 `confirmed.idea.mode`：
+- **builder**（练手 / 学习 / 开源 / hackathon / 纯兴趣）→ 不逼商业，回写 `confirmed.commercial = { mode: "builder", pass: true, skipped: true, reason: "builder 模式不评估商业可行性" }`，不产出文件、不挡流程，直接放行进闸 2
+- **startup**（奔着有人用、可能收钱、要做成产品）→ 走下面完整商业分析
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill（各对应 `~/.dwy/skills/<名>/`）：
+  - `startup-canvas` — 整体盘点（战略 9 节 + 商业模式 2 节），作为引子框架，先跑它把商业全貌摸一遍
+  - `business-model` — 商业模式画布 9 模块（详细展开成本结构 / 收入流）
+  - `monetization-strategy` — 3-5 个变现方案（含 CAC/LTV/回本/毛利单位经济 + 低成本验证实验）
+  - `pricing-strategy` — 定价模型选型 + 分层 + 价值计量 + 价格敏感度
+  - `porters-five-forces` — 赛道竞争结构（补「赛道」维度，判断利润空间是否被结构压扁）
+  - `gtm-strategy` — 首批用户从哪来、渠道、获客成本估算、90 天路线
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+### 推荐跑法（顺序，可按上下文跳）
+1. `startup-canvas` 先出整体画布（摸商业全貌 + 战略一致性）
+2. `monetization-strategy` 出 3-5 个变现方案 + 各自单位经济 → 用户选 1-2 个主攻
+3. `pricing-strategy` 对选定方案细化定价
+4. `porters-five-forces` 判赛道结构是否压扁利润（利润空间 → 可行性）
+5. `gtm-strategy` 出首批获客路径
+6. 综合给可行性结论（pass/fail）
+
+### 可行性判据（pass/fail 怎么判）
+startup 模式给 pass 至少满足：
+- 能讲通一条**具体变现路径**（不是「以后可以收钱」）
+- 单位经济估算**合理**：LTV/CAC ≥ 3（或能说清到达该值的路径），毛利率不为负
+- 有**低成本验证实验**可证伪付费意愿（落地页/预售/访谈愿付价）
+- `porters-five-forces` 没暴露致命结构（如：供方垄断 + 买方集中 + 无差异化壁垒 → 利润被压扁）
+四条任一明显不成立 → fail，写清哪条挂了、缺什么证据。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/商业分析.md`
+- 固定章节：
+  - 商业模式画布（9 模块 或 startup-canvas 摘要）
+  - 变现路径（3-5 个方案，每个含：怎么收钱 + 单位经济 CAC/LTV/毛利率/回本周期估算 + 风险；**标注用户主攻的 1-2 个**）
+  - 定价策略（模型选型 + 2-4 层分层 + 价值计量 + 价格敏感度判断）
+  - 赛道结构（波特五力摘要 + 利润空间判断）
+  - GTM 获客路径（首批用户来源 + 渠道 + 获客成本估算 + 90 天动作）
+  - **可行性结论 pass/fail**（含理由 + 必须先验证的关键假设 + 对应低成本实验）
+- 回写 state.json：`confirmed.commercial`（含 `mode`、`pass` 布尔、`skipped` 布尔、`monetization` 主攻方案、`unit_economics` 关键数字、`gtm` 首批渠道）
+- **startup 模式 fail 时流程必须中断**，不进闸 2（POC）；builder 模式不写 fail

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-competitor/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: dwy-competitor
+description: "【dwy·竞品分析】产品 0 到 1 立项阶段。触发场景：用户说『分析竞品 / 看看市面上有啥 / 竞品调研 / 对标分析 / 市场上谁在做 / competitor』，想知道已有玩家、市场规模和差异化切入点时。"
+---
+
+## 职责（单一）
+盘点已有竞品 + 估算市场规模，找出差异化切入点。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.idea`（含 explore 逼出的具体目标人 target_user、最窄切入 narrowest_wedge——差异化对着这个人定）
+- `.dwy/prod/[项目]/01-立项/想法收敛.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`competitor-analysis`、`market-sizing`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/竞品分析.md`
+- 固定章节：竞品清单 / 各竞品优劣 / 市场规模（TAM/SAM/SOM）/ 差异化切入点
+- 回写 state.json：`confirmed.competitors`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-explore/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: dwy-explore
+description: "【dwy·想法探索收敛】产品 0 到 1 立项第一步，帮『想做但还不清楚』的人想清楚做什么、值不值得做，并收敛成结构化想法定义。触发场景：用户说『我想做个东西 / 有个想法但不清楚 / 帮我想想做什么 / 这个值不值得做 / 想做但没想好 / 想法收敛 / explore / ideate』，在还没想清楚要做什么、写任何代码或文档之前。借鉴 YC office-hours 的 forcing questions 方法论（自写，无外部依赖）。"
+---
+
+## 职责（单一）
+立项第一步，一次干完两件事：① 用 YC 式 forcing questions 逼用户把模糊想法想清楚（做什么、给谁、值不值、最窄切入）；② 把想清楚的结论**收敛成结构化的产品想法定义**。"想不清楚或不值得"的想法在这里就被劝退，想清楚的直接产出可供下游用的 `confirmed.idea`。
+
+## 输入（从哪读）
+- 用户口述的模糊想法（立项最前端，无上游产出）
+
+## 实现（自写，内化方法论）
+
+借鉴 gstack 的 office-hours（Garry Tan / YC，MIT），把它的 forcing questions 方法论内化到这里。**不装 gstack、不依赖任何外部 skill**。
+
+### 提问形式（Claude Code 下强制）
+- 每个问题用 `AskUserQuestion` 工具弹点选卡片，**一次只问一个**，答完再问下一个，不在正文列 A/B/C/D 让用户打字。
+- 开放式补充靠卡片的「Other」兜底。
+- 其他工具（Codex 等无此组件）退回正文逐问。
+
+### 第一步：判模式
+先判断用户在做什么，决定走哪条线：
+- **创业/产品线（startup）**：奔着有人用、可能收钱、要做成产品 → 走六个 forcing questions
+- **Builder 线**：练手 / 学习 / 开源 / hackathon / 纯兴趣 → **不逼商业**，走轻量设计思维 brainstorm（帮想清楚要做成什么样、技术怎么选、范围多大），跳过下面六问
+
+### 六个 forcing questions（startup 线，一次一问）
+逐个问，**追问到答案具体、有证据、让人不舒服为止**。舒服 = 没想够深。
+
+- **Q1 需求真实性**：「最强的证据是什么——证明真有人要这个？不是『感兴趣』、不是 waitlist，而是没了会抓狂、要重新凑合。」
+  - 逼到：具体行为、有人付钱、有人扩大使用、有人把工作流搭在上面。
+  - 红旗：「大家说有意思」「攒了 500 个 waitlist」「VC 看好这赛道」——这些都不是需求。
+  - 追问后还要查：关键词有没有定义清楚（「AI 化」「无缝体验」要能量化）？藏了什么没验证的假设？是真痛点还是脑补（「我觉得开发者会想要」是假设，「我前公司三个开发者每周花 10 小时干这个」是真的）。
+- **Q2 现状替代**：「用户现在怎么凑合解决这个问题——哪怕很烂？这个凑合花他多少时间/钱？」
+  - 逼到：具体工作流、花的小时数、浪费的钱、拼凑的工具、专门雇人手工做。
+  - 红旗：「现在没方案，所以机会大」——真没人凑合，往往是痛点不够痛、不值得行动。
+- **Q3 极致具体**：「点名最需要它的那个**具体的人**。什么头衔？什么让他升职、什么让他被开、什么让他失眠？」
+  - 逼到：一个名字、一个角色、一个不解决会面临的具体后果，最好是亲耳从那人嘴里听到的。
+  - 红旗：类别级答案——「医疗企业」「中小公司」「营销团队」。类别不是人，你没法给一个类别发邮件。
+  - B2B 说职业影响、消费品说日常痛点/社交时刻、个人/开源说被解锁的周末项目——后果要贴合领域，但绝不能停在「用户」「产品经理」。
+- **Q4 最窄切入**：「本周就有人肯付真钱的最小版本是什么？不是建完整个平台之后。」
+  - 逼到：一个功能、一个工作流，可能简单到一封周报邮件或一个自动化。能在几天内发出去、有人愿意付。
+  - 红旗：「得先建完整平台才能用」「砍了就没差异化了」——这是迷恋架构、不是迷恋价值。
+  - 加问：「如果用户什么都不用做就能拿到价值——不登录、不集成、不配置——会是什么样？」
+- **Q5 观察意外**：「你真坐下来看过别人用、且没在旁边帮忙吗？他做了什么让你意外的？」
+  - 逼到：一个具体的意外，用户做了违背你假设的事。没有意外 = 要么没看、要么没在意。
+  - 红旗：「发了问卷」「做了几个 demo 电话」「没啥意外，符合预期」——问卷会撒谎、demo 是表演、「符合预期」= 被既有假设过滤了。
+  - 金矿：用户拿产品干了它没被设计来干的事——那常是真正的产品在冒头。
+- **Q6 未来契合**：「3 年后世界明显不同了（一定会），你的产品变更必需、还是更没用？」
+  - 逼到：关于用户世界如何变、为什么这个变化让产品更有价值的具体主张。
+  - 红旗：「市场每年涨 20%」（增长率不是愿景）、「AI 越来越好我们就越好」（每个对手都能这么说的水涨船高论）。
+
+### Smart routing（按阶段只问相关的，不是每次六问全砸）
+- 纯想法 / 还没产品 → Q1, Q2, Q3
+- 已有用户 → Q2, Q4, Q5
+- 已有付费客户 → Q4, Q5, Q6
+- 纯工程 / 基建 → Q2, Q4
+- 内部项目（intrapreneurship）→ Q4 改问「让你 VP/赞助人点头的最小 demo 是什么」，Q6 改问「换个领导/重组后它还活得下来吗」
+- 前面答案已覆盖后面的问题 → 跳过，只问还不清楚的
+
+### Anti-sycophancy（不拍马屁，硬性）
+- 好答案 → 点名哪里好，**立刻换更狠的追问**，不停留。最好的奖励是下一个更难的问题。
+- 答案模糊 → 先重述帮用户看清「我理解你其实想做的是 X，对吗」，再逼具体，别耗 10 分钟。
+- 用户不耐烦（「别问了直接做」）→ 说「硬问题才是价值，跳过等于不考试直接开药。再问两个最关键的就走」，按该阶段 routing 挑最关键的 2 个，问完直接进结论。第二次还推 → 尊重，立即进结论，不问第三次。
+- 只有用户给出完整方案 + 真证据（现有用户/收入数字/具体客户名）才允许全跳，但仍要给出结论。
+
+## 问运行模式（idea 收敛后，需求讨论完的点）
+idea 收敛、放行进竞品分析前，**问一次运行模式**（`AskUserQuestion`：`standard` 逐步推进、每阶段我介入确认 / `auto` 全自动跑到底、AI 自主决策最后出结果，适合 demo）。写回 `state.json` 顶层 `run_mode`。
+- 这是**运行模式**（怎么跑），区别于本 skill 判的 `confirmed.idea.mode`（startup/builder **产品类型**），两者独立。
+- 后续总控阶段间询问 + 各 stage 内门控都读 `run_mode`；`auto` 下仍保留硬闸门（validate/poc/高风险不可逆）。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/想法收敛.md`
+- 固定章节（前半逼问纪要 + 后半结构化定义，一次产出）：
+  - 模式判定（startup / builder + 理由）
+  - 六问答案纪要（实际问了哪几个 + 用户答案 + 逼出的具体结论；builder 模式写设计思维结论）
+  - **核心问题**（一句话：这产品解决什么）
+  - **目标用户**（Q3 逼出的那个具体的人，不是类别）
+  - **价值主张**（为什么用户非用不可）
+  - **关键假设**（成立则产品成立的几条前提，供下游 validate 去验）
+  - **最窄切入**（Q4：本周就有人付钱的最小版本，供下游 mvp 砍范围）
+  - **边界与不做什么**
+  - 红旗与是否放行（触红旗的答案；想清楚 → 放行进竞品分析；想不清楚或明显不值 → 建议停下重想）
+- 回写 state.json：`confirmed.idea`（含产品类型 mode / 是否放行 pass + 上述结构化定义；原 exploration 的方向并入此字段，不另列）+ 顶层 `run_mode`（standard/auto）

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-mvp/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: dwy-mvp
+description: "【dwy·MVP定义】产品 0 到 1 立项阶段（闸3）。触发场景：用户说『定义 MVP / 最小可行产品 / 先做哪些功能 / 砍功能 / 第一版做什么 / mvp』，要从想法收敛出第一版必须做的核心功能清单时。MVP 功能硬上限 ≤7 个。"
+---
+
+## 职责（单一）
+从想法+验证结果，收敛出第一版 MVP 功能清单。**功能硬上限 ≤7 个**，超出的进后续版本。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.idea`（含 explore 逼出的最窄切入 narrowest_wedge——MVP 砍 ≤7 直接对着它砍）、`confirmed.validation`、`confirmed.poc`
+- `.dwy/prod/[项目]/01-立项/想法收敛.md`、`需求市场验证.md`、`技术验证.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`prioritize-features`、`opportunity-solution-tree`（各对应 `~/.dwy/skills/<名>/`）
+- 若 `~/.dwy/skills/<名>/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/MVP清单.md`
+- 固定章节：MVP 功能清单（≤7 个）/ 优先级排序 / 砍到后续版本的功能
+- **功能数超 7 个直接拒绝，强制收敛**
+- 回写 state.json：`confirmed.mvp_features`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-poc/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: dwy-poc
+description: "【dwy·技术验证】产品 0 到 1 立项阶段（闸2）。触发场景：用户说『技术验证 / 这技术能不能成 / 跑个 POC / 验证可行性 / 核心技术死穴 / poc』，要在写 PRD 前用最小可跑代码实测核心技术假设时。仅在需求市场验证通过后执行。"
+---
+
+## 职责（单一）
+识别 1 个核心技术死穴假设，写最小可跑 POC 实测能不能成。失败→建议砍方向/换技术栈，不进 PRD。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.validation`（仅当 `pass=true` 才执行）
+- `.dwy/prod/[项目]/01-立项/需求市场验证.md`、`想法收敛.md`
+
+## 实现
+[自写型]
+1. 校验 `confirmed.validation.pass=true`，否则直接退出
+2. 从想法中识别**唯一一个**最致命的技术假设（最可能让方案不成立的那个）
+3. 写最小可跑 POC 代码实测，代码放 `.dwy/prod/[项目]/01-立项/poc/`
+4. 实测结果定性：成立 / 不成立
+5. 不成立 → 给出砍方向或换技术栈建议，**不进 PRD**
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/01-立项/技术验证.md`，POC 代码放 `01-立项/poc/`
+- 固定章节：核心技术假设 / POC 方案 / 实测结果 / 结论与建议
+- 回写 state.json：`confirmed.poc`（含 `pass` 布尔字段）

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-prd/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: dwy-prd
+description: "【dwy·PRD生成】产品 0 到 1 需求规划阶段。触发场景：用户说『写 PRD / 出需求文档 / 产品需求文档 / prd』，要把 MVP 清单细化成可开发的产品需求文档时。"
+---
+
+## 职责（单一）
+把 MVP 功能清单细化成完整可开发的 PRD。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.mvp_features`、`confirmed.idea`
+- `.dwy/prod/[项目]/01-立项/MVP清单.md`
+
+## 实现
+[包装型] 用全局本地 skill（位于 `~/.dwy/skills/<外部skill名>/`）：
+读其 `SKILL.md`（及同目录 scripts/、配套 .md），按它的方式与用户交互/提问，产出按下方「产出契约」落地。
+- **提问形式（Claude Code 下强制）**：借用外部 skill 的「问什么、怎么一步步收敛」方法论，但**每个要用户选择/拍板的问题用 `AskUserQuestion` 工具弹点选卡片**，不在正文列 A/B/C/D 让用户打字；保留「一次一问、答完再问下一个」的节奏，开放式补充靠卡片的「Other」兜底。其他工具（Codex 等无此组件）退回外部 skill 原生的正文问答。
+- 本 skill 依赖的外部 skill：`create-prd`（对应 `~/.dwy/skills/create-prd/`）
+- 若 `~/.dwy/skills/create-prd/` 不存在：提示用户先跑 `dwy skills install`（或 `dwy claude sync` 会自动装），不要自己用内置能力顶替。
+
+## 产出契约（硬约束）
+- 落到：`.dwy/prod/[项目]/02-需求规划/PRD.md`
+- 固定章节：背景与目标 / 用户场景 / 功能需求（逐条）/ 非功能需求 / 验收标准
+- 回写 state.json：`confirmed.prd`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-product-launcher/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: dwy-product-launcher
+description: "【dwy·全流程总控】从模糊想法到上线产品的唯一入口。触发场景：用户说『我想做个产品 / 从 0 到 1 把这个做出来 / 走完整流程 / 帮我把想法变成产品 / 一条龙做产品 / product launcher』，要把一个模糊念头逐步推进时。**渐进式：从立项第一步直接开始，每阶段完成后问继不继续，不预设终点、用户随时可停。** 只想做其中某一阶段，也可直接触发对应 dwy-stage-* 阶段 skill。"
+---
+
+## 职责（总控·编排层）
+从模糊想法到产品的唯一入口。按顺序串 5 个阶段 skill，维护 state.json（进度 + 已确认结论），并做多版本子 Agent 编排。**不掺产出内容**，产出由阶段内原子 skill 落地。
+
+## 渐进式推进（核心交互，读 run_mode）
+**不在入口预问"走到哪个阶段"。** 直接从立项第一步开始往下走。`dwy-explore` 在 idea 收敛后会问一次 `run_mode`（standard/auto），之后推进节奏读它：
+- **standard**：每个阶段准出后问一句「继续下一步 / 到此为止」，用户当场决定。终点不预设、随时可喊停。
+- **auto**：阶段间不问，自动连跑到底、最后出结果；**仅硬闸门未过才停**（立项的 validate/poc、高风险不可逆操作）。
+
+```
+开始 → dwy-stage-launch（立项·三闸门）
+     → 阶段完成，问：继续做需求版本？ → 用户选 继续 / 停
+继续 → dwy-stage-prd（需求版本）
+     → 阶段完成，问：继续做设计架构？ → 继续 / 停
+继续 → dwy-stage-design（设计架构）
+     → 问：继续 TDD 开发？ → 继续 / 停
+继续 → dwy-stage-dev（TDD 开发）
+     → 问：继续上架迭代？ → 继续 / 停
+继续 → dwy-stage-ship（上架迭代）→ 完
+```
+
+规则：
+- **从第一步直接开始**，不让用户提前选终点
+- standard 下每阶段准出后**只问"继不继续"**，不问"要走到哪"；auto 下不问、直接流转
+- 闸门内（立项的需求验证/POC）若没过，**无论 standard/auto 都自动停**在当前阶段，不往下走
+- 用户喊停时，已完成阶段的产出和 state.json 都已落盘，下次可断点续跑
+
+按序的五阶段：
+1. **dwy-stage-launch** — 立项（闸门：需求验证 → 商业可行性[startup 硬闸] → POC → MVP）
+2. **dwy-stage-prd** — 需求版本
+3. **dwy-stage-design** — 设计架构
+4. **dwy-stage-dev** — TDD 开发
+5. **dwy-stage-ship** — 上架迭代
+
+进度以 `state.json` 的 `current_stage` 为准；可从任意阶段断点续跑。
+
+## 读 state 先检 schema 版本（老项目升级入口）
+读到**已存在**的 `state.json` 时，**先检 `schema_version`**：缺失或低于当前（`"3"`）→ 按 `references/state-and-contract.md`「七、schema 版本与迁移」逐级迁移（v1→v2→v3），迁移后再续跑。这是老用户旧 state 无感升级的入口。
+
+## 首次初始化（只建根，不建阶段目录）
+新项目首次进入时，**只**做两件最小事：
+- 建项目根目录 `.dwy/prod/[项目]/`（不建 01~05 任何阶段子目录）
+- 初始化 `state.json`（写 `schema_version = "3"`）
+
+产品产出 `.dwy/prod/[项目]/` 入库，无需改 `.gitignore`（外部 skill 在全局 `~/.dwy/skills/`，不落项目）。若包装型原子 skill 触发时 `~/.dwy/skills/<name>/` 不存在，提示用户先跑 `dwy skills install`。
+
+**阶段目录渐进式按需建**：`01-立项/` 进立项时才建，`02-需求规划/` 进需求阶段才建……不要一次把五个阶段目录全建出来（那不是渐进式）。state schema、各 skill 的 `confirmed.*` 字段契约、外部 skill 全局安装见 `references/state-and-contract.md`。
+
+## state.json（进度 + 结论）
+落 `.dwy/prod/[项目]/state.json`，含：
+- `current_stage` — 当前阶段
+- `current_version` — 当前版本（如 `V1.0`）
+- `confirmed.*` — 各原子的已确认结论引用（idea / competitors / validation / commercial / poc / mvp_features / prd / version_plan / tasks / prototype / architecture / dev_progress / acceptance / release）
+- `versions` — 各版本状态（路线图 + 完成情况）
+
+## 多版本编排逻辑
+
+### 版本间：串行
+- V1.1 依赖 V1.0，版本一个接一个做
+- **每个版本起独立子 Agent**（独立上下文窗口），读版本路线图 + 上一版代码
+- 产出写回 `.dwy/prod/` 和源码，**只向主窗口返回成果摘要**（不返回全量代码，省上下文）
+
+### 版本内：多模块并发
+- 互不依赖的模块用多个子 Agent **并发**
+- 改同一批文件时各自独立 **worktree**，避免互相覆盖
+
+## 准出条件（硬约束）
+- 全部规划版本上线完成
+- `state.json` 各版本标记完成，`confirmed.*` 齐全

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-product-launcher/references/state-and-contract.md

@@ -0,0 +1,155 @@
+# 产品 0→1 流程 · 状态与产出契约（配套参考）
+
+`dwy-product-launcher` 总控和各原子/阶段 skill 统一遵循本文件。
+
+## 一、产出与缓存目录（最终全貌，**渐进式按需创建**）
+
+下面是流程全部走完后的**目标结构**，不是初始化时一次建好的。**渐进式原则：每个阶段真正开始时，才创建它自己那一级目录和文件**——初始化只建项目根 + state.json，`01-立项/` 进立项才建，`02-需求规划/` 进需求阶段才建，以此类推。不要上来就把 01~05 五个阶段目录全建出来。
+
+```
+.dwy/prod/
+  [项目名]/                  # 产品产出，入库（git 跟踪）
+    01-立项/
+      想法收敛.md           # dwy-explore：YC 6问逼清 + 收敛成结构化定义
+      竞品分析.md
+      需求市场验证.md         # 闸1·总闸门
+      商业分析.md            # 商业闸门·startup 硬闸（builder 跳过）
+      技术验证.md            # 闸2
+      poc/                  # 最小 POC 代码
+      MVP清单.md            # 闸3·≤7
+    02-需求规划/
+      PRD.md
+      版本路线图.md
+      开发任务拆解.md
+    03-原型设计/
+      wireframe/            # dwy-prototype 第一轮：低保真线框初稿（静态 HTML，一页一图）
+      hifi/                 # dwy-prototype 第二轮：高保真平面图（静态 HTML，一页一图）
+    04-架构设计/
+      技术架构.md
+      数据库设计.md          # 有后端时才出
+      接口契约.md
+    05-上线交付/
+      验收报告.md
+      上架物料.md
+      埋点与指标.md
+      下一版迭代规划.md
+    09-开发日志.md
+    state.json              # 进度 + 已确认结论，入库
+```
+
+**外部 skill 不在项目内**：pm-skills / superpowers 的副本装在**全局** `~/.dwy/skills/<name>/`（一台机一份、全项目共享），由 `dwy skills install` 维护，`dwy claude sync` 自检缺失时自动装。包装型原子 skill 运行时直接读这个全局路径，不在项目里缓存。
+
+## 二、.gitignore 规则（总控初始化项目时写入）
+
+产品产出 `.dwy/prod/[项目]/` **入库**（git 跟踪），无需任何忽略——外部 skill 在全局 `~/.dwy/skills/`，不落项目，没有要忽略的缓存。
+
+注意：**不要**写整行 `.dwy/`（那会把产品文档也忽略）。本流程不需要在项目 `.gitignore` 加任何条目。
+
+## 三、state.json schema
+
+线性单向，只记进度 + 已确认结论，无回退状态机。
+
+```json
+{
+  "schema_version": "3",
+  "version": "1.0",
+  "project_name": "...",
+  "current_stage": 1,
+  "current_round": "stage1_round1",
+  "run_mode": "standard | auto",
+  "confirmed": {
+    "idea": { "mode": "startup | builder", "pass": true, "core_problem": "...", "target_user": "...", "value_prop": "...", "key_assumptions": [], "narrowest_wedge": "...", "boundaries": "..." },
+    "competitors": {},
+    "validation": { "pass": true, "evidence": "...", "method": "..." },
+    "commercial": { "mode": "startup | builder", "pass": true, "skipped": false, "monetization": "...", "unit_economics": {}, "gtm": "..." },
+    "poc": { "pass": true, "deadlock": "...", "result": "..." },
+    "mvp_features": [],
+    "prd": {},
+    "version_plan": {},
+    "tasks": {},
+    "wireframe": {},
+    "prototype": {},
+    "architecture": {},
+    "dev_progress": { "<module>": { "<task>": "todo | done" } },
+    "acceptance": {},
+    "release": {}
+  }
+}
+```
+
+- `schema_version` — **state 结构版本**，当前 `"3"`，升级破坏性结构时 bump（迁移见第七节）。
+- `version` — **产品版本**（用户 app 的 V1.0/V1.1 迭代号），与 schema_version 无关，别混。
+
+字段名是各 skill 的对外契约，**回写方与读取方必须用同一名字**：
+
+| 原子 skill | 回写字段 | 下游读取方 |
+|---|---|---|
+| dwy-explore | confirmed.idea（逼问理清 + 收敛成结构化定义） | dwy-competitor（target_user/wedge 定位）+ dwy-validate（core_problem/assumptions 转定量）+ dwy-mvp（wedge 砍范围）+ dwy-prd |
+| dwy-competitor | confirmed.competitors | dwy-validate |
+| dwy-validate | confirmed.validation | dwy-commercial（仅 pass=true 才执行） + dwy-poc |
+| dwy-commercial | confirmed.commercial | dwy-poc（startup 模式仅 pass=true 或 skipped 才执行；builder 跳过） |
+| dwy-poc | confirmed.poc | dwy-mvp |
+| dwy-mvp | confirmed.mvp_features | dwy-stage-prd |
+| dwy-prd | confirmed.prd | dwy-version |
+| dwy-version | confirmed.version_plan | dwy-tasks / dwy-stage-design |
+| dwy-tasks | confirmed.tasks | dwy-stage-dev |
+| dwy-prototype（第一轮·线框初稿） | confirmed.wireframe | dwy-prototype 第二轮（基于线框升保真） |
+| dwy-prototype（第二轮·高保真平面图） | confirmed.prototype | dwy-architecture（原型定稿后才进架构） |
+| dwy-architecture | confirmed.architecture | dwy-stage-dev |
+| dwy-tdd-dev | confirmed.dev_progress | dwy-stage-ship |
+| dwy-acceptance | confirmed.acceptance | dwy-release |
+| dwy-release | confirmed.release | 迭代回到阶段二 |
+
+## 四、外部 skill 全局安装 `~/.dwy/skills/`
+
+包装型原子 skill（dwy-competitor / dwy-validate / dwy-commercial / dwy-mvp / dwy-prd / dwy-version / dwy-tasks / dwy-tdd-dev / dwy-acceptance / dwy-release）依赖 pm-skills / superpowers 的外部 skill，装在**全局** `~/.dwy/skills/<name>/`：
+
+- 每个外部 skill 是**整个目录**（含 scripts/ 与配套 .md，不止 SKILL.md）
+- 由 cli 命令 `dwy skills install` 安装/更新（clone 两仓库的指定 stable tag → 搬整目录 + LICENSE → 写 `VERSIONS.json`）
+- `dwy claude sync` 自检：`~/.dwy/skills/` 缺失时自动装一次
+- 当前 stable：pm-skills **v2.0.0** | superpowers **v6.0.3**（升级改 cli 的 `skills-install.js` 清单 tag）
+- 原子 skill 运行时**只读** `~/.dwy/skills/<name>/`，缺失则提示用户先 `dwy skills install`，不自己拉、不降级
+
+## 五、运行模式与流转（run_mode）
+
+`state.json` 顶层 `run_mode`，取值 `standard | auto`，由 `dwy-explore` 在 idea 收敛后问一次写入（区别于 `confirmed.idea.mode` 的 startup/builder **产品类型**，`run_mode` 是**怎么跑**）。总控与每个 `dwy-stage-*` 都读它：
+
+| run_mode | 阶段间 | stage 内门控（原型两轮 / PRD 确认等） | 硬闸门（validate 没人要 / poc 做不出 / 高风险不可逆） |
+|---|---|---|---|
+| `standard` | 每阶段准出后问「继续 / 停」 | 照常问用户 | 停 |
+| `auto` | 不问，自动连跑到底出结果 | 全部 AI 自动决策、不问 | **仍停**（auto 不绕硬闸门） |
+
+**流转规则**：每个 stage 准出 = 回写 `current_stage` + 按 `run_mode` 决定「问后流转」（standard）或「直接触发下一 `dwy-stage-*`」（auto）。总控 `dwy-product-launcher` 与单独触发某 stage **行为一致**，都走这套流转。最后一阶段 ship 无下游，正常结束。
+
+**stage 独立触发 + 上游补齐**：单独触发某 `dwy-stage-*` 时上游 `confirmed.*` 缺失 → 不报错，基于已聊上下文 + 现有产出文件**轻量补齐**够本阶段用的上游结论，写回对应 `confirmed.*` 标注「上下文补齐」。**安全边界**：可补产出文档/范围类（prd/version_plan/tasks/prototype/architecture/mvp_features 范围）；**禁止**凭空标硬闸门 `pass=true`（`validation`/`poc` 只能由 launch 真实跑出）。
+
+## 六、断点续跑
+
+会话中断后，总控读 `state.json` 的 `current_stage` + `current_round`，从中断处续跑。已确认字段不重做。
+
+## 七、schema 版本与迁移（单一来源）
+
+**当前 `schema_version = "3"`。** 缺失或 `< 3` = 老结构，**读 state 的 skill（总控 / 任一 stage）必须先迁移再继续**——这是老用户无感升级的唯一入口。迁移**逐级叠加**（v1 项目走 v1→v2→v3）。新建项目直接写 `schema_version = "3"`。
+
+### v1 → v2 迁移规则（AI 执行，幂等）
+老 state（无 `schema_version`，或 dev_progress 是平层）按序处理：
+
+1. **dev_progress 平层 → 嵌套**：`{"<module>": "todo|done"}` → `{"<module>": {"_legacy": "todo|done"}}`（旧模块整体视为一个已完成/待办任务占位；本版本新任务在该 module 下追加 `<task>`）
+2. **旧 prototypes/ 原型归档**：`prototypes/` 目录下的旧原型文件 → 移到 `prototypes/wireframe/`，在该目录 `index` 注明「旧版原型（可交互白板），仅历史保留」；旧 `confirmed.prototype` **保留**，但标注「旧版产物，新两轮（线框 → 高保真平面图）可按需重跑」
+3. **补 `confirmed.wireframe`**（若无）= 引用迁移后的 `prototypes/wireframe/`
+4. **补顶层 `run_mode`**（若无）= `"standard"`
+5. **写 `schema_version = "2"`**（继续走 v2→v3）
+6. 迁移完在 `09-开发日志.md` 记一行（迁移前版本 / 改了什么）
+
+### v2 → v3 迁移规则（AI 执行，幂等）
+v2 把原型与架构拆成独立平级阶段目录、上线交付目录顺延。`schema_version = "2"`（或 v1→v2 刚处理完）的项目按序处理：
+
+1. **原型目录独立**：`03-设计与架构/prototypes/wireframe|hifi/` → 移到 `03-原型设计/wireframe|hifi/`
+2. **架构文档独立**：`03-设计与架构/{技术架构,数据库设计,接口契约}.md` → 移到 `04-架构设计/`
+3. **上线交付顺延**：`04-上线交付/` 整体改名 `05-上线交付/`
+4. 删空的 `03-设计与架构/`
+5. **写 `schema_version = "3"`**
+6. 迁移完在 `09-开发日志.md` 记一行
+
+### 未来再升级
+bump `schema_version` + 在本节追加 `vN → vN+1` 规则；**旧规则保留**，以支持跨多版本逐级迁移（v1→v2→v3→…）。

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-prototype/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: dwy-prototype
+description: "【dwy·UI原型】产品 0 到 1 设计与架构阶段。触发场景：用户说『画原型 / 出原型 / 做 UI 原型 / 把页面画出来 / prototype』，要在写 UI 代码前把页面画成静态原型图时。两轮串行门控：先低保真线框初稿，用户讨论通过后再做高保真平面图，过了才进架构。"
+---
+
+## 职责（单一）
+把 PRD 的页面画成**静态原型图**，两轮串行、每轮门控：**① 线框初稿（低保真）→ 用户讨论通过 → ② 高保真平面图 → 用户讨论通过**。
+
+两轮都是**静态、按页出图**，区别只在保真度——都不做可交互（无拖拽/缩放/连线/点击跳转），浏览器直接展示，速度优先。本流程不调用白板引擎，纯静态 HTML 自写。
+
+## 输入（从哪读）
+- state.json 的 `confirmed.prd`、`confirmed.tasks`
+- `.dwy/prod/[项目]/02-需求规划/PRD.md`
+
+## 判设备形态（两轮共用，先做）
+读 PRD/上下文判目标端，决定页面外框，**不写死尺寸**：
+- 移动端 → 套手机框（iOS 用 iPhone 逻辑尺寸如 390×844、鸿蒙用对应 vp）
+- 网页端 → 不套设备框，用浏览器视口比例
+- 平板 → 用平板真实比例
+
+## 第一轮·线框初稿（低保真静态）
+1. 一个页面一张**低保真静态线框图**：灰阶/占位块表达布局结构，重点让用户看**页面齐不齐、布局对不对、信息层级合不合理**，不纠结视觉、不上色、不做交互。
+2. 图标用占位（稳定图标库的字符或内联 SVG 占位），**不用 emoji** 作功能性图标。
+3. 每图带一句**用途说明** + 关键**边界**（空态/加载/错误等该页适用项），纯文字描述。
+4. 形式：静态 HTML，一页一文件 `<页面>.html` + 总览 `index.html`（平铺各页缩略，可点下钻到单页，仅此导航，无页面内交互）。设备外框按上面判得的形态（网页端不套框）。
+5. 产出：`.dwy/prod/[项目]/03-原型设计/wireframe/`
+6. **门控**：产出后向用户汇报线框覆盖情况，明确问「线框初稿是否通过，可进高保真？」。未通过按反馈改，改完再问。通过后回写 `confirmed.wireframe`。
+
+## 第二轮·高保真平面图（静态，一页一图）
+1. 前置校验 `confirmed.wireframe` 存在，否则报错提示先过线框初稿。
+2. **基于已定稿的线框逐页升保真**：保持线框确定的页面清单与布局，上真实色板/明暗调/真实图标（稳定图标库，不用 emoji）/真实文案。仍是静态、不做可交互。
+3. 配色按产品定位定（金融稳重 / 社交活泼 / 工具中性）；**反 AI 套路**：不堆渐变 blob、不用 emoji 功能图标、用语义色板、≤2 字体。
+4. **每图必带说明**：用途 + 关键交互说明（文字描述「点 X 去 Y」即可，不做可点跳转）+ 边界。
+5. 形式：静态 HTML，一页一文件 `<页面>.html` + 总览 `index.html`，浏览器直接展示。**速度优先**。
+6. 产出：`.dwy/prod/[项目]/03-原型设计/hifi/`
+7. **门控**：产出后汇报，问「高保真平面图是否通过，可进架构？」。通过后回写 `confirmed.prototype`。
+
+## 产出契约（硬约束）
+- 两轮目录分开：`03-原型设计/wireframe/` 与 `03-原型设计/hifi/`，各含每页 `<页面>.html` + `index.html` 总览
+- 两轮都要：覆盖 PRD 所有页面、每图带说明、设备形态贴合目标端
+- 高保真轮额外：布局与线框定稿一致
+- 回写 state.json：线框轮 `confirmed.wireframe`、高保真轮 `confirmed.prototype`