tuya 概述 {#description}
本技能只服务于小程序面板需求文档，不扩展为通用 PRD 写作器。目标是把用户提供的信息整理标准全面 的 Markdown 文档，默认输出完整模板；信息不足时保留结构并使用明确占位，不虚构未确认内容。
这类请求默认直接产出文档，不先进入通用 brainstorming 或方案讨论流程，除非用户明确要求先出 plan、设计方案或对比选项。
生成全文时使用以下固定顺序：
- 顶部版本记录表
一、需求背景二、协作方与交付件三、产品总览四、小程序功能说明五、附件
章节顺序、表格列名、空白骨架和占位规范统一参考 references/standard-structure.md。需要具体表头或字段口径时，先读取该文件再输出。
适用场景 {#scene}
- 从零起草小程序面板需求文档。
- 把零散需求整理成模板化 Markdown。
- 只补某一章，如
产品基本信息、DP 点说明、小程序功能说明或附件。 - 先生成空白模板，后续由人工继续填写。
- 信息不全，但需要先形成可评审、可协作的文档结构。
不适用场景：
- 通用产品 PRD 或未限定终端类型的需求文档。
- Web 站点、H5 页面、官网、活动页、落地页需求文档。
- 管理后台、中后台、运营平台、控制台、SaaS 平台需求文档。
- 原生 App、桌面端、PC 客户端或其他非小程序面板项目。
- 用户明确要求使用另一套模板、另一种文档规范或只做通用需求梳理。
输入边界：
- 只使用用户提供信息和模板本身可推出的常识。
- 未提供的数据写
待业务确认、待补充链接、待补充示意图等明确占位。 - 不编造客户名、团队成员、版本结论、协议参数、链接地址或验收结论。
搭配使用 {#usage}
- 本技能生成 prd 后可使用 requirement-validation-skill(如存在此 skill) 进行需求文档的自动校验，确保输出符合规范。
工作流程 {#workflow}
默认工作流
- 先判断用户要的是全文、局部章节，还是空白模板。
- 全文模式下，按模板固定顺序输出所有章节，不跳章。
- 局部模式下，只输出用户要求的章节，但章节内部仍保持模板标题和表格形态。
- 缺信息时保留表头和最少一行占位，保证文档可继续补充。
- 输出前自检章节顺序、表头、占位文案和显然的虚构信息。
全文输出要求
- 使用 Markdown 标题和 Markdown 表格，不使用 HTML table。
- 顶部先给版本记录表；无版本信息时默认首行可写
V1.0 | YYYY/MM/DD | 初版。 三、产品总览下固定包含：### 1、产品基本信息### 2、DP 点说明
四、小程序功能说明下按页面分块；至少保留 1 个页面块，标题格式参照### 1、（页面一）如：首页。五、附件表在无附件时也要保留空行占位。
局部输出要求
- 只写用户明确要求的章节。
- 章节依赖表格时，输出完整表头和最少 1 行占位。
- 用户要求“骨架”或“模板”时，直接输出可复制的 Markdown 模板，不额外扩写长说明。
自检要点
- 标题顺序是否与模板一致。
- 表头是否与参考文件一致。
- 未知信息是否使用明确占位。
- 是否混入模板之外的章节或旧版结构。
注意事项 {#tip}
MUST
- 以
references/standard-structure.md作为结构和表格的唯一标准。 - 全文模式下输出完整五章结构和顶部版本表。
- 缺信息时保留结构，用明确占位承接，不删关键表格。
协作方与交付件、DP 点说明、小程序功能说明、附件都要以表格形式呈现。小程序功能说明的每个页面块都要包含序号、交互说明、UI 图三列。- 先确认当前请求确实是小程序面板需求；如果是通用 PRD 或 Web/H5/后台/App 类需求，不要套用本技能。
MUST NOT
- 不要输出 HTML 表格、富文本颜色标记或 wiki 样式标签。
- 不要把未知信息写成确定事实。
- 不要省略用户未填写但模板要求保留的章节和表头。
- 不要把本技能误用于 Web、H5、官网、管理后台、中后台、App、桌面端或其他通用需求文档。