Product Manager Frontend High-Fidelity Prototype Skill

1. Objective

Create high-fidelity, clickable prototypes isolated from the official business entry, based on the source code of an existing frontend project, enabling product managers to quickly view, demonstrate, and discuss product proposals.

Prioritize:

Consistency with the existing project's style.
Pages that look like a real product, not a temporary demo.
Using mock data that aligns with the business.
Core flows that are clickable.
Interactions that can be used for requirements review.
Pages that are easy to modify further.
Immediate local run and preview capability.
Default avoidance of impacting in-use business pages and routes.

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

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

Default Isolation Convention: First, reuse the existing project's source code, layouts, components, and visual rules, then implement the prototype within independent prototype pages, routes, or feature directories. Do not modify in-use business pages, production entry points, or existing API calls by default; only do so if 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 requests the following:

Creating independent prototype pages or routes based on existing React, Vue, HTML, or other frontend project source code.
Demonstrating prototype interactions within existing product pages, when the user explicitly requests it.
Adding backend management pages, CRM pages, SaaS pages, operations dashboards, or business workspaces.
Converting static pages into clickable prototypes.
Adding realistic mock data and interaction states.
Adding or optimizing tables, forms, filters, tabs, drawers, modals, charts, detail pages, or business workflows.
Extending new features consistent with the existing project's style.
Completing high-fidelity demos for review without backend development.
Optimizing visual hierarchy, information density, responsiveness, or interaction feedback.

Common expressions:

Add a customer list page within the existing backend.
Add a business data dashboard consistent with the current project's style.
Add a follow-up record module to an 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. Non-Applicable Scenarios

Do not use this skill by default in the following situations:

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 the development of backend APIs, databases, or production services.
The user needs technical architecture documentation, not a prototype.
The user only wants to generate visual images or static screenshots.
The current task primarily involves requirements analysis or PRD writing.

If the current directory is empty, explain that this skill is mainly for existing projects and prioritize using the "Generate HTML High-Fidelity Prototype from Scratch Skill."

4. Core Principles

1. Inspect the Project First, Then Start Designing

Do not immediately write code upon receiving a requirement.

First, check docs/product/ for the product experience baseline corresponding to the current project and frontend (c-end/ or admin/). If the baseline exists, read its product terminology, navigation, page patterns, visual and interaction rules; it supplements the project source code's technical conventions but does not replace the component library, routing, or data architecture.

If the user is initiating the first version of requirements, or if the current feature exposes cross-page patterns that are repeatedly occurring but have no defined product rules, consider using product-experience-foundation first. Do not create or rewrite global product baselines for ordinary single-feature prototypes.

First, inspect the existing project for:

Adjacent pages.
Page layout frameworks.
Routing structure.
Component directories.
Common hooks and utility functions.
CSS variables.
Theme files.
Design tokens.
Icon usage patterns.
Table styles.
Form styles.
Modal and drawer styles.
Message and notification styles.
Current state management approach.

Understand the existing project's:

Information density.
Page spacing.
Typographic hierarchy.
Border radius sizes.
Color usage patterns.
Navigation structure.
Component invocation patterns.
Responsive strategy.

New additions should look like natural extensions of the existing system, not a reimplementation.

2. Prioritize Reuse, Do Not Reinvent the Wheel

Reuse the project's existing components and patterns first:

Buttons.
Tables.
Forms.
Dropdowns.
Date pickers.
Tabs.
Modals.
Drawers.
Pagination.
Status tags.
Message prompts.
Page layout components.
Icons.
Utility functions.
Hooks.
Design tokens.

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

3. Isolate the Prototype Entry by Default

The prototype must be implemented based on the existing source code, not as a standalone static website copied out of the project; at the same time, it must be isolated from the official business entry by default.

Choose one of the following methods supported by the project's existing conventions, in order of preference:

An independent prototype route, e.g., /__prototype/<feature> or an existing demo route convention in the project.
An independent prototype page or feature directory, exposed only in development/preview environments.
An explicit prototype entry that does not alter the default behavior of the original page, such as a query parameter, a dev menu, or a temporary navigation item.

The prototype entry must be able to reuse the real page shell and components, but must not replace the online entry, modify existing business data, or affect other features by default. If the project already has prototype conventions, follow them first; if not, choose the approach with minimal impact on production code and easy removal, and specify the entry location in the final response.

4. Treat the Task as a Product Prototype, Not a Formal Refactoring

Prioritize serving:

Product reviews.
Business demonstrations.
Requirements discussions.
Design and development alignment.
Rapid iteration.

Prefer straightforward and easily modifiable implementation approaches.

Unless the existing project already uses the pattern, do not introduce:

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

5. Use Mock Data, Do Not Rush to Develop Backend

Unless the user explicitly requests otherwise, do not:

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

Place mock data close to the page or feature for easy adjustment by the product manager.

Use local state to simulate:

Create.
Edit.
Delete.
Search.
Filter.
Sort.
Tab switching.
Selection.
State changes.
Drawer opening.
Modal opening.
Form submission.
Confirmation dialogs.
Success messages.
Error messages.

6. The Prototype Must Be Clickable

In addition to the core main flow, supplement the states that a product manager needs to review based on requirements:

Search.
Filter.
Tabs.
Selection.
Detail view.
Empty state.
Loading state.
Form validation.
Disabled state.
Confirmation dialogs.
Success feedback.
Error feedback.
Return paths.
Multi-step navigation.

If the requirement includes multiple steps, ensure the flow can be fully navigated, rather than leaving multiple unrelated static pages.

7. Do Not Turn a Business System into a Marketing Website

When the user needs an application, tool, backend, CRM, operations system, or business workspace:

Do not create an oversized hero section headline.
Do not prioritize marketing-style visual composition.
Do not use excessive decorative gradients and backgrounds as primary visuals.
Do not significantly reduce information density for visual effect.
Do not replace real business controls with marketing cards.

5. Analysis Required Before Coding

Before writing code, extract the following from the requirements and the project:

Product goal.
Target users or roles.
Core tasks users need to accomplish.
Pages to be added or modified.
Existing similar pages.
Page entry points.
Primary user flow.
Required fields.
Required states.
Permission differences for different roles.
Interactions that must be implemented.
Mock data requirements.
Product assumptions.
Business rules that are not yet clear.

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

If only presentation-level details are missing, reasonable assumptions can be used.

Do not supplement core business rules that would change the product's scope.

6. Project Inspection Process

Step 1: Identify the Tech Stack

Confirm:

Frontend framework.
Build tool.
Routing approach.
UI component library.
Icon library.
Styling methodology.
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 workflows of the same type.
Empty, loading, and error states of the same type.

Use these pages as implementation references for new pages.

Step 3: Identify Reusable Content

List what should be reused for this task:

Components.
Hooks.
Design tokens.
Utility functions.
Page layouts.
Interaction patterns.

Avoid re-implementing existing capabilities.

Step 4: Understand the Existing Visual System

Check:

Page width.
Content area padding.
Module spacing.
Typographic 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 located and how it is isolated from the official entry.
New prototype pages or modules to be added.
Whether the user has explicitly requested 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-wide page patterns are reused by the current feature.
Which new patterns are limited to the current feature and which are candidates for future elevation.

7. Mock Data Standards

Mock data should use real business language.

Avoid:

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

Mock data should, where possible, cover:

Different states.
Long text.
Missing values.
Warning messages.
Edge cases.
Different user decisions.
Different business stages.
Empty results.
Disabled actions.

The purpose of mock data is not just to fill the page, but to help the product manager identify page and interaction issues.

8. Product Assumption Rules

The AI can reasonably supplement presentation-level details, such as:

Sample names.
Sample dates.
Sample list data.
Empty state copy.
Success and error messages.
Common filter criteria.
Interaction patterns consistent with the existing project's habits.

The 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 an assumption must be made for demonstration purposes, it should be explicitly stated in the final response.

If a new interaction conflicts with the product experience baseline, do not silently override. Follow the confirmed baseline, or list the reason for deviation and whether it needs to be written back to the baseline as an item to be confirmed.

9. UI and Interaction Standards

1. Information Architecture

Prioritize:

Clear hierarchy.
Reasonable grouping.
Effective field selection.
Prominent primary actions.
Consistent information density.
Easy scannability.

2. Control Selection

Prefer controls familiar to users:

Tool operations use icon buttons.
Mode switching uses segmented controls.
Binary settings use switches or checkboxes.
Numeric settings use input fields, sliders, or steppers.
Multi-options use menus or dropdowns.
Peer views use tabs.
Secondary tasks use drawers or modals.

3. Card Usage

Avoid card nesting.

Cards are suitable for:

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

Do not wrap every page block as a card.

4. Control Decorations

Avoid:

Decorative gradient light blobs.
Floating spheres.
Bokeh effects.
Meaningless SVG decorations.
Purely ambient 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 scheme, adjust accordingly.

Pay special attention to avoiding:

Large areas of purple or blue-violet 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 fits within:

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

Use as needed:

Automatic text wrapping.
Text truncation.
Minimum and maximum widths.
Stable grids.
aspect-ratio.
Container-relative dimensions.

Do not dynamically scale fonts based on viewport width.

Unless the existing design system requires it, keep letter spacing at 0.

6. Do Not Explain the Prototype Within the Product Interface

Do not display the following within the page:

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

Only add explanatory content within the interface if the product itself genuinely requires it.

10. Responsive Scope

Desktop Backend Systems

If the project is clearly a desktop backend system:

Prioritize getting the desktop version right.
Maintain consistent information density.
Ensure it does not completely break on small screens.
Avoid making critical actions inaccessible.
Avoid unnecessary horizontal scrolling where 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 touch target sizes.
Check for control clipping.
Check fixed positioning elements.
Check safe area spacing.
Check keyboard and form behavior as needed.

All Pages Need to Check

Text overlap.
Control clipping.
Action entry points hidden.
Page navigation breakpoints.
Horizontal overflow.
Tables becoming unreadable.
Drawers or modals becoming unusable.

11. Implementation Process

Step 1: Read the Existing Project

Check the relevant project structure and similar pages.

Step 2: Clarify Prototype Entry and Scope

Organize:

Location of prototype pages, routes, or feature directories.
Method of isolation from the official business entry.
Existing pages or modules to modify only when the user explicitly requests.
Core user flow.
Interactions that must be implemented.
Mock data states.
Reusable components.

Step 3: Implement the Independent Prototype Following Existing Project Patterns

Maintain existing:

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

Step 4: Add Mock Data and Interactions

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

Step 5: Supplement Necessary States

Only add states relevant to the current feature:

Empty state.
Loading state.
Validation state.
Disabled state.
Success state.
Error state.
Confirmation dialogs.
No permission state.
Data unavailable state.

Step 6: Actually Run the Project

If necessary, start the existing local development server.

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

Step 7: Perform Visual and Interaction Checks