Product PRD Prototype

Use this manual workflow to connect product intent, running UI evidence, prototype states, annotated screenshots, source-code landmarks, and an AI-implementable PRD.

Do not modify the user's application source unless they explicitly ask for implementation. Build prototype artifacts in an isolated workspace folder and save final deliverables under outputs/.

Require Delivery Mode Selection First

Treat delivery-mode selection as a blocking first gate. Before page discovery, source reading, product questioning, prototype work, or PRD work:

detect whether the user has explicitly selected one of the modes below;
if not, present the mode choices and wait for the user to choose;
do not silently choose a default and do not continue the workflow until a mode is confirmed;
record the confirmed mode in page-map.md, manifest.md, and any PRD or audit report.

Use this selection prompt:

开始前请选择本次交付模式：

A. 原页面交互原型
适合还没有明确新增/修改需求时；先高保真复刻当前页面及边界内的原有交互，不设计新需求。

B. 局部需求原型
适合已经有明确需求；高保真还原完整页面 UI，只完整设计和验证本次新增/修改流程。

C. 全量高保真原型
适合需要原页面及需求相关交互全部按定义边界完整复刻和验证。

D. 仅输出 PRD
完成页面分析、需求规则、连线标注图和 AI 可实施文档，不制作可点击原型。

E. 保真度审计
检查现有实现或原型与运行页面的差异，输出带连线的差异标注图，不主动设计或实现。

When the user has not provided a new or changed requirement, recommend A. Original Page Interaction Prototype, but still require explicit confirmation.

Route Optional Product Design Enhancement

After the user confirms the delivery mode and before page discovery, read references/product-design-integration.md. Treat Product Design as an optional, automatically selected enhancement, never as a runtime dependency.

Detect Product Design only from the skills exposed in the current session. Never inspect or depend on an installation path, plugin cache, or version.
Briefly announce an automatically selected enhancement in commentary and continue without asking for confirmation when it does not change scope or external state.
If the applicable Product Design skill is unavailable, incompatible, or fails, continue through the native fallback. Its absence is not an error and is not a reason to lower the delivery gates.
Ask before an action would expand scope, publish or share externally, modify application source, or introduce a materially different design direction. Do not install or suggest installing Product Design unless the user explicitly requested that plugin.
Keep this skill authoritative for the delivery mode, boundary, stable IDs, annotations, PRD, output contract, verification status, and final validation.

Original Page Interaction Prototype

Use when the user identifies a page but has not defined a new or changed requirement.
Reproduce the current page, its visible states, and every existing interaction within the declared page boundary.
Do not invent product goals, proposed states, change rules, or implementation requirements.
Deliver the high-fidelity interactive baseline prototype, interaction inventory, fidelity evidence, line-connected annotated screenshots, annotation map, and manifest.
Stop after the original-page prototype is delivered. Start requirement design only after the user later supplies a requirement and selects a requirement-oriented mode.

Scoped Prototype

Reproduce the entire target page UI at the same high-fidelity standard used by every other mode.
Fully reproduce and verify the new or changed interaction flows in scope.
Record existing interactions outside the requested flow and preserve their visible controls; simulate or document their boundary without cloning unrelated downstream pages.
Deliver an interactive prototype, line-connected annotated screenshots, PRD, and AI handoff.

Full-Fidelity Replica

Use only when the user explicitly asks for complete page replication, all interactions, or 1:1 fidelity.
Reproduce and verify every existing interaction inside the defined page boundary.
Deliver the same artifacts as Scoped Prototype with full coverage evidence.

PRD Only

Locate and understand the page, define changes, and write a decision-complete PRD.
Do not build a clickable prototype unless needed to resolve ambiguity.
Still deliver high-fidelity annotated screenshots with visible connector lines pointing to every requirement location or result state used by the PRD.

Fidelity Audit

Compare an existing implementation or prototype with the running page.
Report evidence, differences, interaction coverage, exact blockers, and high-fidelity line-connected annotated comparison screenshots; do not redesign or implement unless requested.

Apply Universal Visual Delivery Gates

Apply these gates to every mode. Delivery mode changes interaction coverage and document scope; it never lowers UI fidelity or annotation quality.

High-Fidelity UI Is Mandatory

Use the running page at the exact target viewport as the visual source of truth for existing UI.
Match all visible page geometry, typography, colors, assets, spacing, borders, radii, overlays, fixed regions, scrolling, and content wrapping needed by the selected mode.
Reproduce the entire target page UI in Original Page Interaction Prototype, Scoped Prototype, and Full-Fidelity Replica modes; do not crop the prototype down to the changed component.
In PRD Only mode, use the running page or a verified high-fidelity reproduction as the base for annotated requirement screenshots even though no clickable prototype is required.
In Fidelity Audit mode, use same-viewport running-page and implementation evidence; do not replace evidence with an approximate redraw.
Keep unannotated reference and diff captures under work/<slug>/evidence/; they are verification evidence, not final handoff screenshots.
Do not mark a deliverable final while the existing-page baseline is only Source-derived, Screenshot-derived, or Concept-only. Report high-fidelity verification blocked and request the missing runtime, data, font, asset, or platform prerequisite.

Line-Connected Annotations Are Mandatory

Every final screenshot delivered under outputs/<slug>/ must contain annotation cards plus visible connector lines to the exact UI trigger, changed region, result state, or audited difference.
A detached side list without visible connector lines is not an annotated screenshot and must not be delivered.
Use an SVG line, polyline, or path in a separate non-interactive overlay. Every connector must end in a filled or high-contrast circular marker containing its visible sequence number. Plain dots, empty rings, arrows, or unnumbered endpoints are invalid.
Number annotations from 1 in each screenshot. Numbers must be positive integers, unique, and consecutive with no gaps or duplicates.
Place the numbered circle on the exact UI target—not beside the annotation card, midway along the connector, or in nearby whitespace.
In requirement modes B, C, and D, the target must be the actual UI control, region, or result state being added or modified. In mode A, target the exact existing interaction trigger or result. In mode E, target the exact audited difference.
When one annotation describes multiple related targets, repeat the same sequence number at every connector endpoint associated with that card, or split independent targets into separate numbered annotations.
When an overlay hides the original trigger, connect to the visible result or primary action and explain the transition in the annotation.
Keep connectors visible in the exported PNG, not only in an uncaptured DOM layer.
Save outputs/<slug>/annotation-map.json mapping every final screenshot and annotation ID to its sequence, numbered-circle endpoint, target role, and target coordinates, selector, or named region.
Do not impose a mandatory annotation count, line count, or character limit; solve density through layout, grouping, connector routing, and additional screenshots.

Define The Page And Interaction Boundary

Use this default boundary unless the user expands it:

include the target page, its scrollable content, fixed regions, conditional states, and first-level overlays opened directly from it;
include nested controls inside an in-scope overlay;
for navigation to another business page, verify the trigger, route/parameters, and visible transition, but do not clone the destination unless it belongs to the requested flow;
treat payment, maps, media pickers, keyboards, customer service, permissions, and other platform capabilities as explicit capability boundaries when they cannot run in the standalone prototype;
never allow a navigation chain to silently expand the task into reproducing the rest of the product.

Record the boundary and any explicitly included downstream flow in work/<slug>/page-map.md.

Use Stable Requirement IDs

Assign stable identifiers and reuse them in the page map, prototype state URLs, annotations, PRD, implementation notes, and acceptance criteria:

REQ-01: product requirement or goal;
INT-01: interaction or behavior;
STATE-01A: observable state of an interaction;
AC-01-01: testable acceptance criterion.

Original Page Interaction Prototype mode requires INT and STATE IDs for current behavior, but does not require invented REQ or AC IDs. Requirement-oriented modes use all applicable ID types.

An annotation may describe one interaction or several related interactions. Do not impose a mandatory annotation count, line count, or character limit. Keep screenshots readable through layout, grouping, hierarchy, and additional state images when helpful. Put implementation detail in the PRD instead of requiring every detail to fit inside the screenshot.

Use Verification Statuses Honestly

Classify evidence for each relevant state:

Verified: exercised against the running target and compared at the target viewport;
Source-derived: derived from code, styles, and assets but not runtime-compared;
Screenshot-derived: reconstructed from supplied screenshots; behavior comes from code or product decisions;
Concept-only: proposed without enough runtime, screenshot, or source evidence.

Only call an existing state 1:1 when it is Verified and the fidelity gates pass. A missing runtime does not prevent a draft or working PRD, but it blocks final delivery in every mode and the output must carry the correct status.

Context Budget Mode

When the repository is large, a target file exceeds 800 lines, or the page has many components/interactions, read references/large-project-mode.md and follow its layered discovery workflow. Start with routes, metadata, and rg; do not load large files before confirming the target.

Workflow

1. Pass The Mode Gate

Confirm the delivery mode before taking any discovery or production action. If the mode is not explicit, ask and wait. If the user has no defined requirement, recommend Original Page Interaction Prototype without auto-selecting it.

After confirmation, select and record the optional enhancement route using references/product-design-integration.md. Do not inspect the target page before this point.

2. Locate And Confirm The Target Page

Accept a page title, business description, screenshot, browser state, URL, route, mini-program path, or file path. Search route manifests, page registries, titles, visible text, and likely filenames before asking the user.

When several candidates remain, show a concise candidate card with path, matching evidence, and recommendation. If one candidate is overwhelmingly correct, name it as the working target and proceed unless corrected.

3. Build The Page Map

Read the confirmed page, relevant styles, route config, imported child components, and participating overlays. Record:

information architecture and business modules;
visible and conditional elements;
interaction inventory and page boundary;
current handlers, state fields, components, APIs, and route parameters when visible;
default, loading, success, failure, empty, validation, permission, disabled, dismissed, and boundary states when applicable;
verification status and unresolved facts.

Create:

work/<slug>/page-map.md
work/<slug>/interaction-matrix.md

Record the selected execution path and enhancement decision in page-map.md. Keep Product Design evidence under the same declared page boundary.

Do not confuse an unresolved fact with a proposed product decision. Resolve facts from runtime or source where possible; ask only high-impact product questions that cannot be derived.

4. Define Product Intent, Scope, And Changes

In Original Page Interaction Prototype mode, describe current behavior only and do not infer a new requirement. For requirement-oriented modes, confirm or infer the goal, user, scenario, required actions, required states, and selected delivery mode. Separate:

current behavior;
target behavior;
behavior that must remain unchanged;
out-of-scope behavior;
data/API assumptions and dependencies.

Assign REQ, INT, STATE, and AC IDs as the scope becomes stable. For Scoped Prototype mode, clearly identify which interactions require full implementation and verification.

5. Confirm The UI Direction

Read references/ui-design-guidance.md. High-fidelity reproduction of the complete existing page is mandatory in every mode. In Original Page Interaction Prototype mode, skip proposed-design direction questions and reproduce the current running UI without redesigning it.

Use this priority:

explicit product preference;
current project UI style;
a business-appropriate modern direction when project style is not required or unavailable.

If style is unknown, ask whether to follow the current project. If the user does not answer, default to the project style and record the assumption.

6. Build The Prototype

Before reproducing an existing running page, read references/pixel-perfect-fidelity.md.

Use this structure:

work/<slug>/
├── page-map.md
├── interaction-matrix.md
├── fidelity-baseline.md
├── prototype/
│   └── index.html
└── evidence/

Write Baseline status: Verified in fidelity-baseline.md only after the complete existing page UI passes the same-viewport comparison gate. Any other status blocks final delivery.

Treat the rendered application as the source of truth for existing UI and behavior. Treat confirmed product decisions plus the selected UI direction as the source of truth for proposed states. Do not apply pixel-diff requirements to UI that does not yet exist in the running product.

Reproduce the entire page UI at high fidelity in every interactive prototype mode. Scoped Prototype limits the depth of non-target interactions, not the visual fidelity or page area.

Support deterministic URL states using stable IDs, for example:

?state=overview
?state=state-01a
?state=state-01b

Clicks and URL states must reach the same observable result. In Original Page Interaction Prototype mode, implement every current interaction within the page boundary without adding proposed behavior. In Scoped Prototype mode, implement all in-scope changed flows; in Full-Fidelity mode, implement every interaction within the page boundary.

7. Create Annotated Screenshots

Create at least one final annotated screenshot in every mode. Create additional overview, flow, state, or audit images as the product story requires. Keep the reproduced page at its verified viewport and place annotations in a separate non-interactive layer, preferably outside the page UI when space allows.

Every annotation card must have one or more visible connector lines ending in a numbered circle placed on the exact trigger, changed region, result, or audited difference. A side list with no lines, an unnumbered endpoint, or a number placed away from the true target fails this step. Use IDs to connect annotations to the page map and interaction matrix, and to the PRD when one exists. An annotation can explain multiple related interactions; repeat its sequence at all related endpoints or split independent targets into separate annotations. There is no mandatory number of annotations and no mandatory line or character limit.

Create annotation-map.json before export. For every screenshot, record the annotation ID, consecutive sequence number, connector type, numbered-circle endpoint, target role, and target coordinates, selector, or named region.

{
  "screenshots": [{
    "file": "price-annotated-overview.png",
    "annotations": [{
      "id": "INT-01",
      "sequence": 1,
      "endpoint_label": "1",
      "connector": "svg-path",
      "connector_visible": true,
      "endpoint_visible": true,
      "endpoint_style": "numbered-circle",
      "endpoint_label_visible": true,
      "target": {
        "x": 320,
        "y": 180,
        "role": "modified-ui-location",
        "verified": true
      }
    }]
  }]
}

8. Verify And Export

Use Browser or the available target runtime to exercise the applicable coverage:

identical viewport, data, scroll position, and loaded assets for existing-state comparison;
every required URL state;
every in-scope interaction and nested control;
every annotation card has a visible connector ending in a numbered circle at the intended target;
sequences start at 1 and remain unique and consecutive within each screenshot;
the number is visually centered inside the endpoint circle at the exact modified/interactive/audited UI location;
no detached side-list annotation is accepted;
annotation placement, connector routing, clipping, and readability;
output files and real PNG signatures.

Compare the complete existing page baseline against the running page in every mode. Evaluate proposed states against confirmed decisions, project UI patterns, interaction completeness, and acceptance criteria. Do not finalize delivery until the existing baseline is Verified; record exact blockers instead of claiming unsupported fidelity.

Export final artifacts to:

outputs/<slug>/
├── <slug>-prd.md
├── manifest.md
├── annotation-map.json
├── prototype/
│   └── index.html
├── <slug>-annotated-overview.png
└── <slug>-annotated-<state>.png

Every manifest.md must also contain these exact execution fields:

Product Design availability: available | unavailable | unknown
Execution path: product-design | native-fallback
Enhancement skill: url-to-code | image-to-code | audit | ideate | none
Fallback reason: none | unavailable | incompatible | failed
Runtime verification: verified | blocked
Design QA: passed | blocked | not-applicable

When a Product Design prototype-building path is selected, copy its final design-qa.md into the output directory. When Product Design audit is selected, keep current-run accepted screenshots under work/<slug>/evidence/ and identify that evidence directory in the fidelity audit report. Never record plugin cache paths or versions.

For Fidelity Audit mode, write <slug>-fidelity-audit.md; omit the PRD and clickable prototype when they are not part of the audit request, but always include line-connected annotated audit screenshots and annotation-map.json.

For Original Page Interaction Prototype mode, omit the PRD unless the user separately requests one. Always export the high-fidelity current-page prototype, line-connected annotated screenshots, annotation map, interaction evidence, and manifest.

For PRD Only mode, omit the clickable prototype but always export high-fidelity line-connected requirement screenshots and annotation-map.json for embedding in the PRD.

Include a reproducible local launch command or file entry point; do not rely only on a temporary localhost URL.

9. Write The AI-Implementable PRD

Skip this step in Original Page Interaction Prototype mode unless the user separately requests a current-state specification.

Before writing the PRD, read references/prd-template.md and use its required structure.

The PRD must be decision-complete and traceable. It must include:

a current/target/unchanged change matrix;
an implementation contract for every changed INT item;
state IDs, prototype URLs, annotated screenshot references, source landmarks, and acceptance IDs;
inputs, outputs, validation, loading, success, failure, empty, disabled, permission, and fallback rules when applicable;
exact file/component/method references when they remove ambiguity;
a traceability table connecting requirement, interaction, state, visual evidence, code location, and acceptance criteria;
unresolved decisions and assumptions, clearly separated from confirmed requirements.

Run scripts/validate_delivery.py against the finished artifact set. Fix errors before delivery; review warnings and document accepted exceptions.

10. Provide The Developer/AI Handoff

Skip implementation handoff in Original Page Interaction Prototype mode because no new or changed requirement has been defined.

End with a concise implementation prompt that tells the receiving AI to:

implement by INT ID;
preserve every Unchanged item;
reproduce each referenced STATE URL;
satisfy every mapped AC item;
run the project and verify the target runtime after implementation.

Output Checklist

Apply the checklist for the selected mode:

the user explicitly selected a delivery mode before discovery began;
target page and page boundary are confirmed or clearly assumed;
the complete existing page UI baseline is high-fidelity and Verified in every mode;
page map separates source facts, product decisions, and unresolved items;
stable IDs connect prototype states, annotations, current-state evidence, and—when a requirement exists—PRD rules, code landmarks, and acceptance criteria;
requirement-oriented modes include a change matrix with Current, Target, Unchanged, and Out of scope; Original Page Interaction Prototype mode records current behavior without inventing a change matrix;
existing states use an honest verification status;
Original Page Interaction Prototype coverage includes every current interaction inside the boundary and contains no invented requirement; Scoped Prototype coverage includes every changed flow; Full-Fidelity coverage includes every interaction inside the boundary;
proposed UI is evaluated as a proposal, not falsely pixel-diffed against the current product;
prototype entry point and deterministic state URLs are provided when the mode includes a prototype;
every mode includes final annotated screenshots whose connector lines end in consecutive numbered circles at the corresponding UI targets;
each number is positioned on the actual modified location, existing interaction target, result state, or audited difference required by the mode;
plain dots, empty rings, arrows, duplicate numbers, gaps, and numbers placed in nearby whitespace are absent;
detached side lists without connector lines are absent;
annotation-map.json covers every final screenshot and annotation;
unannotated fidelity evidence stays under work/<slug>/evidence/, not in final handoff outputs;
PRD is linked when the selected mode requires it;
manifest.md identifies artifacts, verification status, assumptions, and exceptions;
manifest.md records Product Design availability, execution path, enhancement, fallback reason, runtime verification, and Design QA using the required values;
Product Design absence never blocks the native workflow, while missing runtime evidence still blocks Verified and 1:1 claims;
application source was not modified unless the user explicitly requested implementation;
scripts/validate_delivery.py reports no unresolved errors.

Aster-mck/product-prd-prototype

Was ist product-prd-prototype?

In Ihrer bevorzugten KI fragen

Dokumentation