visual-spec 0.1.0 → 0.1.2

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_product_reviews.md

@@ -0,0 +1,32 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”补齐商品评论/评价页面（Web + Mobile），并与商品详情页形成可演示串联。
+
+路由（必须）：
+1. Web：`/products/:id/reviews`（至少保证 `/products/1/reviews` 可访问）。
+2. Mobile（前缀必须为 `/m/*`）：`/m/product/:id/reviews`（至少保证 `/m/product/1/reviews` 可访问）。
+
+页面结构（必须）：
+1. 顶部摘要：
+   - 评论总数、好评率（mock）
+   - 星级分布（可用进度条/条形图占位）
+2. 筛选与排序（最小可用即可）：
+   - 筛选：全部/有图/追评（示例即可）
+   - 排序：最新/最有用
+3. 评论列表：
+   - 单条评论至少包含：用户昵称（可匿名）、星级、评论内容、图片（可选）、时间（本地化）
+   - 敏感信息必须脱敏显示（若出现手机号/邮箱等字段）
+4. 写评论（必须）：
+   - “写评价”按钮：打开 Drawer 表单（禁止页内直接编辑）
+   - 字段至少包含：星级（必填）、内容（必填）、图片（可选，mock 上传即可）
+   - 提交后写回 mock，并在列表可见
+
+交互与状态（必须可演示）：
+1. 支持分页/加载更多（Web 用分页也可，Mobile 建议滚动加载）。
+2. 加载/空/错误状态：Skeleton、空态引导、错误重试。
+
+数据要求（必须）：
+1. 评论数据来自 mock（例如 `mock.reviews[productId]`），字段至少包含：id、productId、userName、rating、content、images、time。
+2. 允许同一用户重复评价的策略可简化为覆盖或追加（需明确在 mock 行为里）。
+
+入口要求（必须）：
+1. 商品详情页必须提供“查看全部评论”入口跳转到本页（Web 与 Mobile 各自对应路由）。
+

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_promotion.md

@@ -0,0 +1,58 @@
+你是一名资深前端原型工程师。你的任务是：在“原型工程（/specs/prototypes/）”中补齐优惠/券/促销相关页面与交互，使其能覆盖优惠多样性并可在购物车/支付链路中演示生效。
+
+触发条件（满足任一则必须生成）：
+1. 功能清单出现：优惠/促销/优惠券/折扣券/满减/折扣/免邮/券码/叠加。
+2. 数据模型出现：coupon/promotion/discount/benefit/valid_from/valid_to 等同义字段。
+
+路由与入口（必须）：
+1. Web（运营/配置类）：
+   - 优惠券/促销列表：`/promotions`
+   - 优惠券/促销详情：`/promotions/:id`（至少保证 `/promotions/1` 可访问）
+2. 必须与交易链路联动：
+   - 购物车与支付页必须提供“选择优惠券/查看优惠明细”入口，并确保选择后金额实时变化（写回 mock）。
+
+优惠多样性要求（必须覆盖）：
+1. 优惠类型（至少 4 类都要有样例）：
+   - 满减：满足门槛金额后减免固定金额
+   - 固定比例折扣：例如 9 折/8.5 折
+   - 指定商品/服务折扣：仅对指定商品/类目/SKU 生效
+   - 免运费：运费抵扣为 0 或抵扣 shipping
+2. 有效期（必须）：
+   - 每个优惠必须包含有效期字段（start/end 或 expiredAt）
+   - 过期/未开始：在选择器与详情页都必须置灰并给出原因
+3. 适用范围（商品/服务，必须）：
+   - 必须明确“适用商品/适用服务”的口径，并且都必须支持“所有”选项：
+     - 商品范围：`all`（所有商品）/ `category`（指定类目）/ `productIds`（指定商品/SKU）
+     - 服务范围：`all`（所有服务）/ `serviceType`（指定服务类型）/ `serviceIds`（指定服务/项目）
+   - 页面展示要求：
+     - 列表页与详情页必须展示“适用范围”且可读（例如“所有商品”“指定类目：餐饮”“指定商品：SKU123/456”）
+     - 选择器中必须能清晰选择“所有商品/所有服务”，并与类目/指定项互斥（选了 all 则清空其他范围）
+3. 低值券（必须）：
+   - 至少 1 张低面额券（例如 2~5 元），用于验证最小优惠链路
+4. 叠加规则（必须）：
+   - 至少包含“可叠加/不可叠加”两类优惠
+   - 当用户已选择不可叠加券时，必须阻止再选其他券，并提示规则原因
+5. 客群限制（必须）：
+   - 至少 1 张优惠限定客群（新用户/会员等级/指定标签/指定组织），不满足则不可用并提示
+
+页面要求（Web，必须可演示）：
+1. `/promotions` 列表：
+   - 查询条件（必须）：时间范围（RangePicker）+ 类型 + 状态（进行中/未开始/已结束）至少其二
+   - 列表字段至少包含：名称、类型、面额/折扣、门槛、可叠加、适用范围、有效期、状态（中文 Tag）
+   - 操作：查看详情、停用/启用（mock 生效）、复制创建（可选）
+2. `/promotions/:id` 详情：
+   - 基础信息（Descriptions）：类型、规则、适用范围、客群限制、叠加规则、有效期
+   - 效果预览：给出 2~3 个订单样例（mock），展示优惠前后对比与抵扣明细
+
+数据要求（必须）：
+1. mock 数据至少包含：
+   - `mock.promotions`：优惠规则列表
+   - `mock.couponWallet`：当前用户可领取/已领取/可用券列表（可简化）
+2. 字段至少包含：
+   - id、title、type、value、thresholdAmount、stackable、validFrom、validTo、eligibleSegments、status
+   - 商品范围：`productScope`（all/category/productIds）+（可选）`productCategories`/`productIds`
+   - 服务范围：`serviceScope`（all/serviceType/serviceIds）+（可选）`serviceTypes`/`serviceIds`
+   - 要求：必须允许 `all`，且与其他范围字段互斥（选 all 则其他为空数组）
+3. 必须提供“优惠计算”最小实现：
+   - 输入：items、shipping、selectedCoupons/promotions、userSegment
+   - 输出：discountAmount、shippingDiscount、payable、discountDetails（逐条明细）

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_quiz.md

@@ -0,0 +1,58 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”补齐做题/测评页面（Web + Mobile），用于演示“开始答题 → 作答 → 交卷 → 查看结果/解析”的闭环。
+
+路由（必须）：
+1. Web：
+   - 做题页：`/quiz`（必须稳定可访问）
+   - 结果页：`/quiz/result`（必须稳定可访问）
+2. Mobile（前缀必须为 `/m/*`）：
+   - 做题页：`/m/quiz`（必须稳定可访问）
+   - 结果页：`/m/quiz/result`（必须稳定可访问）
+
+做题页（必须）：
+1. 题型覆盖（至少 3 种）：
+   - 单选题（Radio）
+   - 多选题（Checkbox）
+   - 判断题（是/否）
+   - 可选加分项：填空/简答（Textarea，占位即可但必须可输入并保存）
+2. 页面结构（Web）：
+   - 左侧/顶部：题目导航（题号 + 已答/未答状态；支持点击跳转）
+   - 主体：题干 + 选项/输入区
+   - 底部：上一题/下一题、标记（收藏/疑问）按钮、交卷按钮
+3. 页面结构（Mobile）：
+   - 顶部栏：返回 + 标题“测评”
+   - 主体：题干 + 选项/输入区
+   - 顶部或底部：题号进度（如“3/20”）+ “题号面板”入口（BottomSheet）
+   - 底部吸底操作栏：上一题/下一题 + 交卷（Primary）
+4. 关键交互（必须可演示）：
+   - 作答后自动保存到 mock（切换题目后答案保留）
+   - 支持“标记题目”（用于回看），在题号导航中有明显标识
+   - 交卷前弹出确认（Modal/Drawer）
+   - 支持“未答题提示”：交卷时若存在未答题，需提示未答数量，并可跳转到第一道未答题
+5. 状态与反馈（必须）：
+   - 加载态（Skeleton/Spin）
+   - 交卷提交中 Loading，防重复提交
+   - 错误态 + 重试（可与 config 失败注入联动或本页开关）
+
+结果页（必须）：
+1. 总览区：
+   - 得分/正确率/用时（mock）
+   - 完成状态（如“已完成/未完成”）
+2. 题目复盘：
+   - 列表展示每题对错（Tag 颜色统一：对=绿，错=红，未答=灰）
+   - 点击进入“题目解析”（可在同页展开 Collapse 或跳转到 `/quiz?review=1&index=...` 复用做题页只读模式）
+3. 动作区（必须）：
+   - “再做一次”（重置答案并回到做题页）
+   - “返回首页/返回工具箱”（按原型导航约定跳转）
+
+数据要求（必须）：
+1. 数据来自 mock（例如 `mock.quiz`），至少包含：
+   - `paper`：试卷信息（id、title、durationMinutes、totalScore）
+   - `questions`：题目列表（id、type、stem、options、answer、analysis、score）
+   - `answers`：用户答案（questionId、value、marked、answeredAt）
+   - `result`：成绩与统计（score、correctCount、wrongCount、blankCount、timeUsedSeconds）
+2. Web 与 Mobile 必须复用同一份题库与答案数据源。
+3. 文案、题干、解析必须中文化（mock 中文文本即可）。
+
+入口要求（必须）：
+1. Web：必须能从左侧菜单或 Landing 快捷入口进入（按原型整体导航约定选择其一，需稳定可访问）。
+2. Mobile：移动端 Landing 金刚区必须提供“做题/测评”入口，跳转到 `/m/quiz`。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_richtext_publish.md

@@ -0,0 +1,54 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”补齐“富文本内容发布”页面（Web + Mobile 可选），用于演示“编辑 → 预览 → 校验 → 发布 → 列表可回看”的闭环。
+
+路由（必须）：
+1. Web：
+   - 内容发布：`/content/publish`（必须稳定可访问）
+   - 内容列表：`/content`（必须稳定可访问，用于回看已发布内容）
+2. Mobile（前缀必须为 `/m/*`，用户明确需要移动端发布时才生成）：
+   - 内容发布：`/m/content/publish`
+   - 内容列表：`/m/content`
+
+发布页（必须）：
+1. 基础信息表单（必须）：
+   - 标题（必填）
+   - 分类（必填，Select）
+   - 标签（可选，Tag/Select 多选）
+   - 封面图（可选：上传占位或从 mock 选择）
+   - 摘要（可选，Textarea）
+2. 富文本编辑区（必须可演示）：
+   - 必须提供“工具条 + 编辑区 + 预览区”三段式
+   - 允许使用轻量 mock 实现：工具条按钮（加粗/斜体/标题/有序列表/插入链接/插入图片占位）对编辑内容进行最小变更
+   - 预览区必须可切换显示（Tabs：编辑/预览），预览需渲染为富文本效果（最小可用即可）
+3. 发布设置（至少 2 项）：
+   - 可见范围（公开/仅内部/指定角色，mock）
+   - 定时发布（开关 + 时间选择，mock）
+   - 评论开关（可选）
+4. 底部操作区（必须）：
+   - 保存草稿（写回 mock）
+   - 预览（切换到预览模式）
+   - 发布（Primary）：发布成功后跳转到列表页并能看到新增内容
+
+校验与状态（必须可演示）：
+1. 校验（必须）：
+   - 标题与分类必填
+   - 正文必填（最小长度可设为 > 20 字符）
+2. 状态：
+   - Loading：发布中显示 loading 并防重复提交
+   - 成功：message 提示 + 跳转列表
+   - 失败：错误提示 + 重试按钮（可与 config 失败注入联动）
+
+内容列表页（必须）：
+1. 列表项至少包含：标题、分类、标签、状态（草稿/已发布/定时）、更新时间（本地化）。
+2. 支持搜索（标题关键词）与筛选（状态/分类，最小可用即可）。
+3. 支持点击进入“详情/预览”（可用 Drawer 或详情路由二选一）。
+4. 支持“编辑”入口：跳回发布页并加载内容（mock）。
+
+数据要求（必须）：
+1. 数据来自 mock（例如 `mock.content`），至少包含：
+   - `drafts`、`published`：内容列表（id、title、category、tags、cover、summary、contentHtml、status、visibility、publishAt、updatedAt）
+   - `currentEditing`：当前编辑内容
+2. 时间展示必须本地化；状态/枚举必须中文展示。
+
+入口要求（必须）：
+1. Web：可从左侧菜单或 Toolbox 进入（按原型整体导航约定选择其一，需稳定可访问）。
+2. Mobile：若生成移动端发布，移动端 Landing 金刚区需提供“内容发布”入口。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_super_form_builder.md

@@ -0,0 +1,50 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”补齐“超级表单配置（表单搭建器）”页面，用于演示“字段拖拽/配置 → 预览 → 生成表单 Schema → 用 Schema 渲染填写页”的闭环。
+
+路由（必须）：
+1. Web：
+   - 表单配置：`/tools/form-builder`（必须稳定可访问）
+   - 表单预览：`/tools/form-preview`（必须稳定可访问）
+2. Mobile（可选；用户明确需要移动端填写时才生成）：
+   - 表单填写：`/m/form/:id`（至少保证 `/m/form/1` 可访问）
+
+表单配置页（必须）：
+1. 页面布局（必须，三栏）：
+   - 左侧：字段库（Field Palette）
+   - 中间：表单画布（Canvas，展示当前表单结构）
+   - 右侧：属性面板（Properties，配置选中字段）
+2. 字段库（至少 10 类控件）：
+   - 文本输入、数字、金额、单选、多选、下拉选择、日期、日期范围、开关、上传（占位）、地址（占位）
+3. 画布能力（必须可演示）：
+   - 支持新增字段（点击添加即可，不要求真实拖拽，但若可做拖拽更好）
+   - 支持调整顺序（上移/下移按钮）
+   - 支持分组（Section/Divider），至少支持“基础信息/明细/补充信息”三段结构
+   - 支持必填标识与校验提示展示
+4. 属性面板（必须）：
+   - 字段 label（中文）、fieldKey（英文唯一标识）、是否必填、占位文案
+   - 控件类型相关属性（例如 Select 的 options；金额的小数位；日期格式）
+   - 校验规则（最小可用即可：必填/长度范围/数值范围）
+5. Schema 输出（必须）：
+   - 提供“导出 Schema（JSON）”按钮，弹窗展示 JSON（可复制）
+   - Schema 至少包含：id、version、title、sections、fields（fieldKey/type/label/required/rules/options/...）
+6. 操作区（必须）：
+   - 保存（写回 mock，生成/更新 formDefinition）
+   - 预览（跳转 `/tools/form-preview` 并带 formId）
+   - 新建表单/复制表单（可选）
+
+表单预览页（必须）：
+1. 以只读/可填两种模式展示（Tabs/开关均可）。
+2. 必须使用“同一份 Schema”渲染出表单 UI（最小可用即可）。
+3. 提交动作（mock）：
+   - 校验通过：成功提示 + 生成一条提交记录
+   - 校验失败：定位到第一个错误字段并提示
+4. 提供“返回配置”入口回到 `/tools/form-builder`。
+
+数据要求（必须）：
+1. 数据来自 mock（例如 `mock.forms`），至少包含：
+   - `formDefinitions`：表单定义列表（id、title、version、schemaJson、updatedAt）
+   - `currentEditingFormId`
+   - `submissions`：提交记录（formId、submissionId、data、time）
+2. 所有字段 label、状态文案必须中文化；时间本地化。
+
+入口要求（必须）：
+1. Web：必须能从 Toolbox 进入（例如“更多/工具 → 工具箱 → 表单搭建器”）。

package/{.trae/skills/starter-skill → skills/visual-spec-skill}/prompts/vspec_verify/prototype_toolbox.md

@@ -23,4 +23,5 @@
 联动要求（必须）：
 1. Toolbox 必须与现有工具页路由打通，至少包含并可跳转到：
    - `/tools/introduction`、`/tools/data-dict`、`/tools/config`、`/tools/qr-code`、`/tools/video`、`/profile`、`/agreement/confirm`
+   - `/tools/form-builder`、`/tools/form-preview`（若生成了超级表单/表单搭建相关页面）
 2. 若原型已实现：`/tools/notify-center`、`/weather`、`/report`、`/big-screen`，则 Toolbox 必须自动补齐对应入口卡片。

package/skills/visual-spec-skill/prompts/vspec_verify/prototype_video.md

@@ -0,0 +1,27 @@
+你是一名资深前端原型工程师。你的任务是：为“原型工程（/specs/prototypes/）”补齐视频展示类页面（Web + Mobile），用于演示素材库/课程/教程等视频内容的浏览与播放交互。
+
+路由（必须）：
+1. Web：`/tools/video`（若已存在则增强为可演示版本）。
+2. Mobile（前缀必须为 `/m/*`）：`/m/video`（必须稳定可访问）。
+
+页面结构（必须）：
+1. 视频列表：
+   - 至少 6 个视频卡片：标题、时长、摘要、封面、标签
+   - 支持搜索/筛选（最小可用即可）
+2. 播放区域：
+   - 点击视频卡片进入播放态（可在同页弹 Drawer/Modal，或跳转详情路由二选一）
+   - 播放/暂停、进度条占位交互必须可演示（mock 即可）
+3. 最近播放（必须）：
+   - 记录最近播放列表（mock），并可一键继续播放
+
+交互与状态（必须可演示）：
+1. 加载/空/错误状态：Skeleton、空态引导、错误重试。
+2. 权限受限视频：至少 1 条视频标注“无权限”，卡片置灰并提示原因（基于 session/角色 mock）。
+
+数据要求（必须）：
+1. 数据来自 mock（例如 `mock.videos`），字段至少包含：id、title、duration、summary、cover、tags、permission。
+2. Web 与 Mobile 复用同一数据源。
+
+入口要求（必须）：
+1. Mobile：移动端 Landing 金刚区必须提供“视频”入口，跳转到 `/m/video`。
+

package/{.trae/skills/starter-skill → skills/visual-spec-skill}/prompts/vspec_verify/validation.md

@@ -44,5 +44,9 @@
 
 输出与写入要求：
 1. 将页面代码与工程改动写入到 `/specs/prototypes/` 目录下的原型工程中
-2. 确保 `scenario.html` 可访问，并从首页提供入口跳转到 `scenario.html`（不要要求在左侧菜单新增名为“场景”的菜单项）
+2. 确保 `scenario.html` 可访问，但不要把它集成进任何菜单/导航：
+   - 不要出现在左侧菜单
+   - 不要出现在首页/工作台的任何默认展示区域
+   - 不要在 Header/Toolbox 等位置增加入口链接
+   - 访问方式仅保留“直接访问 URL（/scenario.html）”
 3. 若使用 Vite 多入口（multi-page）方式，必须同步更新 `vite.config.*` 以支持 `index.html` 与 `scenario.html` 同时构建与开发访问

package/.trae/skills/starter-skill/prompts/vspec_new/background.md

@@ -1,76 +0,0 @@
-你是一名资深需求分析师和视觉规格设计师。你会根据用户提供的原始需求，先完成需求澄清与结构化分析，再输出可继续用于界面设计和业务细化的结果。
-
-输入内容为用户刚刚通过 `/vspec:new` 提交的原始需求。
-
-请严格按以下步骤执行：
-
-0. 创建材料目录（docs）
-   - 如果 `/docs` 不存在，请先创建目录
-   - 如果 `/docs/README.md` 不存在，请创建并写入以下内容（保持简短）：
-
-     # docs（需求材料）
-
-     本目录用于存放与本需求相关的业务材料与交付对齐资料，例如：原始文档、流程说明、字段口径、模板/协议/文案、截图、样例数据等。
-
-     建议按主题或日期建立子目录，并在文件名中体现来源与版本。
-
-1. 归档原始需求
-   - 将用户输入的原始需求原文保存到：`/specs/background/original.md`
-   - 如果 `/specs/background` 不存在，请先创建目录
-   - 在该文件中先写入一个小节 `# 原始需求`，其下粘贴原文（不要改写）
-
-2. 提炼需求摘要
-   - 用 2 到 4 句话总结业务目标
-   - 说明这个需求要解决的核心问题
-
-3. 补全业务背景
-   - 识别需求发起方、目标用户、使用场景
-   - 如果原始需求过于简单，基于合理假设补全背景，并明确标注为“假设”
-
-4. 拆解核心功能
-   - 列出主要功能点
-   - 说明每个功能点的输入、处理、输出
-
-5. 设计页面与交互
-   - 推导需要的页面或模块
-   - 描述页面布局重点、关键组件、用户操作路径
-
-6. 提取数据模型
-   - 列出核心实体
-   - 为每个实体给出关键字段、字段含义、是否必填
-
-7. 细化业务逻辑
-   - 说明关键流程
-   - 标记约束条件、状态变化、异常情况
-
-8. 输出待确认问题
-   - 如果存在信息缺口，列出需要用户下一步补充的问题
-   - 问题要具体、可回答、按优先级排序
-   - 提问设计必须覆盖并按以下维度分组组织（避免随机发散），每个维度只问“缺口最大、最影响方案”的问题：
-     - 背景：业务目标、触发原因、成功口径、现状流程与痛点
-     - 企业类型：行业/组织形态、集团/多法人/多组织、地域/多语言、管控模式（集权/分权）
-     - 业务类型：业务链路类型（ToB/ToC/内部运营）、交易/项目/工单/审批类、线上/线下、跨部门协作方式
-     - 财务：计费/预算/成本/收入口径、币种与税率、对账与结算周期、财务期间/关账、科目/核算维度
-     - 人员：角色与编制、组织架构与汇报线、权限边界、参与人数与峰值并发、交接/代办/离职处理
-     - 系统与数据（如涉及）：数据来源与主数据、历史数据迁移、对接系统、权限/审计/合规要求
-   - 输出格式建议：在“# 待确认问题”下按上述分组使用小标题，每组 2 到 6 个问题；若某组无信息缺口则可省略该组
-
-请使用以下输出结构：
-
-# 原始需求（写入 /specs/background/original.md）
-
-# 需求摘要
-
-# 业务背景
-
-# 核心功能
-
-# 业务逻辑
-
-# 风险与假设
-
-# 待确认问题
-
-写入要求：
-- 将本次完整输出（包含“原始需求、分析内容、待确认问题”）追加写入到：`/specs/background/original.md`
-- 文件中必须保留原始需求原文与本次分析结果，便于后续 stakeholders/roles 阶段引用

package/.trae/skills/starter-skill/prompts/vspec_new/functions.md

@@ -1,82 +0,0 @@
-你是一名资深产品分析师/系统分析师。你的任务是：在外部依赖系统识别完成后，基于当前需求材料输出“功能清单”，并合理把与外部系统交互相关的功能分布到对应的系统分组下。
-
-输入信息包含：
-- 原始需求与 background 分析（/specs/background/original.md 或等价内容）
-- 干系人与角色任务（/specs/background/stakeholder.md、/specs/background/roles.md 或等价内容）
-- 术语表（/specs/background/terms.md 或等价内容）
-- 流程与场景与细节（/specs/flows/*.puml、/specs/background/scenarios.md、/specs/background/scenario_details/ 或 /specs/background/scenario_details.md（旧版））
-- 外部依赖系统清单（/specs/background/dependencies.md）
-
-输出目标：
-1. 生成“本系统功能清单”（核心产品功能）
-2. 如果存在外部依赖系统：为每个外部系统分别生成一份功能清单（该系统相关的对接/同步/校验/通知/对账等功能）
-
-分组与写入要求：
-- 生成目录：`/specs/functions/`
-- 如果目录不存在，请先创建
-- 输出文件规则：
-  - 本系统：`/specs/functions/core.md`
-  - 外部依赖系统：每个系统一个文件，使用英文小写下划线命名，例如：`/specs/functions/crm.md`、`/specs/functions/sso.md`
-  - 如果无法确定英文名，用 `ext_1.md`、`ext_2.md`，并在文件标题里写清系统中文名
-
-表格格式（每个文件都必须包含一个或多个表格，严格使用此表头）：
-
-| 模块 | 功能 | 子功能 | 说明 |
-| --- | --- | --- | --- |
-
-功能分析规则：
-1. 以“用户可感知/可验收”的功能为粒度，不要拆到按钮级别
-2. 子功能用于表达该功能下的重要分解（通常 2 到 6 条）；如果不需要可留空
-3. 模块命名优先与 roles/flows/terms 对齐，例如：申请、审批、执行、变更、取消、查询与报表、配置与权限、审计与归档等
-4. 涉及外部系统依赖的功能：
-   - 在 `core.md` 中保留业务端功能（例如“申请提交”“审批决策”等）
-   - 在对应外部系统文件中补充对接类功能（例如“同步组织人员”“推送审批结果”“拉取资源库存”“对账校验”等）
-5. 场景覆盖要求（必须）：
-   - 生成功能清单时，必须显式对齐 `scenarios.md` 中的关键回退/拒绝/异常场景，确保功能清单中包含可落地的“回退与兜底能力”，而不是只覆盖主流程
-   - 至少检查并覆盖以下类型（按需裁剪，但若 scenarios 中出现则必须在 functions 中体现）：
-     - 审批驳回/拒绝：驳回原因、退回到哪个状态、重提/补充材料/重新走审批链
-     - 取消/撤销：申请后取消、审批后取消、执行前取消、执行中紧急叫停
-     - 变更：审批前变更、审批后变更、执行前变更、执行中变更（如允许）
-     - 执行者拒绝/换人执行：拒绝原因、重新分派、占用释放、SLA 影响
-     - 资源冲突/额度不足：冲突检测、提示与替代方案（排队/换资源/拆单/驳回）
-     - 外部系统异常：超时/失败的降级、重试、补偿、对账与人工兜底
-   - 对每类回退/拒绝场景：在“模块/功能/子功能/说明”中体现其触发入口、处理动作、状态变化与审计/通知要求
-5. 输出控制：
-   - `core.md` 不限制行数（以覆盖完整、可评审为准）
-   - 每个外部系统文件默认 10 到 30 行
-   - 避免重复，优先合并同类项
-
-文件结构要求（请严格遵循）：
-- 按“系统”拆分文件，不要按“模块”拆分文件
-- 每个文件只输出 1 个 markdown 表格（模块通过“模块”列表达，不要拆成多个表格或多个小节）
-- 表格表头必须固定为：`模块 | 功能 | 子功能 | 说明`
-
-端分配规则（必须，影响后续原型生成）：
-1. 功能清单必须明确每一行“功能点”由哪个端实现，写在“说明”字段里，且必须放在说明开头，使用固定格式：
-   - `端={Web|Mobile|Web+Mobile|Backend|Job}；入口={路由/按钮/接口/任务}；` 后续再补充业务说明
-2. 端含义：
-   - Web：PC 后台管理端（带 Header+Menu+工作区三段式布局）
-   - Mobile：移动端（路由前缀 `/m/*`，移动端布局；Web 端对应动作需置灰并提示“请在手机端操作”）
-   - Web+Mobile：两端都要做，但职责要拆清（在说明里补一句“Web 做xx；Mobile 做xx”）
-   - Backend：仅服务端能力（API/集成/规则引擎/权限校验等），不生成页面
-   - Job：仅后台作业/定时任务，不生成页面（后续由 cron_job 模块汇总输出）
-3. 对页面型功能点，说明必须包含推荐路由（写在入口里即可）：
-   - Web 示例：`端=Web；入口=/apply；...`
-   - Mobile 示例：`端=Mobile；入口=/m/execute；...`
-4. 对非页面能力，入口必须表明形态：
-   - Backend 示例：`端=Backend；入口=API；...`
-   - Job 示例：`端=Job；入口=cron；...`
-5. 输出自检（必须做）：检查 `core.md` 每一行都包含 `端=` 且值合法；若缺失必须补齐，不允许留空。
-
-Dashboard/工作台分析（必须）：
-1. 必须把“Dashboard/工作台”作为系统级核心能力纳入 `core.md`，不允许漏掉。
-2. 至少输出 1 行“工作台（Dashboard）”功能点，且必须为 Web 端：
-   - 模块建议：`工作台`（或 `Dashboard`）
-   - 说明开头必须包含：`端=Web；入口=/；`
-3. 工作台必须体现“不同角色看不同内容”，因此该行的“子功能”必须列出至少 3 类角色视角的差异点（示例）：
-   - 申请人：我发起的/草稿/待我补充/被驳回需要重提
-   - 审批人：待我审批/超时预警/一键通过与驳回入口（若适用）
-   - 执行人/司机：我的任务/今日任务/执行中/异常上报（并标注 `端=Mobile；入口=/m/...` 的移动端入口行）
-   - 管理员/调度：全量概览/资源占用/冲突与告警/快速分派
-4. 若 roles.md 中存在“更适合手机操作”的角色（司机/外勤/执行等），必须额外输出对应移动端 Dashboard/任务入口行：
-   - 说明开头使用：`端=Mobile；入口=/m/...；`

package/docs/commands.md

@@ -1,84 +0,0 @@
-## 命令总览
-
-| 命令 | 目的 | 主要输入 | 主要输出 |
-| --- | --- | --- | --- |
-| `/vspec:new` | 从原始需求生成基础规格产物 | 原始需求文本 + 交互问答 | `/specs/`（original、stakeholder、roles、terms、flows、scenarios、scenario_details、dependencies、functions、questions）+ 初始化 `/docs/*` 归档目录 |
-| `/vspec:refine` | 基于修订材料修订需求，并同步更新细节与原型 | `/docs/refine/*`（或命令参数）+ `/specs/background/original.md`（基线）+ `/specs/details/`（前置条件） | 追加写入 `/specs/background/original.md`（变更清单 + Canonical）+ 更新受影响 `/specs/details/` 与 `/specs/prototypes/` |
-| `/vspec:refine-q` | 基于 questions 的已回答内容修订需求 | `/specs/background/original.md` + `/specs/background/questions.md` | 追加写入 `/specs/background/original.md`（采纳条目 + 变更清单 + Canonical） |
-| `/vspec:verify` | 生成模型与原型，用于快速验证 | `/specs/` 产物 | `/specs/models/*.md`、`/specs/prototypes/`（Vue + Ant Design Vue 原型、场景确认页 `scenario.html`） |
-| `/vspec:detail` | 按功能点细化需求细节 | `/specs/functions/*` + 细节/模型/角色 | `/specs/details/<function_slug>/*`（权限/交互/校验/日志/通知/MQ/导入导出/定时任务等） |
-| `/vspec:accept` | 生成验收测试用例 | 功能/场景/细节/角色/模型 | `/specs/acceptance/<function_slug>/acceptance_cases.md`、`/specs/acceptance/index.md` |
-| `/vspec:test` | 生成自动化测试代码 | 验收用例 + 仓库既有测试框架 | 写入既有测试目录或 `/tests/` |
-| `/vspec:impl` | 生成前后端集成代码 | 规格/细节/模型/依赖 | 写入仓库源码（API、后端实现、前端页面与集成） |
-| `/vspec:upgrade` | 基于旧系统材料做升级改造分析并生成新规格 | `/docs/current/file_list.md` + `/docs/legacy/*`（可选 templates/texts/assets）+ 既有 `/specs/background/original.md`（如存在） | 按 `/vspec:new` 结构生成/更新 `/specs/` + 同步技术规格到 `/scheme.yaml` |
-| `/vspec:change` | 基于变更材料做影响分析并更新产物 | `/docs/change/*`（可选 file_list.md）+ 现有产物 `/specs/` | 更新相关文件（优先 `/specs/details/<module_slug>/`）+ `/specs/change_log.md`（更新前需 git 快照提交） |
-| `/vspec:qc` | 对 `/specs/` 产物做质量检查并输出不合格清单 | 内嵌标准 + 项目 `quality_standard.md`（可选） + `/specs/` | `/specs/qc_report.md` |
-| `/vspec:plan` | 估算与排期 | 功能/角色/流程/依赖/细节 | `/specs/plan_estimate.md`、`/specs/plan_schedule.html` |
-
-## `/vspec:new`
-
-- 使用场景：需求刚拿到、信息不完整，需要快速形成统一语言与初版规格
-- 输出重点：干系人/角色/术语/流程/场景/功能清单/待确认问题
-- 目录初始化：会在项目根目录初始化 `/docs/` 及其子目录（legacy/current/change/refine/templates/texts/assets），用于材料归档与后续命令读取
-
-## `/vspec:refine`
-
-- 使用场景：需求在开发/细化过程中出现补充与修订，需要在保留可追溯的前提下，更新“当前生效需求”并同步更新细节与原型
-- 输入来源：
-  - 默认读取：`/docs/refine/`（优先 `/docs/refine/file_list.md`；否则按文件名顺序）
-  - 可选：命令参数指定文件/目录（优先级更高）
-- 前置条件：必须已存在且非空的 `/specs/details/`，否则 refine 不执行（避免只有上游需求变了、下游细节不跟导致产物失配）
-- 输出重点：
-  - 在 `original.md` 末尾追加“变更清单 + 当前生效需求（Canonical）+ 影响分析与产物更新”
-  - 更新受影响的 `/specs/details/`（优先更新既有文件）与 `/specs/prototypes/`（最小可评审 diff）
-
-## `/vspec:refine-q`
-
-- 使用场景：业务已回答 `/specs/background/questions.md`，希望将已回答内容合并回需求并形成新的生效版本
-- 输出重点：采纳的问答条目 + 变更清单 + 当前生效需求（Canonical）
-
-## `/vspec:verify`
-
-- 使用场景：希望尽快验证数据结构与页面形态，降低理解偏差
-- 输出重点：数据模型文件（实体拆分）、可运行原型、场景确认页
-
-## `/vspec:detail`
-
-- 使用场景：进入方案设计/开发前，需要把“每个功能点”拆到可实现的细节级别
-- 输出重点：RBAC 到控件级、数据权限、加载/交互/校验矩阵、提交后处理、日志/通知矩阵、MQ、导入/导出、定时任务
-
-## `/vspec:accept`
-
-- 使用场景：准备验收与交付对齐，形成可执行的用例集合
-- 输出重点：按功能点组织的验收用例表，覆盖主流程/异常/边界/权限/数据权限
-
-## `/vspec:test`
-
-- 使用场景：需要把验收用例落地为可运行的自动化测试（E2E/API/单测）
-- 输出重点：复用仓库既有测试框架与脚本，不引入新依赖
-
-## `/vspec:impl`
-
-- 使用场景：需要把规格产物转为真实可运行的前后端联调代码
-- 输出重点：接口契约、后端实现、前端页面与 API 集成、权限与状态机落地
-
-## `/vspec:change`
-
-- 使用场景：需求发生明确变更，需要可追溯地更新产物并评估影响
-- 输入来源：读取 `/docs/change/` 下材料（可选 `/docs/change/file_list.md` 作为入口按顺序读取；兼容旧路径 `/docs/changes/`）
-- 更新策略：优先更新受影响模块的明细规格目录 `/specs/details/<module_slug>/`，并按需联动 models/functions/prototypes/acceptance
-- 更新前快照：若目标仓库是 git 仓库，写入任何更新前必须先提交一次快照，便于查看本次变更 diff
-- 输出重点：结构化变更清单、影响分析表、变更日志与对应产物更新
-
-## `/vspec:upgrade`
-
-- 使用场景：基于遗留系统材料做“升级改造/重构迁移”分析，从旧内容继承并生成新的规格产物
-- 入口清单：`/docs/current/file_list.md`（不存在则先生成模板），用于列出输入文件及用途、提取要点、是否必须
-- 输入范围：通常来自 `/docs/legacy/*` 与 `/docs/current/*`，可选结合 `/docs/templates/*`、`/docs/texts/*`、`/docs/assets/*`
-- 输出重点：复用 `/vspec:new` 的产物结构生成/更新 `/specs/`，并在功能清单中标注“继承/新增/调整/废弃”
-- 技术规格同步：从“系统技术规格”输入中抽取选型并写入 `/scheme.yaml`，用于后续 `/vspec:verify` 与 `/vspec:impl`
-
-## `/vspec:plan`
-
-- 使用场景：需要对齐交付节奏，按用户故事地图拆解并排期
-- 输出重点：故事拆分与估算（人天）、迭代计划、HTML 用户故事地图

package/docs/concepts.md

@@ -1,36 +0,0 @@
-## 设计理念
-
-### 1. 以产物驱动协作
-
-- 把“讨论”转化为“可评审产物”，减少口头对齐成本
-- 产物按层次递进：原始需求 → 规格（/specs）→ 模型（/specs/models）→ 原型（/specs/prototypes）→ 细节（/specs/details）→ 验收/测试/代码
-
-### 2. 场景化拆解，而不是功能堆砌
-
-- 场景使用节点组合（apply/approve/cancel/change/execute-start/execute-end 等）覆盖主流程与回退路径
-- 通过场景驱动细节：每个功能点最终都能落到“可执行的用户动作 + 可验证的期望结果”
-
-### 3. 权限与数据权限前置
-
-- RBAC 精确到页面区域与控件，避免“页面能看但按钮不该点”的灰区
-- 数据权限独立建模（行/列/范围/状态/组织），并与 RBAC 形成组合关系（先鉴权再过滤）
-
-### 4. 可实现的细节表达
-
-- 页面加载逻辑、交互逻辑、提交后处理都用步骤清单/表格输出，便于工程实现与评审
-- 校验、日志、通知等采用“矩阵形式”，保证覆盖完整、方便回溯与对齐
-
-### 5. 最终一致性与可观测性是默认能力
-
-- 对外部依赖、MQ、重试、DLQ、补偿等给出明确规格
-- 默认要求关键事件可追踪（trace_id/request_id）、可审计（操作日志）、可告警（失败与堆积）
-
-### 6. 从验收到自动化再到集成实现
-
-- 验收用例作为开发与测试共同语言
-- 自动化测试优先复用仓库既有框架与目录约定，减少维护成本
-- 生成代码强调最小可评审差异与可运行闭环
-
-### 7. 便于变更的需求文档
-
-- 生成的需求文档强调可编辑、可阅读、易发现问题、易修正，并能快速适配需求变更。

package/docs/installation.md

@@ -1,32 +0,0 @@
-## 安装到 Trae
-
-本仓库通过脚本把内置的 Skill 目录复制到你的 Trae 配置目录下。
-
-### 前置条件
-
-- Node.js >= 14
-
-### 安装/更新（推荐）
-
-在本仓库根目录执行：
-
-```bash
-node scripts/postinstall.cjs --force --target "$HOME"
-```
-
-说明：
-
-- `--target` 指定 Trae 配置目录的根路径；脚本会安装到：`<target>/.trae/skills/starter-skill`
-- `--force` 会先删除旧目录再覆盖安装
-
-### 验证
-
-确认目录存在：
-
-- `$HOME/.trae/skills/starter-skill`
-
-### 卸载
-
-删除目录即可：
-
-- `$HOME/.trae/skills/starter-skill`