prd-maker

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

PRD Maker

PRD生成器

Turn a rough product idea into a reviewable AI planning package: PRD, planning diagram, feature spec, user flow, wireframe, preview viewer, and source log.

Create or update planning folders under
```
.hypercore/prd/[slug]/
```
from short product ideas, feature requests, or initiative notes.
Produce the core planning outputs a team can review before implementation: product requirements, visual planning map, functional details, user flow, low-fidelity wireframe, and browser preview.
Keep assumptions, open questions, scope decisions, and evidence visible instead of pretending the idea is fully specified.

</purpose>

<routing_rule>

Use

prd-maker

when the main output is a stored product planning package, PRD, planning diagram, feature specification, user flow, wireframe, or preview viewer.

Use

research

instead when the job is only fact-finding and no planning package should be written yet.

Use

docs-maker

instead when the output is a general document, runbook, guide, or technical spec not stored as a product planning folder.

Use

plan

instead when the user wants discussion or task planning but does not want files under

.hypercore/prd/

Do not use

prd-maker

when:

the user only wants brainstorming with no saved artifact
the user only wants implementation, coding, or debugging
the requested output is only a generic markdown document rather than product requirements/planning output

</routing_rule>

<activation_examples>

Positive requests:

"Create a PRD and flow for team inbox assignments."
"Make a ManyFast-style planning output for a billing retry feature."
"Turn this app idea into PRD, diagram, feature spec, user flow, and wireframe docs."
"Update the existing onboarding PRD with a new flow and acceptance criteria."

Negative requests:

"Research how competitors handle onboarding."
"Implement the billing retry flow."
"Rewrite this runbook for support engineers."

Boundary request:

"Plan this feature before coding." Use
```
prd-maker
```
only if the plan should become a saved planning package under
```
.hypercore/prd/
```
. Otherwise route to
```
plan
```
.

</activation_examples>

<trigger_conditions>

Situation	Mode
A rough product idea needs a complete planning package	create
A PRD needs a supporting diagram, feature spec, user flow, or wireframe added	update
Existing planning docs need scope, requirements, metrics, risks, or flows refreshed	update
A release or initiative needs source-backed requirements before implementation	create/update

</trigger_conditions>

<supported_targets>

New planning package folders under
```
.hypercore/prd/[slug]/
```
Existing package updates under
```
.hypercore/prd/[slug]/
```
```
prd.md
```
product requirements
```
diagram.md
```
visual planning map source,
```
diagram.data.json
```
node data, and rendered
```
diagram.svg
```
```
feature-spec.md
```
functional specification and acceptance criteria
```
user-flow.md
```
actor journeys, states, and edge cases
```
wireframe.md
```
text-based low-fidelity wireframes and screen inventory
```
preview.html
```
browser-viewable package preview generated from the package files and
```
assets/preview.template.html
```
```
sources.md
```
evidence, query, and context log
```
flow.json
```
phase tracking for complex multi-session packages

</supported_targets>

<complexity_classification>

Classify before writing files:

Complexity	Signals	Path
Simple	Single feature, clear audience, limited unknowns, minimal research, small output	Direct package — write the core markdown files and source log without flow tracking
Complex	Multi-feature initiative, vague or high-stakes scope, external research, multiple personas, cross-team dependencies, phased rollout	Tracked package — add and maintain `flow.json`

Announce the classification:

text

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

When uncertain, classify as complex. Losing phase state is more expensive than maintaining a small flow file.

</complexity_classification>

<output_shape>

Default package shape:

text

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

```
prd.md
```
explains the product decision: problem, goals, scope, requirements, metrics, risks, and open questions.
```
diagram.md
```
contains a ManyFast-like branching planning map: central idea → PRD/spec/flow/wireframe branches, with key subnodes and open gaps.
```
diagram.data.json
```
feeds
```
scripts/render-planning-map.mjs
```
, which renders the card-and-connector map to
```
diagram.svg
```
without adding dependencies.
```
feature-spec.md
```
translates the PRD into functional behavior, acceptance criteria, states, and edge cases.
```
user-flow.md
```
captures the key paths, decision points, empty/error states, and handoffs.
```
wireframe.md
```
describes low-fidelity screens and layout blocks in text so designers/builders can review structure before visual work.
```
preview.html
```
embeds the package content and
```
diagram.svg
```
into a local browser viewer for fast review.
```
sources.md
```
logs provided context, research queries, links, and evidence gaps.
```
flow.json
```
tracks phase progress for complex packages. See
```
references/flow-schema.md
```
.

Use the templates in

assets/

when creating a folder for the first time. For the diagram, create

diagram.md

diagram.data.json

, and

diagram.svg

; prefer

scripts/render-planning-map.mjs

because it renders the visual map without new dependencies.

</output_shape>

<support_file_read_order>

Read in this order:

This core
```
SKILL.md
```
to confirm the request belongs to a planning package.
```
rules/package-workflow.md
```
to choose create/update mode, complexity, research need, and package phase order.
```
rules/storage-and-updates.md
```
to apply folder, slug, file, and merge rules.

references/planning-package.md

when drafting

diagram.md

feature-spec.md

user-flow.md

, or

wireframe.md

```
references/prd-sections.md
```
when drafting or updating
```
prd.md
```
.
Relevant templates in
```
assets/
```
when creating missing package files, including
```
diagram.data.template.json
```
.

scripts/render-planning-map.mjs

when rendering

diagram.svg

from

diagram.data.json

assets/preview.template.html

and

scripts/build-preview.mjs

when generating

preview.html

```
assets/sources.template.md
```
when live research is needed and the package needs a source ledger.
```
references/flow-schema.md
```
when the package is complex or a
```
flow.json
```
already exists.
```
rules/validation.md
```
before declaring the package complete.

</support_file_read_order>

将粗略的产品想法转化为可评审的AI规划包：PRD、规划图、功能规格、用户流程、线框图、预览查看器和来源日志。

根据简短的产品想法、功能需求或计划笔记，在
```
.hypercore/prd/[slug]/
```
下创建或更新规划文件夹。
生成团队在开发前可评审的核心规划输出：产品需求、可视化规划图、功能细节、用户流程、低保真线框图和浏览器预览。
保留假设、待解决问题、范围决策和依据，而非假装想法已完全明确。

</purpose>

<routing_rule>

当主要输出为存储的产品规划包、PRD、规划图、功能规格、用户流程、线框图或预览查看器时，使用

prd-maker

。

当任务仅为事实调研且暂无需编写规划包时，改用

research

。

当输出为通用文档、运行手册、指南或技术规格，且不存储为产品规划文件夹时，改用

docs-maker

。

当用户需要讨论或任务规划，但不需要在

.hypercore/prd/

下生成文件时，改用

plan

。

以下情况请勿使用

prd-maker

：

用户仅需头脑风暴，无需保存成果
用户仅需开发、编码或调试
请求的输出仅为通用markdown文档，而非产品需求/规划输出

</routing_rule>

<activation_examples>

正向请求示例：

"为团队收件箱分配功能创建PRD和流程。"
"为账单重试功能生成ManyFast风格的规划输出。"
"将这个应用想法转化为PRD、图表、功能规格、用户流程和线框图文档。"
"更新现有的入职PRD，添加新流程和验收标准。"

反向请求示例：

"调研竞品如何处理入职流程。"
"实现账单重试流程。"
"为支持工程师重写这份运行手册。"

边界请求示例：

"编码前规划这个功能。" 仅当规划需要保存为
```
.hypercore/prd/
```
下的规划包时，使用
```
prd-maker
```
；否则路由至
```
plan
```
。

</activation_examples>

<trigger_conditions>

场景	模式
粗略的产品想法需要完整的规划包	创建
PRD需要添加配套的图表、功能规格、用户流程或线框图	更新
现有规划文档需要刷新范围、需求、指标、风险或流程	更新
版本发布或计划需要在开发前提供有来源支撑的需求	创建/更新

</trigger_conditions>

<supported_targets>

```
.hypercore/prd/[slug]/
```
下的新规划包文件夹
```
.hypercore/prd/[slug]/
```
下的现有包更新
```
prd.md
```
产品需求文档
```
diagram.md
```
可视化规划图源文件、
```
diagram.data.json
```
节点数据，以及渲染后的
```
diagram.svg
```
```
feature-spec.md
```
功能规格和验收标准
```
user-flow.md
```
角色旅程、状态和边缘场景
```
wireframe.md
```
基于文本的低保真线框图和页面清单
```
preview.html
```
可在浏览器查看的包预览，由包文件和
```
assets/preview.template.html
```
生成
```
sources.md
```
依据、查询和上下文日志
```
flow.json
```
复杂多会话包的阶段跟踪

</supported_targets>

<complexity_classification>

编写文件前先进行分类：

复杂度	判断信号	处理路径
简单	单一功能、受众明确、未知项少、调研需求低、输出内容少	直接生成包 — 编写核心markdown文件和来源日志，无需流程跟踪
复杂	多功能计划、范围模糊或高风险、需外部调研、多角色、跨团队依赖、分阶段发布	跟踪式包 — 添加并维护 `flow.json`

需宣布分类结果：

text

复杂度: [简单/复杂] — [一句话理由]

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

</complexity_classification>

<output_shape>

默认包结构：

text

.hypercore/prd/[slug]/
├── prd.md
├── diagram.md
├── diagram.data.json
├── diagram.svg
├── feature-spec.md
├── user-flow.md
├── wireframe.md
├── preview.html
├── sources.md
└── flow.json          (仅复杂路径包含)

```
prd.md
```
说明产品决策：问题、目标、范围、需求、指标、风险和待解决问题。
```
diagram.md
```
包含类似ManyFast的分支规划图：核心想法 → PRD/规格/流程/线框图分支，包含关键子节点和待填补空白。
```
diagram.data.json
```
为
```
scripts/render-planning-map.mjs
```
提供数据，无需添加依赖即可将卡片连接图渲染为
```
diagram.svg
```
。
```
feature-spec.md
```
将PRD转化为功能行为、验收标准、状态和边缘场景。
```
user-flow.md
```
记录关键路径、决策点、空/错误状态和交接环节。
```
wireframe.md
```
用文本描述低保真页面和布局模块，方便设计师/开发者在视觉设计前评审结构。
```
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>

按以下顺序读取：

核心文件
```
SKILL.md
```
，确认请求属于规划包范畴。
```
rules/package-workflow.md
```
，选择创建/更新模式、复杂度、调研需求和包阶段顺序。
```
rules/storage-and-updates.md
```
，应用文件夹、slug、文件和合并规则。

起草

diagram.md

、

feature-spec.md

、

user-flow.md

或

wireframe.md

时，参考

references/planning-package.md

。

起草或更新
```
prd.md
```
时，参考
```
references/prd-sections.md
```
。
创建缺失的包文件时，使用
```
assets/
```
中的相关模板，包括
```
diagram.data.template.json
```
。

从

diagram.data.json

渲染

diagram.svg

时，使用

scripts/render-planning-map.mjs

。

生成

preview.html

时，使用

assets/preview.template.html

和

scripts/build-preview.mjs

。

需要实时调研且包需要来源记录时，使用
```
assets/sources.template.md
```
。
包为复杂类型或已存在
```
flow.json
```
时，参考
```
references/flow-schema.md
```
。
宣布包完成前，参考
```
rules/validation.md
```
。

</support_file_read_order>

Direct package path

直接生成包路径

Phase	Task	Output
0	Confirm package deliverable, choose create/update, classify simple	Mode + complexity
1	Extract or infer a minimum brief; put unresolved gaps in open questions	Working brief
2	Create or locate `.hypercore/prd/[slug]/`	Storage target
3	Write or update `prd.md` , `diagram.md` , `feature-spec.md` , `user-flow.md` , `wireframe.md` , `preview.html` , and `sources.md`	Reviewable package
4	Validate consistency, scope, evidence, and unknowns	Final package

阶段	任务	输出
0	确认包交付内容，选择创建/更新模式，分类为简单	模式 + 复杂度
1	提取或推断最小化需求 brief；将未解决的空白放入待解决问题	工作需求 brief
2	创建或定位 `.hypercore/prd/[slug]/`	存储目标
3	编写或更新 `prd.md` 、 `diagram.md` 、 `feature-spec.md` 、 `user-flow.md` 、 `wireframe.md` 、 `preview.html` 和 `sources.md`	可评审的包
4	验证一致性、范围、依据和未知项	最终包

Tracked package path

跟踪式生成包路径

Phase	Task	Output
0	Confirm package deliverable, choose create/update, classify complex	Mode + complexity
1	Create or locate folder and initialize/resume `flow.json`	Storage target + phase state
2	Gather minimum brief and update `flow.json`	Working brief
3	Run live research if needed or record why skipped	Evidence basis
4	Draft/update PRD, diagram, feature spec, user flow, wireframe, preview, and sources in phase order	Planning package
5	Validate and mark flow completed	Final package

阶段	任务	输出
0	确认包交付内容，选择创建/更新模式，分类为复杂	模式 + 复杂度
1	创建或定位文件夹，初始化/恢复 `flow.json`	存储目标 + 阶段状态
2	收集最小化需求 brief 并更新 `flow.json`	工作需求 brief
3	如需实时调研则执行，否则记录跳过原因	依据基础
4	按阶段顺序起草/更新PRD、图表、功能规格、用户流程、线框图、预览和来源文件	规划包
5	验证并标记流程完成	最终包

Operating rules

操作规则

Start from the user's rough idea; infer only low-risk basics and mark everything else as assumptions or open questions.
Do not ask for clarification unless a missing answer would materially branch the product direction.
If current market, competitor, legal, platform, or technical facts affect requirements, run live research before finalizing claims.
Update existing packages surgically. Preserve valid decisions and append dated change history rather than rewriting everything.
Keep raw research and context in
```
sources.md
```
, not in the PRD body.
Treat the diagram as a navigable product map, not a decorative image.
Rebuild
```
preview.html
```
after package content changes so the viewer is never stale.
Treat wireframes as structural review artifacts, not polished visual design.

</workflow> <required>

Complexity classified before writing.
Every package stored under
```
.hypercore/prd/[slug]/
```
with ASCII kebab-case slug preferred.

New packages include

prd.md

diagram.md

diagram.data.json

diagram.svg

feature-spec.md

user-flow.md

wireframe.md

preview.html

, and

sources.md

PRD includes goals, scope, non-goals, requirements, metrics, risks/dependencies, open questions, and change history.
Diagram includes a central initiative node, first-level planning branches, second-level requirement/flow/screen nodes, and open gaps.
Feature spec includes functional requirements, acceptance criteria, states, errors, permissions, analytics, and rollout notes when relevant.
User flow includes actors, happy paths, alternate paths, edge/error states, and entry/exit points.
Wireframe includes screen inventory, layout blocks, component notes, and unresolved visual/product questions.
Preview HTML opens locally in a browser and includes the diagram plus text artifacts.
```
sources.md
```
records provided context and either distinct research queries or why external research was unnecessary.
Complex packages maintain
```
flow.json
```
and update it after each phase.

</required> <forbidden>

Returning the planning package only in chat without saving files.
Creating a PRD without the supporting diagram, spec, flow, wireframe, and preview when making a new package.
Hiding assumptions or unresolved questions.
Copying raw source material into the PRD instead of summarizing and linking it from
```
sources.md
```
.
Creating extra README, notes, or changelog files unless the user explicitly asks.
Treating the diagram as final architecture or the wireframe as final UI design/implementation code.

</forbidden>

从用户的粗略想法出发；仅推断低风险基础信息，其余均标记为假设或待解决问题。
除非缺失的答案会实质性改变产品方向，否则无需请求澄清。
如果当前市场、竞品、法律、平台或技术事实影响需求，在最终确定结论前执行实时调研。
针对性更新现有包。保留有效的决策，添加带日期的变更历史，而非重写全部内容。
将原始调研和上下文保存在
```
sources.md
```
中，而非PRD正文中。
将图表视为可导航的产品地图，而非装饰性图像。
包内容变更后重新生成
```
preview.html
```
，确保查看器内容始终最新。
将线框图视为结构评审成果，而非 polished 的视觉设计。

</workflow> <required>

编写前需完成复杂度分类。
所有包均存储在
```
.hypercore/prd/[slug]/
```
下，优先使用ASCII短横线命名法（kebab-case）的slug。

新包需包含

prd.md

、

diagram.md

、

diagram.data.json

、

diagram.svg

、

feature-spec.md

、

user-flow.md

、

wireframe.md

、

preview.html

和

sources.md

。

PRD需包含目标、范围、非目标、需求、指标、风险/依赖、待解决问题和变更历史。
图表需包含核心计划节点、一级规划分支、二级需求/流程/页面节点和待填补空白。
功能规格需包含功能需求、验收标准、状态、错误、权限、分析和相关的发布说明。
用户流程需包含角色、理想路径、备选路径、边缘/错误状态和入口/出口点。
线框图需包含页面清单、布局模块、组件说明和未解决的视觉/产品问题。
预览HTML可在本地浏览器打开，包含图表和文本成果。
```
sources.md
```
记录提供的上下文，以及明确的调研查询或无需外部调研的原因。
复杂包需维护
```
flow.json
```
，并在每个阶段后更新。

</required> <forbidden>

仅在聊天中返回规划包，不保存文件。
创建新包时，仅生成PRD而不配套提供图表、规格、流程、线框图和预览。
隐藏假设或未解决的问题。
将原始来源材料复制到PRD中，而非在
```
sources.md
```
中总结并链接。
除非用户明确要求，否则创建额外的README、笔记或变更日志文件。
将图表视为最终架构，或将线框图视为最终UI设计/实现代码。

</forbidden>