Prd Maker

@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 planning package that builds layer by layer: PRD → feature specification → user flow → low-fidelity wireframe, plus diagram, preview, and source log.

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.

• Create or update planning folders under .hyper/prd/[slug]/ from short product ideas, feature requests, or initiative notes.
• Produce a layered planning chain: prd.md sets product truth, feature-spec.md turns it into buildable behavior, user-flow.md validates user paths, and wireframe.md describes low-fidelity screen structure.
• Add review helpers around that chain: diagram.md, diagram.data.json, rendered diagram.svg, local preview.html, sources.md, and optional flow.json for complex work.
• Keep assumptions, open questions, scope decisions, and evidence visible instead of pretending the idea is fully specified.

Use prd-maker when the main output is a stored product planning package, PRD, feature specification, user flow, low-fidelity wireframe, planning diagram, 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 .hyper/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
• the user needs final visual UI design rather than low-fidelity structure

Positive examples:

• "Create a PRD, feature spec, user flow, and low-fi wireframe for team inbox assignments."
• "Make a ManyFast-style planning package for a billing retry feature before implementation."
• "Turn this app idea into layered docs: PRD first, then functional spec, user flow, and wireframe."
• "Update the existing onboarding PRD and propagate the change into the spec, flow, and wireframes."

Negative examples:

• "Research how competitors handle onboarding."
• "Implement the billing retry flow."
• "Rewrite this support runbook."
• "Make final polished UI mockups in our brand style."

Boundary examples:

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

• New planning package folders under .hyper/prd/[slug]/
• Existing package updates under .hyper/prd/[slug]/
• prd.md product requirements and product decision record
• feature-spec.md functional behavior, acceptance criteria, states, permissions, analytics, rollout notes
• user-flow.md actor journeys, entry/exit points, happy paths, alternate paths, and error/empty states
• wireframe.md text-based low-fidelity screen inventory, layout blocks, states, and component notes
• diagram.md planning map source, diagram.data.json node data, and rendered diagram.svg
• preview.html browser-viewable package preview generated from package files and assets/preview.template.html
• sources.md evidence, query, provided-context, and gap log
• flow.json phase tracking for complex multi-session packages

Classify before writing files:

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.

Default package 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 is the product source of truth: problem, goals, scope, requirements, metrics, risks, dependencies, open questions, and change history.
• feature-spec.md translates PRD requirements into functional behavior, acceptance criteria, states, permissions, errors, analytics, and rollout notes.
• user-flow.md turns user-facing feature behavior into actor journeys, entry/exit points, decision points, alternate paths, empty/error states, and handoffs.
• wireframe.md maps flows to low-fidelity screen structure, layout blocks, component notes, and unresolved design/product questions.
• diagram.md contains a 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.
• 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, source notes, 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.

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/prd-sections.md when drafting or updating prd.md.
5. references/planning-package.md when drafting feature-spec.md, user-flow.md, wireframe.md, diagram.md, or preview.html.
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.

Direct package path

Tracked package path

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 PRD as the product truth, the feature spec as the behavior contract, the user flow as path validation, and the wireframe as low-fidelity screen structure.
• 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.

• Package files exist in the expected .hyper/prd/[slug]/ folder and match create/update mode.
• PRD decisions trace forward into feature-spec.md, user-flow.md, wireframe.md, and the planning diagram.
• sources.md records provided context, research evidence, or a clear reason external research was skipped.
• diagram.data.json, diagram.svg, and preview.html are regenerated when package content changes.
• Open questions, assumptions, risks, and validation gaps remain visible instead of being silently resolved.

• Complexity classified before writing.
• Every package stored under .hyper/prd/[slug]/ with ASCII kebab-case slug preferred.
• New packages include prd.md, feature-spec.md, user-flow.md, wireframe.md, diagram.md, diagram.data.json, diagram.svg, preview.html, and sources.md.
• PRD includes goals, scope, non-goals, requirements, metrics, risks/dependencies, open questions, and change history.
• Feature spec includes functional requirements, acceptance criteria, states, errors, permissions, analytics, and rollout notes when relevant.
• User flow includes actors, entry points, happy paths, alternate paths, edge/error states, and exit points.
• Wireframe includes screen inventory, layout blocks, component notes, state variants, and unresolved visual/product questions.
• Diagram includes a central initiative node, first-level planning branches, second-level requirement/flow/screen nodes, and open gaps.
• 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 downstream feature spec, user flow, wireframe, diagram, and preview when making a new package.
• Writing downstream artifacts before PRD decisions are clear enough to derive from.
• 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.