@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.

<output_language>

Default all user-facing deliverables, saved artifacts, reports, plans, generated docs, summaries, handoff notes, commit/message drafts, and validation notes to Korean, even when this canonical skill file is written in English.

Preserve source code identifiers, CLI commands, file paths, schema keys, JSON/YAML field names, API names, package names, proper nouns, and quoted source excerpts in their required or original language.

Use a different language only when the user explicitly requests it, an existing target artifact must stay in another language for consistency, or a machine-readable contract requires exact English tokens. If a localized template or reference exists (for example *.ko.md or *.ko.json), prefer it for user-facing artifacts.

</output_language>

• 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.

<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:

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:

.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:

1. This core SKILL.md to confirm the request belongs to a planning package.
2. rules/package-workflow.md to choose create/update mode, complexity, research need, and package phase order.
3. rules/storage-and-updates.md to apply folder, slug, file, and merge rules.
4. references/planning-package.md when drafting diagram.md, feature-spec.md, user-flow.md, or wireframe.md.
5. references/prd-sections.md when drafting or updating prd.md.
6. Relevant localized templates in assets/ when creating missing package files, including *.template.ko.md and diagram.data.template.ko.json by default; use English templates only when requested or required.
7. scripts/render-planning-map.mjs when rendering diagram.svg from diagram.data.json.
8. assets/preview.template.html and scripts/build-preview.mjs when generating preview.html.
9. assets/sources.template.ko.md by default when live research is needed and the package needs a source ledger; use assets/sources.template.md only when requested or required.
10. references/flow-schema.md when the package is complex or a flow.json already exists.
11. 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.

• 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.

• 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.