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

PRD Maker

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>

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

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

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>

prd-maker

NPX Install

Tags

SKILL.md Content

PRD Maker

Direct package path

Tracked package path

Operating rules