SKILL.md 18 KB
name: prd-generator-from-demo
description: Generate and incrementally update detailed Chinese PRD documents for any business domain from incomplete requirement notes, frontend or mobile prototypes, admin or backend demos, screenshots, existing API docs, config tables, dictionary tables, mock data, or static JSON. Use when Codex must reverse-engineer and complete a development-ready and testable PRD from prototypes and fragmented materials, or revise an existing PRD after prototypes change, with page display rules, backend/admin configuration rules, API fields, button interactions, validation, edge cases, flow diagrams, and open questions.
PRD Generator From Demo
Objective
Generate a detailed Chinese product requirements document from fragmented inputs for any business domain. The output must be concrete enough for frontend, backend, QA, and product stakeholders to split work, implement, and test.
Do not merely polish an existing PRD. Infer and complete missing page structure, fields, states, interactions, admin rules, API contracts, field mappings, edge cases, and unresolved questions from the provided materials.
This skill is domain-neutral. Do not assume a specific industry, product type, tenant, channel, or business vocabulary unless it appears in the user's materials. Preserve the user's domain terms and infer only from visible prototypes, supplied requirements, code, screenshots, APIs, and data files.
Input Materials
Accept any combination of the following materials from any project:
- Incomplete requirement notes, partial PRDs, business remarks, or unclear field and rule descriptions.
- Frontend or mobile prototype materials, including HTML demos, app page code, screenshots, prototypes, or runnable projects.
- Admin, backend, or management-console demo materials, including HTML files, generated admin projects, React/Vue/HTML/CSS/JS code, screenshots, prototypes, or runnable pages.
- Existing API documentation.
- Screenshots, prototype images, old requirement documents, test cases, configuration tables, dictionary tables, mock data, static JSON, or page notes.
When reading demos, identify page structure, modules, fields, buttons, states, display rules, interaction behavior, validation, permissions, persistence rules, mobile impact, and edge cases.
If the product is not mobile-first, replace "移动端" in the output with the actual user-facing channel, such as "前台", "Web端", "小程序端", "App端", "H5端", or another channel found in the materials.
Source Priority
When materials conflict, apply this priority:
- Incomplete requirement description
- Existing API documentation
- Admin/backend demo
- Frontend/mobile prototype
- Mock data or static data
- Reasonable inference
Follow these conflict rules:
- If requirement notes and demos conflict, keep both signals and mark the issue as a "疑似冲突点".
- If API docs and page fields differ, prefer the API docs and list the difference under "待确认问题".
- If demos contain fields, buttons, or modules that are missing from requirement notes, add them to the PRD.
- If information cannot be determined, do not pretend it is certain. Put it under "待确认问题".
Writing Rules
- Write the final PRD in Chinese.
- Use product manager requirement-document language.
- Do not write generic background, goals, project value, or market analysis.
- Avoid vague wording such as "根据实际情况", "按需展示", or "相关数据".
- Explain every field's source, purpose, display rule, interaction rule, and exception rule.
- Explain every button's click behavior, permission control, secondary confirmation, success message, and failure message.
- Make rules specific, developable, and testable.
- Clearly mark inferred content and explain the basis for inference.
- Mark virtual APIs as "【虚拟接口，待技术确认】".
- When designing virtual APIs, use Chinese interface names and Chinese field names. Do not use English, pinyin, camelCase, snake_case, or technical placeholder names for virtual API fields.
- If an existing API document uses English field names, preserve the original technical field names, but add Chinese field meanings so product, business, and testing readers can understand them.
- Do not make the PRD read like a stack of tables. For each module, page, API, rule set, and diagram, first write a short natural-language explanation of what it does, when it applies, and what the key rule is. Then use tables only for dense field-level details, mappings, validation lists, and button inventories.
- Write in a human product-document style: use complete sentences, explicit cause-and-effect rules, and short paragraphs before tables. Avoid table-only sections unless the content is purely an inventory.
Generation Workflow
Use this workflow when creating a PRD for the first time:
- Inventory all input materials and identify their type.
- Extract user-facing page modules from top to bottom, using the actual channel name from the materials.
- Extract admin pages, filters, lists, dialogs, fields, buttons, validation, permissions, and persistence rules.
- Extract existing API names and fields. Reuse them exactly when available.
- If dynamic data is required but no API exists, design virtual APIs with Chinese interface names and Chinese field names, and mark them as pending technical confirmation.
- Build frontend-admin field mappings.
- Add business flow, swimlane, state-transition, or sequence diagrams when the requirement contains frontend-admin linkage, API call chains, state transitions, publish/enable/disable flows, multiple roles, or complex user paths.
- Collect suspected conflicts, unclear rules, missing fields, and technical assumptions into "待确认问题".
Incremental Update Workflow
Use this workflow when the user provides an existing PRD plus changed frontend/mobile, backend/admin, or management-console prototypes.
- Read the existing PRD first and preserve its section structure, numbering style, terminology, confirmed decisions, and table formats.
- Inspect the current frontend/mobile prototype and backend/admin prototype. Compare them against the existing PRD and identify only changed, added, deleted, or behaviorally affected items.
- Update only impacted sections. Do not rewrite unrelated modules, do not rename stable fields, and do not reorder stable content unless the prototype structure itself changed.
- For every change, update all directly affected places:
- Frontend/mobile module description, display rules, field table, interaction rules, state rules, and edge cases.
- Backend/admin page description, filter/list/form fields, button rules, validation rules, popup prompts, permissions, and edge cases.
- API field descriptions or virtual APIs.
- Frontend-admin field mapping table.
- Mermaid flow diagrams.
- Pending questions.
- If a prototype removes a field, button, or module, mark the removal clearly and delete or update the corresponding requirement only when the removal is evident from the new prototype. If uncertain, keep the existing requirement and add a pending question.
- If a prototype adds a field but the source is unclear, add the field with the most likely source marked as inferred and create a pending question.
- If behavior changes are visible but the persistence/API impact is unclear, update visible behavior and add a pending technical question.
- Add a short "本次更新说明" section at the top of the output when performing an incremental update. Include changed prototype source, changed modules, updated sections, and pending confirmation items.
Use this table for the incremental update summary:
| 更新项 | 变更来源 | 影响页面/模块 | 已更新章节 | 是否存在待确认 |
|---|
When returning an updated PRD, include either the full updated document or a patch-style section replacement, depending on the user's request. If the user does not specify, provide the full updated document when the document is short; provide section-level replacements when the document is long.
Output Structure
Generate the PRD with the following sections.
一、需求范围说明
State the covered pages, modules, admin configuration scope, and API scope. Do not write background or goals.
二、功能范围与模块结构
This section must only include the structural information needed before detailed requirements. Do not add a separate feature inventory, summary table, background, goals, or value analysis.
2.1 前台/移动端模块结构
Use the actual user-facing channel name from the materials. Describe the user-facing modules in their actual display or operation order, and explain what each module is responsible for. Do not only list visual areas; include the business meaning of each module.
Examples:
- 顶部展示区
- 用户信息区
- 权益列表区
- 活动轮播区
- 底部按钮区
2.2 后台/管理端配置结构
List backend/admin/management-console modules by configuration responsibility. Explain which frontend/mobile modules they control, not only where they appear in the admin page.
Examples:
- 菜单入口
- 查询筛选区
- 列表区
- 新增/编辑弹窗
- 配置项区域
- 上传区域
- 排序区域
- 操作按钮区
2.3 前后台关系概览
Briefly explain only the necessary relationship between frontend/mobile display, backend/admin configuration, API data, and user actions. Keep this section concise because the detailed field mapping table appears later in the PRD.
Use this table when applicable:
| 前台/移动端模块 | 后台/管理端配置 | 依赖接口 | 用户操作影响 | 说明 |
|---|
三、前台/移动端功能详细说明
Use the actual user-facing channel name from the materials. Write one module at a time. Use this structure for each module:
3.x 模块名称
3.x.1 模块说明
Describe the module position, purpose, and display conditions.
3.x.2 展示规则
Explain when the module is shown or hidden, whether it is controlled by admin configuration, and whether it is controlled by API state.
3.x.3 字段说明
Use this table:
| 字段/元素 | 类型 | 展示位置 | 数据来源 | 来源说明 | 展示规则 | 交互规则 | 异常规则 |
|---|
Only use one of these data source values:
- 写死
- 后台配置
- 接口获取
- 前端计算
- 用户操作产生
- 系统默认
For data source explanations:
- 写死: describe the fixed copy or fixed rule.
- 后台配置: name the corresponding admin configuration field.
- 接口获取: name the API, field name, and Chinese field meaning.
- 前端计算: describe the formula and dependent fields.
- 用户操作产生: describe the user action source.
- 系统默认: describe the default value and effective scenario.
3.x.4 交互规则
Explain clicks, jumps, expand/collapse, popups, copy actions, submit actions, return behavior, refresh behavior, and any other interactions.
3.x.5 状态规则
If the module has state branches, use this table:
| 状态值 | 状态含义 | 展示文案 | 展示样式 | 可操作按钮 | 规则说明 |
|---|
3.x.6 异常、空数据和边界规则
Describe empty fields, API errors, API timeouts, image load failures, unknown states, user ineligibility, and other boundaries.
四、后台/管理端功能详细说明
Write backend/admin/management-console requirements by page, area, field, button, validation, and boundary.
4.x 后台页面名称
4.x.1 页面入口
Describe menu path, page name, and page purpose.
4.x.2 查询筛选区
Describe filter fields, default values, reset support, fuzzy search support, and relationships between filters.
Use this table:
| 字段名称 | 字段类型 | 是否必填 | 默认值 | 数据来源 | 查询规则 | 校验规则 | 说明 |
|---|
4.x.3 列表区
Describe list fields, sorting rules, pagination, empty display, and operation column.
Use this table:
| 列表字段 | 字段类型 | 数据来源 | 展示规则 | 排序规则 | 空值规则 | 说明 |
|---|
4.x.4 新增/编辑弹窗或配置表单
Describe field differences for create, edit, and view modes, echo rules, and save rules.
Use this table:
| 字段名称 | 字段类型 | 是否必填 | 默认值 | 数据来源 | 配置用途 | 校验规则 | 前台/移动端影响 |
|---|
Common field types include:
- 文本输入框
- 数字输入框
- 文本域
- 单选框
- 多选框
- 下拉选择
- 开关
- 日期选择
- 时间选择
- 图片上传
- 文件上传
- 富文本编辑器
- 颜色选择器
- 排序输入框
- 表格配置
- 字典选择
- 枚举选择
4.x.5 按钮说明
Explain every admin button. Repeated buttons may be described once under common button rules and referenced in specific modules.
Use this table:
| 按钮名称 | 出现场景 | 操作对象 | 点击后行为 | 权限控制 | 二次确认 | 成功提示 | 失败提示 |
|---|
Common buttons include:
- 查询
- 重置
- 新增
- 编辑
- 删除
- 查看
- 保存
- 取消
- 上传
- 更换图片
- 排序
- 上移
- 下移
- 发布
- 下线
- 启用
- 停用
- 复制
- 预览
4.x.6 校验规则
Describe required validation, format validation, length validation, image size, image format, duplicate sorting, duplicate enum values, and time ranges.
Use this table:
| 字段/操作 | 校验规则 | 触发时机 | 不通过提示 | 是否阻断提交 |
|---|
4.x.7 后台边界规则
Describe admin exceptions and boundaries, such as:
- 必填项为空
- 字数超限
- 图片格式错误
- 图片大小超限
- 排序值重复
- 删除已上线配置
- 编辑已生效配置
- 多人同时编辑
- 保存失败
- 查询无结果
- 筛选条件重置
- 权限不足
- 枚举值被引用后不可删除
- 配置正在被移动端使用
五、接口与字段说明
If existing APIs are provided, reuse original API names and fields. If no API is provided but the page clearly needs dynamic data, design virtual APIs.
Virtual API rules:
- API names must be Chinese.
- Field names must be Chinese.
- Do not use English field names, pinyin field names, camelCase, snake_case, abbreviations, or technical placeholders for virtual APIs.
- Do not invent names such as
id,type,status,title,imageUrl,createdTime,isEnabled, or similar English fields for virtual APIs. Use Chinese names such as "记录编号", "类型", "状态", "标题", "图片地址", "创建时间", and "是否启用". - If the user later provides a real API, replace or map the virtual Chinese interface and Chinese fields to the real technical interface and fields.
- Mark as "【虚拟接口，待技术确认】".
- Explain purpose, input parameters, output parameters, field meanings, field sources, usage locations, and exception rules.
- Do not write only "调用接口获取"; specify which API and which field is used by which module.
Before the API tables, write a short paragraph explaining why the page needs this API, which module calls it, and what information it returns or saves.
Use this structure for each API:
接口名称：
接口类型：
接口用途：
是否虚拟接口：
调用时机：
使用页面/模块：
入参：
| 字段名称 | 是否必填 | 字段类型 | 字段说明 | 示例值 |
|---|
出参：
| 字段名称 | 字段类型 | 字段说明 | 使用位置 | 异常规则 |
|---|
接口异常规则：
| 异常场景 | 页面表现 | 是否允许重试 | 提示文案 |
|---|
六、前台与后台字段映射关系
Explain how backend/admin configuration fields affect frontend/mobile display.
Use this table:
| 后台配置字段 | 后台位置 | 前台/移动端展示字段或模块 | 影响规则 | 是否必填 | 空值处理 |
|---|
七、业务流程图 / 泳道图 / 状态流转图 / 接口调用时序图
Add Mermaid diagrams when any of these are present:
- Frontend-admin linkage
- API call chains
- State transitions
- Publish, enable, disable, approve, online, or offline flows
- Multi-role collaboration
- Complex user operation paths
Choose the diagram type based on the requirement:
- 普通业务流程图
- 泳道图
- 状态流转图
- 接口调用时序图
Use Mermaid syntax. Keep node text in Chinese and make flow branches explicit.
八、权限规则
Describe permission control for admin entry, buttons, data visibility, editable status, deletable status, and mobile eligibility if present.
Use this table when applicable:
| 权限点 | 适用对象 | 控制范围 | 无权限表现 | 说明 |
|---|
九、埋点与日志需求
If user behavior, operation audit, publish history, or troubleshooting is relevant, define tracking and logs.
Use this table:
| 事件/日志名称 | 触发时机 | 记录字段 | 使用目的 | 备注 |
|---|
十、待确认问题
List unresolved items clearly. Include suspected conflicts, missing API fields, missing admin rules, unclear button behavior, unclear permission rules, unclear image requirements, unclear state definitions, and inferred assumptions.
Use this table:
| 序号 | 问题类型 | 问题描述 | 影响范围 | 建议确认对象 | 当前处理方式 |
|---|
Quality Checklist
Before finalizing the PRD, verify:
- Every visible frontend/mobile field has a data source and display rule.
- Every backend/admin field has validation and frontend/mobile impact when applicable.
- Every button has click behavior, permission, confirmation, success, and failure rules.
- Every dynamic module maps to an API field or admin configuration field.
- Every virtual API is marked as pending technical confirmation.
- Every virtual API uses Chinese interface names and Chinese field names.
- Existing English API fields, if any, have Chinese meanings and usage explanations.
- Each major section includes natural-language explanation before tables.
- Every conflict or uncertainty appears in "待确认问题".
- Mermaid diagrams are included when workflows or state transitions are non-trivial.
- The document avoids generic background and vague wording.