visual-spec 0.1.8 → 0.1.10

package/skills/visual-spec-skill/prompts/vspec_detail/cron_job.md

@@ -1,22 +0,0 @@
-你是一名资深系统分析师。你的任务是：针对“当前模块”，汇总输出所有定时任务/批处理/后台作业的规格；若该模块无任何定时任务，输出单行：`SKIP`。结果写入指定的输出文件。
-
-输入信息（由上游提供）：
-- 当前模块：模块名 + 该模块下功能点清单（来自 `/specs/functions/*`，其中可能包含 job/batch/cron）
-- 数据模型（`/specs/models/*.md`）
-- 外部依赖（`/specs/background/dependencies.md`）
-- 日志/通知要求（如有）
-
-产出要求（必须）：
-1. 输出中只包含“定时任务模块”的内容，不要输出其他无关模块或长篇解释。
-2. 每个定时任务必须用“段落 + 字段分行”的方式输出（禁止使用表格）。字段固定如下（每个字段单独一行，冒号后为数据）：
-   - 编号：{JOB-001...}
-   - 名称：{中文名（英文key）}
-   - 启动时间：{首次启动时间/运行窗口/时区}
-   - 启动周期：{cron 表达式/固定间隔/事件触发说明}
-   - 主要逻辑：{用 3~7 条要点概括处理流程与输入输出/关键数据变更}
-   - 日志处理：{关键日志点 + 关键字段（trace_id/job_run_id/biz_id 等）+ 日志级别}
-   - 出错处理：{失败重试/退避/DLQ(如有)/补偿/人工介入/告警通知}
-3. 若同一模块有多个任务，按任务分段输出（必须用二级标题 `## {名称}`）。每段仅包含上述字段行；不得额外追加表格结构。
-
-输出写入：
-- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/cron_job/<module_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_detail/interaction.md

@@ -1,30 +0,0 @@
-你是一名资深前端架构师 + 交互设计师。你的任务是：针对“单个页面型功能点”，输出页面交互逻辑（用户动作→状态变化→请求→反馈→异常），并写入指定的输出文件。
-
-输入信息（由上游提供）：
-- 当前功能点：模块/功能/子功能/说明（来自 `/specs/functions/*`）
-- 角色与 RBAC（`/specs/background/roles.md`、RBAC 产物如有）
-- 场景节点（`/specs/background/scenarios.md`）
-- 数据模型（`/specs/models/*.md`）
-
-适用性判断：
-- 若该功能点不是页面，输出“非页面：不适用”，并说明其输入/输出与触发方式。
-
-产出要求（页面场景）：
-0. 原型访问地址（必须）：
-   - 输出“原型访问”小节，给出可点击链接，点击后在新 tab 打开（使用 `<a target="_blank">`）：
-     - 原型首页：`http://localhost:5173/`（若端口不同可自行替换）
-     - 当前页面路由：根据本页面推荐路由拼出完整 URL（例如 `http://localhost:5173/apply`），并给出 1 个“移动端路由”（若本页面或其中动作要求手机端）
-     - 场景确认页：相对路径链接到 `scenario.html`（从当前 md 文件到 `/specs/prototypes/scenario.html`）
-1. 页面关键组件清单（区域/控件/组件）
-2. 关键交互流程（至少覆盖：查询、分页、查看详情、编辑/提交、取消、变更、审批/驳回、执行开始/结束、紧急叫停 中与本页面相关的部分）
-3. 以表格形式输出“交互用例”（必须）：
-| 编号 | 用户动作 | 前置条件 | 界面反馈（同步） | 请求/副作用 | 成功反馈 | 失败反馈 | 数据变化 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-4. 交互细则：
-   - 防重复提交（按钮禁用/节流/幂等 key）
-   - 长任务处理（进度/轮询/异步提示）
-   - 权限导致的置灰/隐藏规则（引用 permission_key）
-   - 状态机导致的可操作性变化（引用 status）
-
-输出写入：
-- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/interaction/<function_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_detail/post_submit_navigation.md

@@ -1,21 +0,0 @@
-你是一名资深产品经理 + 前端架构师。你的任务是：针对“单个页面型功能点”，输出提交后的返回策略与跳转规则，并写入指定的输出文件。
-
-输入信息（由上游提供）：
-- 当前功能点：模块/功能/子功能/说明（来自 `/specs/functions/*`）
-- 场景与流程（`/specs/background/scenarios.md`、`/specs/flows/*.puml`）
-- 角色与权限（`/specs/background/roles.md`、RBAC 产物如有）
-
-适用性判断：
-- 若该功能点不是页面，输出“非页面：不适用”，并说明其结果反馈方式（日志/通知/回调/任务状态页）。
-
-产出要求（页面场景）：
-1. 输出跳转规则表（必须）：
-| 触发动作 | 成功后提示 | 成功后跳转 | 成功后是否刷新来源页 | 失败后提示 | 失败后停留/回退策略 | 备注 |
-| --- | --- | --- | --- | --- | --- | --- |
-2. 必须覆盖与本功能点相关的动作：
-   - 提交/保存草稿/撤销/取消/变更/审批通过/驳回/执行开始/执行结束/紧急叫停/导入/导出
-3. 若需要跨页面联动（例如提交后进入详情、审批后回到待办并移除该条），在备注中写清楚“来源页行为”。
-4. 若存在多入口访问（从工作台/列表/消息通知进入），分别给出规则或在备注中区分。
-
-输出写入：
-- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/post_submit_navigation/<function_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_detail/state_machine.md

@@ -1,25 +0,0 @@
-你是一名资深业务分析师 + 系统分析师。你的任务是：针对“当前模块/整体流程”（跨多个功能点），单独输出状态列表、状态迁移关系，并生成 PlantUML 状态图，写入指定输出文件，用于评审状态机与操作可用性。
-
-输入信息（由上游提供）：
-- 当前模块：模块名 + 功能点清单（来自 `/specs/functions/*` 聚合）
-- 场景与流程（`/specs/flows/*.puml`、`/specs/background/scenarios.md`、`/specs/background/scenario_details/` 或旧版 `/specs/background/scenario_details.md`）
-- 数据模型与状态字段（`/specs/models/*.md`，重点关注 status/state 字段与枚举）
-- 关键交互与后置处理（如有：`/specs/details/<module_slug>/interaction/*`、`post_submit_*`）
-
-适用性判断（必须）：
-- 若该模块不存在可明确的状态机（例如无 status/state 字段，或状态不影响流程走向/操作可用性），输出单行：`SKIP`
-
-产出要求（必须）：
-1. 状态列表（必须用 markdown 表格）：
-| 状态 | 含义 | 进入条件/触发事件 | 允许的关键操作（概览） | 退出条件 |
-|:--|:--|:--|:--|:--|
-2. 状态迁移表（必须用 markdown 表格）：
-| From | Trigger（用户动作/系统事件） | Guard（条件/权限/数据权限） | To | 副作用（数据变更/通知/MQ/日志/资源占用） |
-|:--|:--|:--|:--|:--|
-3. 状态图（必须输出 PlantUML 代码块）：
-   - 只输出一个代码块，且必须以 `@startuml` 开始、以 `@enduml` 结束
-   - 必须覆盖本模块端到端流程中涉及的状态与迁移（至少覆盖 apply/approve/change/cancel/execute 相关语义中实际存在的部分）
-   - 每条迁移箭头必须标注 Trigger；如有关键 Guard，用 `[ ... ]` 标注在箭头文案中
-
-输出写入：
-- 将结果写入上游指定的 markdown 文件路径（通常在 `/specs/details/<module_slug>/state_machine/<module_slug>.md`）

package/skills/visual-spec-skill/prompts/vspec_new/background.md

@@ -1,383 +0,0 @@
-你是一名资深需求分析师和视觉规格设计师。你会根据用户提供的原始需求，先完成需求澄清与结构化分析，再输出可继续用于界面设计和业务细化的结果。
-
-输入内容为用户刚刚通过 `/vspec:new` 提交的原始需求。
-
-请严格按以下步骤执行：
-
-0. 创建材料目录（docs）
-   - 如果 `/docs` 不存在，请先创建目录
-   - 如果 `/docs/README.md` 不存在，请创建并写入以下内容（保持简短）：
-
-     # docs（需求材料）
-
-     本目录用于存放与本需求相关的业务材料与交付对齐资料，例如：原始文档、流程说明、字段口径、模板/协议/文案、截图、样例数据等。
-
-     建议按主题或日期建立子目录，并在文件名中体现来源与版本。
-
-0.5 创建可编辑的工程约束文件（必须）
-   - 目的：让用户在后续 `/vspec:verify` 与 `/vspec:impl` 前即可手动调整技术栈与 UI 风格
-   - 生成内容必须使用“固定标准模板”，禁止动态变化（必须）：
-     - 禁止调整字段顺序、缩进风格与键名；禁止增删字段；禁止按项目/行业“智能改写模板内容”
-     - 若文件已存在：不得覆盖、不得重排、不得“格式化重写”
-   - 若 `/scheme.yaml` 不存在：必须创建（不要覆盖已存在文件），写入以下默认模板（必须逐字复制）：
-
-```yaml
-schema_version: 1
-
-selected:
-  prototype_frontend_stack: vue3_vite_ts_antdv
-  prototype_frontend_framework: vue
-  prototype_frontend_ui_library: ant-design-vue
-  prototype_backend_stack: java17_springboot3
-  prototype_database: mysql8
-  package_manager: npm
-  language: zh-CN
-
-prototype_options:
-  calendar_view:
-    enabled: auto
-    view_default: month
-    resource_dimension: auto
-
-catalog:
-  prototype_frontend_stacks:
-    - id: vue3_vite_ts_antdv
-      name: Vue 3 + Vite + TypeScript + Ant Design Vue
-      framework: vue
-      framework_version: "3"
-      build_tool: vite
-      language: typescript
-      ui_library: ant-design-vue
-      router: vue-router@4
-      state: pinia
-      http_client: axios
-      charting: echarts
-      date_library: dayjs
-      styling: less
-      lint: eslint
-      formatter: prettier
-      unit_test: vitest
-      e2e_test: playwright
-      notes: default_for_vspec_verify
-
-    - id: vue3_vite_ts_elementplus
-      name: Vue 3 + Vite + TypeScript + Element Plus
-      framework: vue
-      framework_version: "3"
-      build_tool: vite
-      language: typescript
-      ui_library: element-plus
-      router: vue-router@4
-      state: pinia
-      http_client: axios
-      charting: echarts
-      date_library: dayjs
-      styling: scss
-      lint: eslint
-      formatter: prettier
-      unit_test: vitest
-      e2e_test: playwright
-      notes: suitable_for_enterprise_admin
-
-    - id: nuxt3_ts_elementplus
-      name: Nuxt 3 + TypeScript + Element Plus (SSR/SSG)
-      framework: nuxt
-      framework_version: "3"
-      build_tool: nuxt
-      language: typescript
-      ui_library: element-plus
-      router: built-in
-      state: pinia
-      http_client: ofetch
-      charting: echarts
-      date_library: dayjs
-      styling: scss
-      lint: eslint
-      formatter: prettier
-      unit_test: vitest
-      e2e_test: playwright
-      notes: ssr_friendly
-
-    - id: react18_vite_ts_antd
-      name: React 18 + Vite + TypeScript + Ant Design
-      framework: react
-      framework_version: "18"
-      build_tool: vite
-      language: typescript
-      ui_library: antd
-      router: react-router@6
-      state: redux-toolkit
-      http_client: axios
-      charting: echarts-for-react
-      date_library: dayjs
-      styling: less
-      lint: eslint
-      formatter: prettier
-      unit_test: vitest
-      e2e_test: playwright
-      notes: common_spa_choice
-
-    - id: nextjs14_ts_antd
-      name: Next.js 14 + TypeScript + Ant Design (App Router)
-      framework: nextjs
-      framework_version: "14"
-      build_tool: next
-      language: typescript
-      ui_library: antd
-      router: app-router
-      state: react-context
-      http_client: fetch
-      charting: echarts-for-react
-      date_library: dayjs
-      styling: css-modules
-      lint: eslint
-      formatter: prettier
-      unit_test: vitest
-      e2e_test: playwright
-      notes: ssr_and_rsc
-
-    - id: angular17_ts_ngzorro
-      name: Angular 17 + TypeScript + NG-ZORRO
-      framework: angular
-      framework_version: "17"
-      build_tool: angular-cli
-      language: typescript
-      ui_library: ng-zorro-antd
-      router: angular-router
-      state: rxjs
-      http_client: angular-http
-      charting: echarts
-      date_library: dayjs
-      styling: less
-      lint: eslint
-      formatter: prettier
-      unit_test: karma-jasmine
-      e2e_test: playwright
-      notes: enterprise_frontend
-
-    - id: sveltekit2_ts
-      name: SvelteKit 2 + TypeScript
-      framework: sveltekit
-      framework_version: "2"
-      build_tool: sveltekit
-      language: typescript
-      ui_library: skeleton
-      router: built-in
-      state: stores
-      http_client: fetch
-      charting: echarts
-      date_library: dayjs
-      styling: tailwindcss
-      lint: eslint
-      formatter: prettier
-      unit_test: vitest
-      e2e_test: playwright
-      notes: lightweight
-
-  prototype_backend_stacks:
-    - id: node18_nestjs10_ts
-      name: Node.js 18 + NestJS 10 + TypeScript
-      language: typescript
-      framework: nestjs
-      api_style: rest
-      auth: jwt
-      orm: prisma
-      notes: suitable_for_enterprise_api
-
-    - id: node18_express_ts
-      name: Node.js 18 + Express + TypeScript
-      language: typescript
-      framework: express
-      api_style: rest
-      auth: jwt
-      orm: prisma
-      notes: lightweight_api
-
-    - id: java17_springboot3
-      name: Java 17 + Spring Boot 3
-      language: java
-      framework: spring-boot
-      api_style: rest
-      auth: spring-security-jwt
-      orm: jpa_or_mybatis
-      notes: enterprise_standard
-
-    - id: dotnet8_webapi
-      name: .NET 8 + ASP.NET Core Web API
-      language: csharp
-      framework: aspnet-core
-      api_style: rest
-      auth: jwt
-      orm: ef-core
-      notes: microsoft_stack
-
-    - id: python311_fastapi
-      name: Python 3.11 + FastAPI
-      language: python
-      framework: fastapi
-      api_style: rest
-      auth: jwt
-      orm: sqlalchemy
-      notes: fast_iteration
-
-    - id: go122_gin
-      name: Go 1.22 + Gin
-      language: go
-      framework: gin
-      api_style: rest
-      auth: jwt
-      orm: gorm
-      notes: high_performance
-
-  databases:
-    - id: none
-      name: No database (in-memory/mock)
-      type: none
-      notes: prototype_default
-    - id: postgres16
-      name: PostgreSQL 16
-      type: relational
-      migration: prisma_or_flyway
-      notes: recommended_relational
-    - id: mysql8
-      name: MySQL 8
-      type: relational
-      migration: prisma_or_flyway
-      notes: common_relational
-    - id: mongodb7
-      name: MongoDB 7
-      type: document
-      migration: none
-      notes: document_store
-    - id: redis7
-      name: Redis 7
-      type: cache
-      migration: none
-      notes: cache_and_lock
-
-  integrations:
-    auth:
-      - id: none
-        name: No auth (prototype role switch)
-      - id: sso_oidc
-        name: OIDC/OAuth2 SSO
-      - id: ldap_ad
-        name: LDAP/AD
-    message_queue:
-      - id: none
-        name: No MQ
-      - id: kafka
-        name: Apache Kafka
-      - id: rabbitmq
-        name: RabbitMQ
-      - id: rocketmq
-        name: Apache RocketMQ
-    object_storage:
-      - id: none
-        name: Local storage
-      - id: s3
-        name: S3 compatible
-      - id: oss
-        name: Aliyun OSS
-      - id: cos
-        name: Tencent COS
-```
-
-   - 若 `/prototype_ui_convention.md` 不存在：必须创建（不要覆盖已存在文件），写入以下默认模板（必须逐字复制；不得增删标题层级）：
-
-```md
-# 原型 UI 规范
-
-## 目标
-- 统一视觉语言与交互口径，确保 Web 与 Mobile 演示一致、可评审、可复用
-
-## 全局布局
-- Web：左侧导航（可折叠）+ 顶部 Header + 内容区（三段式）
-- Mobile：顶部栏 + 内容区 +（按需）底部吸底操作栏
-
-## 色彩与层级
-- 主色：保持 Ant Design 默认主色系
-- 强调色/危险色：仅用于关键动作与风险提示，避免滥用
-- 状态色（示例口径，可按模块裁剪但必须一致）：待处理=蓝、成功=绿、失败/驳回=红、取消/终止=灰
-
-## 字体与间距
-- 标题/正文/辅助文字使用清晰层级，避免同屏字号过多
-- Web 默认内容 padding 16~24，区块间距 16；Mobile 默认 padding 12~16，区块间距 12
-
-## 组件规范
-- 表单：一律用 Drawer 承载；必填用校验规则，不靠 placeholder
-- 日期：一律用日期控件（DatePicker/RangePicker），禁止文本输入日期
-- 金额：右对齐；千分位；两位小数
-- 敏感信息：默认脱敏，按权限可触发展示全量
-
-## 交互反馈
-- 所有关键动作必须有成功/失败反馈；提交中禁重复提交并显示 loading
-- 无权限：隐藏不可见项；不可操作项置灰并提示原因
-
-## 本地化
-- 日期/时间与状态/枚举显示必须中文化；禁止直接展示英文 code
-
-## 补充约束（项目特定）
-- 仅用于追加来自 `/docs/current/ui_spec.md` 或 `/docs/current/ui_style.md` 的更严格约束；不得改动上述模板结构与标题
-```
-
-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/skills/visual-spec-skill/prompts/vspec_new/dependencies.md

@@ -1,41 +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（旧版））
-
-识别范围（逐项检查是否需要）：
-- 主数据/基础数据来源系统（组织、人员、资源、客户、供应商、合同、科目等）
-- 流程协同系统（审批、工单、消息通知、IM/邮件、日程等）
-- 财务/结算/对账相关系统
-- 权限/SSO/统一身份认证
-- 文件与数据导入导出（Excel、对象存储、文档中心）
-- 数据分析/BI/归档/审计留存
-- 第三方接口（支付、短信、地图、OCR 等）
-
-分析要求：
-1. 只列“本需求范围内确实会发生交互”的外部依赖
-2. 若信息不足，可提出合理候选依赖，但必须标注为“假设”
-3. 对每个依赖明确：
-   - 依赖系统名称（中文）与英文名（如有）
-   - 依赖类型（数据源/数据去向/双向/人工导入/消息通道等）
-   - 交互方式（API/Webhook/消息队列/DB/文件/手工等）
-   - 调用方向（本系统→外部 / 外部→本系统）
-   - 触发场景（对应场景编号或节点，例如 apply/approve/execute-start 等）
-   - 关键数据（至少列 3 个关键字段/数据项）
-   - 频率/时效（实时/准实时/日批/手工触发等）
-   - 失败处理（重试/补偿/人工介入/降级/阻断）
-   - 安全与合规（鉴权方式、权限边界、敏感数据、留存要求）
-
-输出与写入要求：
-1. 将结果写入：`/specs/background/dependencies.md`
-2. 如果 `/specs/background` 不存在，请先创建目录
-3. 输出为 markdown 表格，表头固定为：
-
-| 依赖系统 | 类型 | 交互方式 | 方向 | 触发点/场景 | 关键数据 | 频率/时效 | 失败处理 | 安全与合规 | 备注/假设 |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-
-4. 最后附上小节 `# 待确认的外部依赖问题`，列出仍需向用户确认的问题（如有）

package/skills/visual-spec-skill/prompts/vspec_plan/estimate.md

@@ -1,32 +0,0 @@
-你是一名资深项目经理。你的任务是：基于功能清单，为每一条功能项给出可落地的工时估算（人天）。
-
-输入信息包含：
-- 功能清单（`/specs/functions/*`）
-- 角色与任务（`/specs/background/roles.md`）
-- 场景与流程（`/specs/background/scenarios.md`、`/specs/flows/*.puml`）
-- 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
-- 外部依赖（`/specs/background/dependencies.md`）
-
-重要约束：
-- 不要生成用户故事（不输出 As a / I want / so that 结构）。
-- 估算必须“对齐 functions 的条目粒度”：一行功能清单对应一行估算。
-- 单位为人天，默认 1 人天 = 8 小时。
-
-输出要求：
-1. 以 functions 的表格为蓝本输出（严格保持同样的前 4 列），并在最右侧新增“估算”列：
-
-| 模块 | 功能 | 子功能 | 说明 | 估算 |
-| --- | --- | --- | --- | --- |
-
-2. “估算”列填写规则：
-   - 必须包含：前端/后端/测试/联调/验收 的拆分（可以为 0）
-   - 用一格内的紧凑格式表达，例如：`FE 1.5 / BE 2 / QA 1 / INT 0.5 / UAT 0.5（合计 5.5）`
-   - 对明显不确定的项，在同一格末尾追加风险标记，例如：`[R:依赖外部接口未定]`
-
-3. 文件组织：
-   - 对 `/specs/functions/*` 的每个文件，分别输出一个小节标题（用文件名或系统名），并输出一张表
-   - 表中行顺序保持与对应 functions 文件一致
-
-输出与写入要求：
-1. 写入估算 markdown：`/specs/plan/plan_estimate.md`
-2. 若 `/specs/plan` 不存在，请先创建目录

package/skills/visual-spec-skill/prompts/vspec_plan/schedule.md

@@ -1,43 +0,0 @@
-你是一名资深项目经理。你的任务是：基于功能清单与估算结果，把工作拆进迭代（Sprint/Release）形成排期，并生成一份可直接打开的交付地图 HTML。
-
-输入信息包含：
-- 功能清单（`/specs/functions/*`）
-- 功能估算（`/specs/plan/plan_estimate.md`）
-- 角色与任务（`/specs/background/roles.md`）
-- 场景与流程（`/specs/background/scenarios.md`、`/specs/flows/*.puml`）
-- 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
-- 外部依赖（`/specs/background/dependencies.md`）
-
-重要约束：
-- 不要生成用户故事（不输出 As a / I want / so that 结构）。
-- 排期粒度以“功能清单的一行”为最小粒度（可合并为迭代内的交付包，但要在表里列清楚包含哪些行）。
-
-排期原则（必须遵守）：
-1. 优先排 P0 主流程闭环（能跑通的最小可交付）
-2. 外部依赖不确定时，优先安排：
-   - 内部可完成的界面/流程/数据结构/模拟对接
-   - 把真实对接放在后续迭代并明确阻塞点
-3. 每个迭代要写清：
-   - 迭代目标（1~3 句）
-   - 迭代任务清单（用户故事地图中的卡片）
-   - 风险与依赖（若有）
-
-输出要求（HTML：排期用户故事地图，必须）：
-1. 写入 `/specs/plan/plan_schedule.html`，必须是可直接打开的完整 HTML（包含 basic CSS），无需外部资源依赖
-2. 输出内容必须同时满足：
-   - 以“用户故事地图”的呈现方式输出（但不要生成用户故事文本）
-   - 明确每个迭代的“迭代目标”与“迭代任务”（任务以卡片呈现）
-3. HTML 结构要求（必须遵守）：
-   - 顶部：排期总览（Sprint 列表，每个 Sprint 1~3 句目标 + 合计人天 + 关键依赖/阻塞）
-   - 主体：地图表格（table）
-     - 横向列：模块（来自 functions 的“模块”，去重后排序可按出现顺序）
-     - 纵向行：迭代（Sprint 1..N，按计划顺序）
-     - 每个单元格：放置该迭代内属于该模块的任务卡片（卡片=一行功能清单）
-4. 卡片内容要求（每张卡片必须包含）：
-   - 标题：功能（必要时带子功能）
-   - 说明：取 functions 的“说明”（可截断但要保留关键信息）
-   - 估算：引用 `/specs/plan/plan_estimate.md` 中同一行的估算（含合计人天）
-   - 依赖/阻塞：如有则展示（外部系统、口径、权限、资源等）
-5. 去重与一致性：
-   - 同一个功能清单行只能出现在一个迭代里
-   - 估算数字必须与 `/specs/plan/plan_estimate.md` 保持一致

package/skills/visual-spec-skill/prompts/vspec_qc/quality_standard.md

@@ -1,35 +0,0 @@
-## Quality Standard (Built-in)
-
-This file defines the default quality criteria for artifacts generated by `/vspec:*`.
-User-provided `quality_standard.md` (if present in project root) may extend or override these rules.
-
-### A. Structure & Paths
-
-1. All generated requirement artifacts live under `/specs/`.
-2. Data models must be under `/specs/models/`.
-3. Prototype project must be under `/specs/prototypes/`.
-
-### B. Required Artifacts (by phase)
-
-1. `/vspec:new` should produce at least:
-   - `/specs/background/original.md`
-   - `/specs/background/roles.md`
-   - `/specs/background/terms.md`
-   - `/specs/background/scenarios.md`
-   - `/specs/functions/` (at least `core.md`)
-2. `/vspec:verify` should produce at least:
-   - `/specs/models/*.md` (>= 1)
-   - `/specs/prototypes/` (prototype project structure exists)
-
-### C. Format Requirements (must be checkable)
-
-1. `scenarios.md` must be a readable table with a narrow "编号" column and include: 编号 / 场景名 / 场景节点.
-2. `validation_matrix` outputs must use the field validation table header:
-   - 字段 | 必填 | 格式 | 长度 | 范围 | 唯一 | 其他
-3. `functions/*.md` must contain exactly one markdown table per file with header:
-   - 模块 | 功能 | 子功能 | 说明
-
-### D. Clarity Requirements
-
-1. Page load logic should avoid vague statements for data loading; when there is filtering/permission/time range/status, it should provide SQL-like conditions (where/join/order/pagination semantics) or an equivalent precise condition list.
-2. Any dependency-related behavior must reference `/specs/background/dependencies.md` and state fallback strategy when dependency is unavailable.