skyroc-admin-prd-prototype

name	skyroc-admin-prd-prototype
description	为 Skyroc Admin / RuoYi Plus Fast 模块编写来源可追溯的 PRD，并生成可独立打开、可交互、经过桌面端和移动端验收的 HTML 设计原型。仅在用户明确要求使用本 Skill 时启用。

Skyroc Admin PRD 与 HTML 原型

本 Skill 用于把当前 FastAPI 契约、React 实现、仓库设计规范以及可用的历史或外部参考整理成一套可实施的 PRD，并为每个真实页面生成独立 HTML 原型。

不要把历史接口、字段或权限字符当作永久事实。每次任务都必须重新读取当前源码。

适用范围

在用户明确说出以下任一表达时使用本 Skill：

• “使用 skyroc-admin-prd-prototype”
• “按 Skyroc Admin PRD 原型 Skill 做”
• “用之前那套 PRD 和 HTML 设计流程”且明确指向本 Skill

典型任务包括：

• 为一个管理模块编写 PRD。
• 判断模块需要拆成几个页面。
• 生成一个或多个独立 HTML 设计图。
• 在已有 PRD 或原型基础上继续设计。
• 对照当前 FastAPI、React 实现和可用参考资料修订设计。

本 Skill 不负责把 HTML 原型直接改造成生产 React 页面，除非用户同时明确要求实施前端功能。

默认交付物

没有另行指定时，交付：

1. 一份 Markdown PRD。
2. 每个真实页面一份独立的 index.html。
3. 必要的桌面端和移动端验收截图。
4. 一份简短验收结论，区分已验证内容和未验证内容。

默认路径：

design/ruoyi-plus-fast/pages/<domain>/<module>.md
design/ruoyi-plus-fast/prototypes/<page-slug>/index.html
design/ruoyi-plus-fast/prototypes/<page-slug>/qa/*.png

如果相邻模块使用不同目录层级，沿用相邻模块，不为统一路径而搬动旧文件。

必须读取的资料

开始设计前，完整执行 证据读取顺序。至少确认：

• 当前设计系统和信息架构。
• 至少一个业务形态相近的 PRD 和一个视觉或交互形态相近的原型；需要比较设计模式时再读取两个以上样例。
• FastAPI 当前 routes、schemas、service/use case、权限，以及与当前模块直接相关的测试或接口文档。
• 当前 React 路由、页面、API 类型与请求封装（如果已经存在）。
• 用户提供或仓库中确实存在的历史、外部参考实现（如果有）。

用户给出的路径优先于默认路径。路径不存在时，先在相邻仓库中搜索实际位置，不要直接向用户索要可自行发现的信息。

工作流

1. 明确架构和事实边界

在动手写文件前，用简短说明明确：

• 模块解决什么问题。
• 前端、后端、基础设施各自负责什么。
• 哪些是当前源码确认的事实。
• 哪些是为了补齐体验提出的设计假设。
• 哪些能力当前不存在，原型不得伪装成已经对接。

创建一份内部事实表，至少包含：

证据	已确认能力	缺口或冲突	对设计的影响
当前 FastAPI
当前 React
设计系统和旧原型
可选参考资料

遇到冲突时，以当前目标系统的真实后端契约为实现事实；历史或外部参考只用于理解业务边界和比较设计方案。不要为了视觉一致而虚构接口。

2. 决定页面数量

按照任务目标而不是参考页面的文件数量拆分页面：

• 不同菜单入口、权限边界、用户角色或长期工作区通常是独立页面。
• 新增、编辑、详情、确认等短任务通常使用抽屉或弹窗。
• 用户明确要求两个页面时，必须生成两个能独立打开的 HTML 文件；不能用一个页面里的 Tab 或状态切换冒充两个页面。
• 独立页面之间需要真实导航关系时，使用相对链接互相跳转。

在 PRD 中先给出页面清单、页面 ID、路由、使用者和边界，再展开页面细节。

3. 编写 PRD

以 PRD 产物规范 为准，并从 PRD 模板 起草。

PRD 必须做到：

• 来源可追溯，事实与假设分开。
• 页面结构、字段、表格列、筛选、状态和交互足够具体。
• 接口、权限、错误、空状态、并发和危险操作有明确设计。
• 同时说明桌面端和窄屏行为。
• 明确原型与当前生产实现之间的差距。

4. 生成独立 HTML 原型

以 HTML 原型规范 为准。

优先参考当前仓库中的黄金样例：

• design/ruoyi-plus-fast/prototypes/user/index.html
• design/ruoyi-plus-fast/prototypes/role/index.html
• design/ruoyi-plus-fast/prototypes/menu-final/index.html
• design/ruoyi-plus-fast/prototypes/oss/index.html
• design/ruoyi-plus-fast/prototypes/oss-config/index.html

黄金样例用于理解布局、层级、信息密度和交互质量，不是复制固定业务内容。新页面应保持同一产品家族感，同时让业务特征决定局部布局。

可以从 后台页面骨架 起步。交付前必须替换模板占位内容，并删除未使用的演示结构。

5. 验收

完整执行 验收清单。最低要求：

1. 使用 Oxfmt 检查 PRD 和 HTML。
2. 使用本 Skill 的静态检查脚本检查每个原型。
3. 启动本地静态服务，通过浏览器访问，不只使用文件预览。
4. 分别检查桌面、窄屏和手机宽度。
5. 点击查询、重置、新增、编辑、详情、危险操作、关闭浮层等主要交互。
6. 检查浏览器控制台错误和页面横向溢出。
7. 截取能证明主页面、关键浮层和移动端状态的图片。

静态检查命令示例：

node .agents/skills/skyroc-admin-prd-prototype/scripts/verify-prototypes.mjs \
  design/ruoyi-plus-fast/prototypes/example-a \
  design/ruoyi-plus-fast/prototypes/example-b

不可妥协的规则

• 不复制旧 PRD 中可能已经过期的接口事实。
• 不把历史或外部参考行为描述成 FastAPI 已实现行为。
• 不把静态 HTML 描述成已经完成后端联调。
• 不用 Tab 冒充用户要求的多个页面。
• 不把所有业务塞进一个超长弹窗。
• 不生成只有视觉、没有关键点击反馈的“截图式页面”。
• 不使用外部图标 CDN 作为关键依赖；优先内联 SVG。
• 不在原型中写入真实密钥、Token、个人信息或生产地址。
• 不因制作原型而修改当前 React 生产代码，除非用户明确要求。

完成报告

最终只需要说明：

1. PRD 和页面数量。
2. 每个页面的主要内容和关键交互。
3. 生成文件的绝对路径。
4. 执行过的格式、静态和浏览器验证。
5. 当前仍属于设计假设或尚未真实联调的部分。