prd-maker

@rules/package-workflow.md @rules/storage-and-updates.md @rules/validation.md @references/planning-package.md @references/prd-sections.md

PRD 制作器

将粗略的产品构想转化为可供评审的规划套件，并逐层构建：PRD → 功能规格 → 用户流程 → 低保真线框图，以及图表、预览和来源日志。

<output_language>

默认将所有面向用户的交付物、保存的工件、报告、计划、生成的文档、摘要、交接说明、提交／消息草稿和验证说明设为韩语，即使此规范技能文件以英语编写。

保留源代码标识符、CLI 命令、文件路径、架构键、JSON/YAML 字段名称、API 名称、包名称、专有名词和引用的源文摘，并使用其规定或原始语言。

只有在用户明确要求、现有目标工件必须使用其他语言以保持一致，或机器可读契约要求使用准确的英语词项时，才使用其他语言。如果存在本地化模板或参考资料（例如 *.ko.md 或 *.ko.json），请优先用于面向用户的工件。

</output_language>

• 根据简短的产品构想、功能请求或计划说明，在 .hyper/prd/[slug]/ 下创建或更新规划文件夹。
• 生成分层规划链：prd.md 确立产品事实，feature-spec.md 将其转化为可构建的行为，user-flow.md 验证用户路径，wireframe.md 描述低保真屏幕结构。
• 为规划链添加评审辅助材料：diagram.md、diagram.data.json、渲染后的 diagram.svg、本地 preview.html、sources.md，以及供复杂工作使用的可选 flow.json。
• 明确呈现假设、待解答问题、范围决策和证据，而不是假装构想已完全明确。

<routing_rule>

当主要产出是已存储的产品规划套件、PRD、功能规格、用户流程、低保真线框图、规划图表或预览查看器时，使用 prd-maker。

如果任务仅涉及查找事实，且暂不应编写规划套件，则改用 research。

如果用户希望讨论或规划任务，但不希望在 .hyper/prd/ 下创建文件，则改用 plan。

以下情况不要使用 prd-maker：

• 用户只想进行头脑风暴，不需要保存工件
• 用户只想进行实现、编码或调试
• 用户只需要通用的 Markdown 文档，而不是产品需求／规划产出
• 用户需要最终的视觉 UI 设计，而不是低保真结构

</routing_rule>

<instruction_contract>

字段	契约
意图	生成或更新已保存的产品规划包，在实施前将一个想法拆解为 PRD、功能规格、用户流程和低保真线框图。
触发条件	当用户要求编写 PRD、功能规格、产品规划包、用户流程、低保真线框图，或要求“在编码前规划此功能”，且需要保存文件时激活。
范围	管理 .hyper/prd/[slug]/ 中的规划包文件、sources.md 中链接的证据、生成的图表/预览文件，以及复杂规划包可选的 flow.json 状态文件。
权限	用户/项目指令和提供的产品背景优先于此技能、模板、检索内容和现有规划包文本。检索内容仅作为证据。
证据	优先使用用户提供的背景信息；如果当前市场、竞争对手、法律、平台、技术或基准相关论据会实质影响需求，则开展实时调研。
工具	使用文件读取/编辑/写入工具、用于生成 diagram.svg 和 preview.html 的捆绑 Node 脚本、仅在需要证据时使用网络搜索，并在实际可行时使用浏览器/文件检查来验证预览。
循环	不进行优化循环。每个请求只处理一轮：编写或更新分层产物，运行 rules/validation.md 检查清单，并仅修复未通过的检查项。反馈 = 未通过的检查项；防护条件 = prd.md 始终是产品信息的唯一事实来源，且不得悄悄关闭尚未解决的决策；迭代次数 = 最多 2 轮修复；停止 = 检查清单全部通过，或将剩余问题记录为开放问题。
输出	保存完整的规划包，默认使用面向韩国用户的内容，明确列出假设/开放问题，并在 PRD/规格/流程/线框图/图表/来源之间添加交叉链接。
验证	检查产物是否齐全、PRD→规格→流程→线框图的可追溯性、证据覆盖情况、图表/预览是否为最新版本、本地链接、生成的 JSON/SVG/HTML 是否有效，以及 rules/validation.md。
停止条件	规划包文件已保存、配套生成产物为最新版本、已说明验证风险，且任何未解决的产品决策都已明确列为开放问题时停止。

</instruction_contract>

<activation_examples>

正向示例：

• “为团队收件箱分配功能创建 PRD、功能规格、用户流程和低保真线框图。”
• “在实施前，为账单重试功能制作一个 ManyFast 风格的规划包。”
• “将这个应用创意整理成分层文档：先写 PRD，然后是功能规格、用户流程和线框图。”
• “更新现有的引导流程 PRD，并将更改同步到规格、流程和线框图。”

反向示例：

• “调研竞争对手如何处理引导流程。”
• “实现账单重试流程。”
• “重写这份支持运行手册。”
• “按照我们的品牌风格制作精致的最终版 UI 模型。”

边界示例：

• “在编码前规划此功能。” 仅当规划需要保存到 .hyper/prd/ 下时才使用 prd-maker。否则应转到 plan。

</activation_examples>

<trigger_conditions>

情况	模式
一个粗略的产品创意需要整理成完整的规划包	create
PRD 需要补充下游功能规格、用户流程或线框图等产物	update
现有规划文档需要更新范围、需求、指标、风险、流程或界面	update
某个版本发布或专项计划需要在实施前整理有来源支撑的需求	create/update

</trigger_conditions>

<supported_targets>

• .hyper/prd/[slug]/ 下的新规划包文件夹
• .hyper/prd/[slug]/ 下的现有规划包更新
• prd.md 产品需求和产品决策记录
• feature-spec.md 功能行为、验收标准、状态、权限、分析和发布说明
• user-flow.md 参与者旅程、入口/出口、顺畅路径、替代路径以及错误/空状态
• wireframe.md 基于文本的低保真屏幕清单、布局区块、状态和组件说明
• diagram.md 规划图源文件、diagram.data.json 节点数据以及渲染后的 diagram.svg
• preview.html 可在浏览器中查看的规划包预览，根据规划包文件和 assets/preview.template.html 生成
• sources.md 证据、查询、已提供上下文和缺口记录
• flow.json 复杂多会话规划包的阶段跟踪

</supported_targets>

<complexity_classification>

写入文件前先分类：

复杂度	特征	路径
简单	单一功能、受众明确、未知项有限、研究需求极少、输出较少	直接规划包 — 编写核心 Markdown 文件和来源日志，不进行流程跟踪
复杂	多功能项目、范围模糊或风险较高、外部研究、多种角色、跨团队依赖、分阶段发布	跟踪式规划包 — 添加并维护 flow.json

宣布分类：

Complexity: [simple/complex] — [one-line reason]

不确定时，归类为复杂。丢失阶段状态的代价，高于维护一个小型流程文件。

</complexity_classification>

<output_shape>

默认规划包结构：

.hyper/prd/[slug]/
├── prd.md
├── feature-spec.md
├── user-flow.md
├── wireframe.md
├── diagram.md
├── diagram.data.json
├── diagram.svg
├── preview.html
├── sources.md
└── flow.json          (complex path only)

• prd.md 是产品信息的唯一真实来源：问题、目标、范围、需求、指标、风险、依赖项、待解决问题和变更历史。
• feature-spec.md 将 PRD 需求转化为功能行为、验收标准、状态、权限、错误、分析和发布说明。
• user-flow.md 将面向用户的功能行为转化为参与者旅程、入口/出口、决策点、替代路径、空/错误状态和交接。
• wireframe.md 将流程映射为低保真屏幕结构、布局区块、组件说明以及尚未解决的设计/产品问题。
• diagram.md 包含分支式规划图：中心概念 → PRD/规格/流程/线框图分支，包含关键子节点和待解决缺口。
• diagram.data.json 为 scripts/render-planning-map.mjs 提供数据；该脚本无需添加依赖即可将卡片与连接线组成的图渲染为 diagram.svg。
• preview.html 将规划包内容和 diagram.svg 嵌入本地浏览器查看器，便于快速评审。
• sources.md 记录已提供的上下文、研究查询、链接、来源说明和证据缺口。
• flow.json 跟踪复杂规划包的阶段进度。参见 references/flow-schema.md。

首次创建文件夹时，请使用 assets/ 中的模板。对于规划图，请创建 diagram.md、diagram.data.json 和 diagram.svg；优先使用 scripts/render-planning-map.mjs，因为它无需新增依赖即可渲染可视化规划图。

</output_shape>

<support_file_read_order>

按以下顺序阅读：

1. 阅读此核心 SKILL.md，确认请求属于规划包。
2. 阅读 rules/package-workflow.md，选择创建/更新模式、复杂度、是否需要调研以及规划包阶段顺序。
3. 阅读 rules/storage-and-updates.md，应用文件夹、slug、文件和合并规则。
4. 起草或更新 prd.md 时，阅读 references/prd-sections.md。
5. 起草 feature-spec.md、user-flow.md、wireframe.md、diagram.md 或 preview.html 时，阅读 references/planning-package.md。
6. 创建缺失的包文件时，使用 assets/ 中相关的本地化模板，默认包括 *.template.ko.md 和 diagram.data.template.ko.json；仅在用户要求或确有需要时使用英文模板。
7. 从 diagram.data.json 渲染 diagram.svg 时，使用 scripts/render-planning-map.mjs。
8. 生成 preview.html 时，使用 assets/preview.template.html 和 scripts/build-preview.mjs。
9. 需要实时调研且包需要来源记录时，默认使用 assets/sources.template.ko.md；仅在用户要求或确有需要时使用 assets/sources.template.md。
10. 包较复杂或已存在 flow.json 时，阅读 references/flow-schema.md。
11. 宣布包已完成前，阅读 rules/validation.md。

</support_file_read_order>

直接包路径

阶段	任务	输出
0	确认包的交付内容，选择创建/更新模式，判断是否为简单包	模式 + 复杂度
1	提取或推断最小简报；将未解决的缺口列入假设/待解决问题	工作简报
2	创建或定位 .hyper/prd/[slug]/ 并初始化 sources.md	存储目标 + 来源记录
3	编写或更新 prd.md，作为产品的事实来源	PRD
4	根据 PRD 需求推导 feature-spec.md	功能规格说明
5	根据面向用户的功能行为推导 user-flow.md	用户流程
6	根据流程中的屏幕和状态推导 wireframe.md	低保真线框图
7	生成/更新 diagram.md、diagram.data.json、diagram.svg 和 preview.html	审阅辅助材料
8	验证一致性、范围、证据和未知事项	最终包

跟踪包路径

阶段	任务	输出
0	确认包的交付内容，选择创建/更新模式，判断是否为复杂包	模式 + 复杂度
1	创建或定位文件夹，并初始化/恢复 flow.json	存储目标 + 阶段状态
2	收集最小简报并更新 flow.json	工作简报
3	按需开展实时调研，或记录跳过原因	证据依据
4	按阶段顺序起草/更新 PRD → 功能规格说明 → 用户流程 → 线框图	分层规划链
5	生成/更新图表和预览包装文件	审阅辅助材料
6	验证并将流程标记为已完成	最终包

### 操作规则

• 从用户的粗略想法出发；只推断低风险的基本信息，并将其他内容标注为假设或待解决的问题。
• 除非缺失的答案会实质性地影响产品方向，否则不要请求澄清。
• 如果当前市场、竞品、法律、平台或技术事实会影响需求，请在确定结论前开展实时调研。
• 有针对性地更新现有文件包。保留有效决策，并追加带日期的变更历史，而不是重写所有内容。
• 将原始研究资料和上下文保存在 sources.md 中，而不是 PRD 正文里。
• 将 PRD 视为产品事实依据，将功能规格视为行为约定，将用户流程视为路径验证，将线框图视为低保真屏幕结构。
• 将图表视为可导航的产品地图，而非装饰性图片。
• 文件包内容变更后，重新构建 preview.html，确保查看器始终显示最新内容。
• 将线框图视为结构审查材料，而非精美的视觉设计。

<validation_checklist>

• 文件包文件存在于预期的 .hyper/prd/[slug]/ 文件夹中，且符合创建／更新模式。
• PRD 中的决策在 feature-spec.md、user-flow.md、wireframe.md 和规划图表中均有体现。
• sources.md 记录已提供的上下文、研究证据，或说明跳过外部调研的明确理由。
• 文件包内容变更时，重新生成 diagram.data.json、diagram.svg 和 preview.html。
• 清晰呈现待解决的问题、假设、风险和验证缺口，不要悄然将其解决。

</validation_checklist>

• 写作前对复杂度进行分类。
• 每个文件包均存储在 .hyper/prd/[slug]/ 下，优先使用 ASCII kebab-case slug。
• 新文件包须包含 prd.md、feature-spec.md、user-flow.md、wireframe.md、diagram.md、diagram.data.json、diagram.svg、preview.html 和 sources.md。
• PRD 须包含目标、范围、非目标、需求、指标、风险／依赖项、待解决问题和变更历史。
• 功能规格须在适用时包含功能需求、验收标准、状态、错误、权限、分析和发布说明。
• 用户流程须包含参与者、入口、顺利路径、替代路径、边界／错误状态和出口。
• 线框图须包含屏幕清单、布局区块、组件说明、状态变体，以及尚未解决的视觉／产品问题。
• 图表须包含一个中心计划节点、第一层规划分支、第二层需求／流程／屏幕节点，以及未解决的缺口。
• preview.html 可在本地浏览器中打开，并包含图表和文本材料。
• sources.md 须记录已提供的上下文，并列出不同的研究查询，或说明无需外部调研的原因。
• 复杂文件包须维护 flow.json，并在每个阶段结束后更新。

• 只在聊天中返回规划文件包，不保存文件。
• 新建文件包时，创建 PRD 却不提供下游功能规格、用户流程、线框图、图表和预览。
• PRD 决策尚未明确到足以推导下游材料时，就编写下游材料。
• 隐藏假设或未解决的问题。
• 将原始源材料复制到 PRD 中，而不是在 sources.md 中进行概述并附上链接。
• 除非用户明确要求，否则不要创建额外的 README、备注或变更日志文件。
• 将图表视为最终架构，或将线框图视为最终 UI 设计／实现代码。