pm-frontend-prototype

Product Manager Frontend High-Fidelity Prototype Skill

1. Objective

Based on the source code of an existing frontend project, create a high-fidelity, clickable prototype isolated from the formal business entry points, so that product managers can quickly view, demonstrate, and discuss product solutions.

Prioritize ensuring:

Consistency with the existing project style.
The page looks like a real product, not a temporary Demo.
Use mock data that fits the business.
Core flows are clickable.
Interactions can be used for requirements review.
The page is easy to continue modifying.
It can be run and previewed locally immediately.
By default, it does not affect the business pages and routes currently in use.

Unless the user explicitly requests it, do not treat the task as rebuilding the entire system from scratch.

When the current goal is a high-fidelity prototype, do not prioritize developing backend interfaces, production data pipelines, or complex architecture.

Default isolation conventions: First reuse the existing project's source code, layout, components, and visual rules, then implement in independent prototype pages, prototype routes, or feature directories. Do not modify the business pages in use, production entry points, or existing interface calls by default; this may be done only when the user explicitly requests "demonstrate directly on the original page" or "overlay the prototype onto the existing page."

2. Applicable Scenarios

Use this Skill when the user raises the following requirements:

Create independent prototype pages or routes based on the source code of an existing React, Vue, HTML, or other frontend project.
When the user explicitly requests it, demonstrate prototype interactions in an existing product page.
Add admin management pages, CRM pages, SaaS pages, operations backends, or business workbenches.
Turn static pages into clickable prototypes.
Add highly realistic mock data and interaction states.
Add or optimize tables, forms, filters, Tabs, drawers, modals, charts, detail pages, or business flows.
Extend new features according to the existing project style.
Do not develop the backend; first complete a high-fidelity Demo for review.
Optimize visual hierarchy, information density, responsiveness, or interaction feedback.

Common expressions:

Add a customer list page to the existing backend.
Add a business data dashboard according to the current project style.
Add a follow-up records module to the existing detail page.
Complete this page into a clickable prototype.
Add search, filter, status toggle, drawer, and modal interactions.
Optimize this existing page, but do not change the overall system style.

3. Inapplicable Scenarios

This Skill is not used by default in the following cases:

The user wants to create a brand-new product starting from an empty directory.
The user only needs a marketing website or landing page.
The user requests developing backend interfaces, databases, or production services.
The user needs a technical architecture document, not a prototype.
The user only requested generated visual images or static screenshots.
The current task is mainly requirements analysis or PRD writing.

If the current directory is empty, it should be explained that this Skill is mainly intended for existing projects, and the "Generate HTML High-Fidelity Prototype from Scratch Skill" should be used first.

IV. Core Principles

1. Inspect the project first, then start designing

Do not start writing code immediately after receiving the requirements.

First look for the product experience baseline in docs/product/ that corresponds to the current project and the current frontend (c-end/ or admin/). When a baseline exists, read the product terminology, navigation, page patterns, visual and interaction rules within it; it supplements the technical conventions of the project source code, but cannot replace the component library, routing, and data architecture.

If the user is launching the first version of the requirements, or the current feature exposes product rules that recur across pages but have not yet been defined, it is recommended to first use product-experience-foundation. An ordinary single-feature prototype must not arbitrarily create or rewrite the global product baseline.

First inspect the following in the existing project:

Adjacent pages.
Page layout framework.
Routing structure.
Component directory.
Shared Hooks and utility functions.
CSS variables.
Theme files.
Design Tokens.
Icon usage.
Table styles.
Form styles.
Modal and drawer styles.
Message and notification styles.
Current state management approach.

It is necessary to understand the existing project's:

Information density.
Page spacing.
Font hierarchy.
Corner radius size.
Color usage.
Navigation structure.
Component invocation approach.
Responsive strategy.

New content should look like a natural extension of the existing system, rather than a rebuilt system.

2. Prioritize reuse, do not reinvent the wheel

Prioritize reusing the project's existing:

Buttons.
Tables.
Forms.
Dropdown selects.
Date pickers.
Tab。
Modals.
Drawers.
Pagination.
Status tags.
Message toasts.
Page layout components.
Icons.
Utility functions.
Hook。
Design Tokens.

If the existing project already has the corresponding capabilities, do not create a second component system.

3. Isolate the prototype entry point by default

The prototype must be implemented based on the existing source code, rather than copying out a static website detached from the project; at the same time, it is isolated from the formal business entry point by default.

Prioritize one of the following approaches supported by the project's existing conventions:

An independent prototype route, for example /__prototype/<feature> or the project's existing demo route convention.
An independent prototype page or feature directory, with the entry point exposed only in the development/preview environment.
An explicit prototype entry point that does not change the default behavior of the original page, such as a query parameter, a development menu, or a temporary navigation item.

The prototype entry point must be able to reuse the real page shell and components, but must not replace the online entry point by default, modify existing business data, or affect other features. If the project already has prototype conventions, they must be followed first; if there are none, choose the approach with the least impact on production code that is easy to remove, and explain the entry point location in the final reply.

4. Treat the task as a product prototype, not a formal refactor

Prioritize serving:

Product review.
Business demos.
Requirements discussions.
Design and development alignment.
Rapid iteration.

Prefer direct, easy-to-modify implementation approaches.

Unless the existing project itself already adopts the corresponding pattern, do not introduce:

Large-scale global refactoring.
New architectural layers.
Heavyweight dependencies.
Over-abstraction.
Complex state machines.

5. Use mock data, do not rush to develop the backend

Unless the user explicitly requests it, do not:

Connect to real APIs.
Design backend APIs.
Create service layers.
Handle production data pipelines.

Keep mock data as close as possible to the page or current feature, so the product manager can adjust it easily.

Use local state to simulate:

Create.
Edit.
Delete.
Search.
Filter.
Sort.
Tab switching.
Selection.
State changes.
Drawer opening.
Modal opening.
Form submission.
Secondary confirmation.
Success message.
Error message.

6. The prototype must be clickable

In addition to the core main flow, supplement the states that the product manager needs to view during review according to requirements:

Search.
Filter.
Tab。
Selection.
Detail view.
Empty state.
Loading state.
Form validation.
Disabled state.
Secondary confirmation.
Success feedback.
Error feedback.
Return path.
Multi-step navigation.

If the requirements include multiple steps, the flow should be fully navigable rather than leaving multiple unrelated static pages.

7. Do not turn a business system into a marketing website

When what the user needs is an application, tool, backend, CRM, operations system, or business workbench:

Do not create oversized hero headlines.
Do not prioritize marketing-style visual compositions.
Do not use large amounts of decorative gradients and backgrounds as the main visual.
Do not significantly reduce information density for visual effects.
Do not replace real business controls with marketing cards.

V. Analysis required before coding

Before starting to write code, first extract from the requirements and project:

Product goals.
Target users or roles.
The core tasks users need to complete.
Pages that need to be added or modified.
Existing similar pages.
Page entry.
Main user flow.
Required fields.
Required states.
Permission differences across roles.
Interactions that must be implemented.
Mock data requirements.
Product assumptions.
Business rules that are not yet clarified.

Do not repeatedly ask for information the user has already provided.

If only presentation-layer details are missing, reasonable assumptions may be used.

Do not add core business rules on your own that would change the product scope.

VI. Project Inspection Process

Step 1: Identify the tech stack

Confirm:

Frontend framework.
Build tool.
Routing approach.
UI component library.
Icon library.
Styling approach.
State management approach.
Data request conventions.
Testing or preview approach.

Step 2: Find similar pages

Prioritize finding:

List pages of the same type.
Detail pages of the same type.
Forms of the same type.
Data dashboards of the same type.
Modals or drawers of the same type.
Business flows of the same type.
Empty, loading, and error states of the same type.

Use these pages as implementation references for the new page.

Step 3: Identify reusable content

List what should be reused this time:

Components.
Hook。
Design tokens.
Utility functions.
Page layouts.
Interaction patterns.

Avoid reimplementing existing capabilities.

Step 4: Understand the existing visual system

Check:

Page width.
Content area padding.
Module spacing.
Typography hierarchy.
Button styles.
Form density.
Table density.
Status colors.
Border styles.
Shadow usage.
Responsive breakpoints.

Step 5: Determine the prototype scope

Clarify:

Where the prototype entry is placed, and how it is isolated from the official entry.
Prototype pages or modules that need to be added.
Whether the user explicitly requests modifications to existing business pages.
Which interactions must be clickable.
Which data uses mock data.
Which states must be represented.
Which product assumptions are necessary.
Which product-level page patterns the current feature reuses.
Which new patterns are limited to the current feature, and which can be candidates for later promotion.

VII. Mock Data Standards

Mock data should use real business language.

Avoid using:

Test User。
Lorem ipsum。
Company A。
Sample Data。
User 001。

Mock data should cover as much as possible:

Different states.
Long text.
Missing values.
Warning messages.
Boundary data.
Different user decisions.
Different business stages.
Empty result.
Disabled action.

The purpose of mock data is not to fill the page, but to help product managers discover page and interaction issues.

Eight, Product Assumption Rules

AI may reasonably supplement presentation-layer details, such as:

Example names.
Example dates.
Example list data.
Empty state copy.
Success and error messages.
Common filter conditions.
Interaction patterns consistent with existing project conventions.

AI must not silently supplement the following core business logic:

New business states.
New role permissions.
New approval rules.
New business calculation methods.
New management modules.
New product scope.
New external system dependencies.

If assumptions must be made for demonstration purposes, they should be explained collectively in the final reply.

If a new interaction conflicts with the product experience baseline, it must not be silently overridden. The confirmed baseline should be followed, or the reason for the deviation and "whether the baseline needs to be written back" should be listed as items to be confirmed.

Nine, UI and Interaction Standards

1. Information Architecture

Prioritize ensuring:

Clear hierarchy.
Reasonable grouping.
Effective field selection.
Obvious primary actions.
Stable information density.
Pages that are easy to scan.

2. Control Selection

Prioritize using controls familiar to users:

Use icon buttons for tool operations.
Use segmented controls for mode switching.
Use switches or checkboxes for binary settings.
Use input boxes, sliders, or steppers for numeric settings.
Use menus or dropdowns for multiple options.
Use tabs for peer views.
Use drawers or modals for secondary tasks.

3. Card Usage

Do not nest cards within cards.

Cards are suitable for:

Repeated list items.
Modals.
Drawers.
Standalone tools.
Data groups that need clear framing.

Do not wrap every section of the page in a card.

4. Control Decoration

Avoid:

Decorative gradient glows.
Floating orbs.
Bokeh effects.
Meaningless SVG decorations.
Purely atmospheric backgrounds.
Marketing-style hero sections.
A single color tone filling the entire page.

After implementation, check the CSS; if the page is almost entirely one color family, adjust it appropriately.

Pay special attention to avoiding:

Large areas of purple or blue-purple gradients.
Large areas of beige or sand colors.
Large areas of dark blue or gray-blue.
Large areas of brown or orange.

5. Text and Layout Stability

Ensure text can adapt to:

Buttons.
Table cells.
Cards.
Sidebars.
Drawers.
Modals.
Mobile containers.

Use as needed:

Automatic line wrapping.
Text truncation.
Minimum and maximum width.
Stable grid.
aspect-ratio。
Container-relative sizing.

Do not dynamically scale fonts based on viewport width.

Keep letter spacing as 0。

6. Do not explain the prototype in the product interface

Do not display the following explanations on the page:

How this prototype was made.
Which temporary solutions were used.
How reviewers should understand the page.
Which interactions are simulated.

Only add explanations within the interface when the product itself genuinely needs help content.

10. Responsive scope

Desktop admin system

If the project is clearly a desktop admin system:

Prioritize doing the desktop side well.
Maintain stable information density.
Ensure it does not completely break on small screens.
Avoid making key actions inaccessible.
Avoid unnecessary horizontal scrolling as much as possible.

Mobile or consumer products

If the product is consumer-facing, mobile-first, or the user explicitly requests mobile:

Design the mobile layout and interactions just as carefully.
Check tap target sizes.
Check control clipping.
Check fixed-position elements.
Check safe spacing.
Check keyboard and form behavior as needed.

All pages need to be checked for

Text overlap.
Control clipping.
Hidden action entry points.
Page navigation breakpoints.
Horizontal overflow.
Unreadable tables.
Unusable drawers or modals.

11. Implementation process

Step 1: Read the existing project

Inspect the relevant project structure and similar pages.

Step 2: Clarify the prototype entry point and scope

Organize:

The location of the prototype pages, routes, or feature directory.
How it is isolated from the formal business entry point.
Existing pages or modules to modify only when the user explicitly requests it.
Core user flows.
Interactions that must be implemented.
Mock data states.
Reusable components.

Step 3: Implement an independent prototype following the existing project approach

Keep the existing:

Technical framework.
Component system.
Styling approach.
Routing approach.
Icons.
Utility functions.
State management conventions.

Step 4: Add mock data and interactions

Use local state to implement the complete flow needed for this review.

Step 5: Add necessary states

Only add states relevant to the current feature:

Empty state.
Loading state.
Validation state.
Disabled state.
Success state.
Error state.
Secondary confirmation.
No-permission state.
Data-unavailable state.

Step 6: Actually run the project

Start the existing local development service when needed.

Do not claim the task is complete before the project can be previewed.

Step 7: Perform visual and interaction checks