prd-generator-from-prototype

Other

读取产品原型图/页面描述,按预设模板自动生成标准PRD文档,完成后自检一致性,不扩展需求范围

Install

openclaw skills install prd-generator-from-prototype

1. 触发规则(When)

Use this skill when

  • 用户提供原型页面、需求描述,要求生成PRD
  • 需要按固定模板输出结构化产品需求文档
  • 需要限定需求范围、禁止自由扩展
  • 需要对生成结果做一致性自检

Do NOT use this skill when

  • 仅做简单问答、不生成文档
  • 没有提供原型/页面信息
  • 需求是代码开发、接口开发、数据查询

2. 输入输出(Input / Output)

Input

  • prototype_text: string # 原型页面描述/截图文字化
  • prd_template: string # 模板类型:business/analysis/list/form/auto(默认auto)
  • scope: string # 需求范围,只生成该范围内容(推荐:按“页面/模块/功能点”列出清单)

Output

  • 标准PRD文档(Markdown)
  • 一致性自检报告(漏项、错配、范围外内容)

2.2 scope 推荐格式与解析规则(强制约束)

推荐格式(择一)

  • 页面清单:列出允许覆盖的页面/弹窗/标签页名称(例如:“预算编制页、指标明细弹窗、导入结果页”)。
  • 功能点清单:列出允许覆盖的动作与能力(例如:“查询、重置、导出、提交、驳回、权限可见性”)。
  • 边界声明:明确不包含内容(例如:“不包含接口设计、不包含数仓口径重算、不包含移动端”)。

解析规则(必须执行)

  • 仅当某条PRD内容满足以下任一条件时,才视为“范围内”:
    • 明确对应到 scope 中的页面/弹窗/标签页;或
    • 明确对应到 scope 中的功能点,并且发生在 scope 允许的页面内。
  • 若 prototype_text 包含但 scope 未包含的页面/功能点:
    • 必须在“一致性自检报告-范围外内容”中列出,并拒绝将其展开成需求条目;
    • 仅允许以“待确认事项/开放问题”的方式提示用户补充 scope。
  • 若 scope 过于笼统(例如仅写“按原型生成”/“全部功能”):
    • 必须先输出“需补充信息清单”(见 2.3),在用户补齐前不得生成完整PRD正文(可生成目录骨架与占位)。

2.3 信息不足时的补问模板(最小必要集)

当出现以下任一情况时触发补问:未提供 scope;scope 不可判定边界;prototype_text 仅为截图但字段/按钮不可读;或 prd_template=auto 且无法判断业务类型。

输出格式必须为:

  • 缺失信息:
    • (1)scope:请按“页面/弹窗/标签页清单 + 功能点清单 + 明确不包含内容”给出
    • (2)原型信息:请补充可读的字段/按钮/流程/权限说明(可直接粘贴截图文字化内容)
    • (3)模板偏好:business 或 analysis(不确定可选 auto)
  • 在补齐前我将提供:
    • PRD目录骨架(按所选模板)
    • 已确认信息摘要(仅基于 prototype_text 可确定部分)

scope 可复制填写示例(推荐直接按此格式回填)

请将下方占位符替换为你的实际范围(保持三行结构不变):

  • 页面/弹窗/标签页:<页面A>;<页面B>;<弹窗C>;<标签页D>
  • 功能点:<查询>;<重置>;<导出>;<新增/编辑/删除>;<提交/驳回/退回>;<权限可见性>
  • 不包含:<接口设计>;<数据库表结构>;<数仓口径重算>;<移动端>;<跨模块改造>

2.1 约束优先级(冲突裁决)

  • 当模板示例与第6节书面语言输出规范发生冲突时,以第6节为最高优先级;模板仅作为结构参考,需随规范调整输出形式。
  • 当用户输入与本Skill约束冲突(例如要求扩展范围、要求输出JSON响应示例代码块)时,必须拒绝冲突请求并给出合规替代方案(书面字段结构描述)。

3. 执行步骤(Steps)

  1. 读取原型:提取页面结构、字段、按钮、流程、权限
  2. 匹配模板:优先使用用户指定的模板,未指定时默认使用【通用模块PRD模板】。
  3. 限定范围:只生成scope内内容,不新增无关模块
  4. 生成PRD:按模板输出完整结构(必须遵循第6节书面语言规范)
  5. 自检核对:对比原型与PRD,检查一致性、漏项、越界

4. 失败处理(On Failure)

  • 无原型/无范围:返回错误并提示补充信息
  • 模板不匹配:提示可选模板列表
  • 自检不通过:列出问题并修正后再输出
  • 超出范围:明确标注并拒绝生成

5. 模板引用(渐进式披露)

请从以下模板选择:

  • 通用业务模块PRD模板(template_business.md):遵循固定结构,包含需求背景、方案、菜单结构、通用规则、多标签页详细规则、技术实现说明,适用于所有数据分析类功能。
  • 通用数据分析模块PRD模板(template_analysis.md):遵循固定结构,包含需求背景、方案、菜单结构、通用规则、多标签页详细规则、技术实现说明,适用于所有数据分析类功能。
  • prd_template 映射规则:
    • business:使用 template_business.md
    • analysis:使用 template_analysis.md
    • list:使用 template_business.md 中的“需求结构(标准章节)”,重点展开“查询条件/页面展示/按钮与操作/异常规则”
    • form:使用 template_business.md 中的“需求结构(标准章节)”,重点展开“字段定义/校验规则/按钮与操作/权限控制”
    • auto:若原型以图表/指标/统计口径为主,使用 analysis;否则使用 business

默认使用:通用模块PRD模板

6. 书面语言输出规范(强制约束)

生成PRD文档时必须严格遵循以下规范,违者视为自检不通过:

6.1 禁止事项

  • 禁止使用emoji图标:文档中不得出现任何emoji符号(如🎯📊📦👤📖✅❌等),包括标题前缀、表格标记、状态标识等位置
  • 禁止使用Given-When-Then格式:验收条件不得采用"Given...When...Then..."的BDD测试用例格式,应改为自然语言描述
  • 禁止虚拟人设引用:不得出现"John审阅""AI优化""助手建议"等字样,保持文档客观性
  • 禁止口语化表达:不得使用"咱们""搞定""OK""没问题"等口语词汇
  • 禁止感叹号滥用:仅在警告/错误提示文案中使用单个感叹号,正文叙述一律不用感叹号
  • 禁止叙述性内容使用Markdown竖线表格:指标、目标、规则、约束、需求说明、验收标准、术语定义、附录(权限矩阵/开放问题/风险事项/参考文档/截图索引)等叙述性内容,一律使用书面段落或编号列表描述,严禁使用| 列 | 列 | ... |格式的Markdown表格。此为强制性要求,违者视为自检不通过
  • 禁止使用ASCII线框图及树形代码块:页面布局、弹窗结构、界面原型等不得使用┌─┐│└┘├┤┬┴┼═等制表符绘制线框图;菜单层级、功能树、目录结构等不得使用├──/等字符在代码块中绘制树形图。以上两类均须改为书面语言分层次描述其组成和层级关系
  • 禁止API响应示例使用JSON代码块:接口定义中的响应示例须使用书面语言描述字段结构和数据格式,严禁使用```json代码块展示示例数据。应说明返回数据的字段名称、数据类型、取值含义及示例值

6.2 文档结构规范

  • 章节标题采用中文数字编号:一、二、三……
  • 子节标题采用阿拉伯数字编号:1.1、1.2、1.3……
  • 同级列表项采用中文序号:(一)(二)(三)……或 1. 2. 3.
  • 表格必须有表头行,列名使用简明术语
  • 图片直接嵌入对应功能章节:界面截图、原型图等必须直接嵌入到对应功能章节的正文中(使用Markdown ![描述](路径)语法),严禁将图片集中放置在附录的"截图索引"章节中。每个功能章节应在功能说明或页面结构描述后紧邻插入相关截图,确保图文对应

6.3 语言风格要求

  • 使用正式书面语,如"旨在达成以下目标""其处理逻辑如下""具体说明如下"
  • 业务规则统一采用"规则名称+触发时机+执行逻辑+例外处理"四段式结构
  • 功能描述采用"功能说明+字段定义+业务规则+操作按钮"固定顺序
  • 接口定义包含请求方式、路径、参数、响应示例、错误码五要素

6.4 表格使用边界与字段定义格式

可保留表格的场景(仅限以下情况):

  • 文档修订记录表(版本/日期/修订内容/状态)
  • 数据库DDL级字段定义表(字段名/数据类型/长度/必填/默认值/索引/说明),用于开发建表参考
  • API接口参数表(请求参数/响应结构/错误码定义),用于前后端联调

禁止使用表格的场景(须转为书面语言):

  • 成功衡量指标、建设目标、不包含范围 → 分段叙述或编号列表
  • 功能模块列表、菜单架构 → 加粗编号列表
  • 配置差异对比 → 连贯段落逐项对比
  • 字段定义(业务层面)→ "名称(英文名),类型,必填,默认值,校验,来源"的连贯句式
  • 查询条件、列表列定义、操作按钮说明 → 分段书面描述
  • 编辑约束、状态约束 → 叙述性段落
  • 性能需求、安全需求 → 按维度分段叙述
  • 验收标准 → "AC-编号 功能名:预期结果"的自然语言格式
  • 术语定义 → "术语:定义。"的加粗格式
  • 附录(截图索引/权限矩阵/开放问题/风险事项/参考文档)→ 书面段落

附录内容扩展规范:

  • UI设计规范附录:允许在附录中补充配色方案、布局风格、组件规范等UI设计细节,以便保持界面一致性。示例: 配色方案:达标状态使用绿色(#52c41a),未达标状态使用红色(#f5222d),警告状态使用橙色(#faad14),主色调使用蓝色(#1890ff)。 布局风格:参考综合人车比V2.0的卡片式布局,采用上下分区结构。
  • 开发建议附录(可选):作为独立附录章节,可提供开发计划建议、工时估算、风险提示等内容,但不得放在正文主体中。

字段定义推荐格式示例:

录入人员(operator_name),只读文本类型,必填,默认值为当前登录用户,不可修改,数据来源于系统会话,用于标识数据录入者身份。

合计金额(total_amount),数字输入类型,必填,默认值为0,校验规则为大于0,始终显示。

伪代码和代码块:

  • 仅允许用于伪代码/公式/枚举清单等非数据示例内容;接口响应示例不得使用JSON代码块,页面/弹窗布局不得使用ASCII线框图或树形代码块,应改为书面层次描述。
  • 业务计算公式展示:允许使用代码块展示业务逻辑计算公式(如序时进度标准计算、达成率计算等),以便开发人员准确理解业务规则。示例:
    月度序时标准 = 50000 ÷ 12 = 4166.67 公里/月
    N月序时进度标准 = 4166.67 × N 公里
    达成率 = 当前累计里程 ÷ 序时进度标准 × 100%
    

页面/弹窗布局描述格式(替代ASCII线框图):

根据截图(图X),[页面/弹窗]采用[整体布局方式](如左右分区/上下分区/居中模态对话框),各区域组成如下:

[整体框架说明,如标题栏、标签页位置]

[第一区域]为[区域名称],包含以下内容:[字段列表或功能说明]。

[第二区域]分为[X]部分。[子区域A][描述]。[子区域B][描述]。

[底部操作区]排列以下按钮:[按钮名1](功能)、[按钮名2](功能)。