mingdui/AI-Product-Skills

Product Manager Frontend Hi-Fi Prototype Skill

1. Goal

Based on the source code of an existing frontend project, create a high-fidelity, clickable prototype that is isolated from the formal business entry points, allowing 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.
• Use of realistic business-related mock data.
• Clickable core flows.
• Interactions suitable for requirements review.
• Pages that are easy to modify further.
• Immediate local operation and preview.
• No impact on currently used business pages and routes by default.

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

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

Default Isolation Convention: First, reuse the source code, layout, components, and visual rules of the existing project. Then, implement the prototype in an independent prototype page, route, or feature directory. Do not modify currently used business pages, production entry points, or existing API calls by default; only do so if the user explicitly requests "to demonstrate directly on the original page" or "to 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 on existing product pages when explicitly requested by the user.
• Adding backend management pages, CRM pages, SaaS pages, operations backends, or business workstations.
• Transforming 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 flows.
• Extending new features following the existing project's style.
• Completing a high-fidelity demo for review without backend development.
• Optimizing visual hierarchy, information density, responsiveness, or interaction feedback.

Common expressions:

• Add a customer list page to the existing backend.
• Add a business data dashboard following the current project's style.
• Add a follow-up record module to an existing detail page.
• Complete this page to make it a clickable prototype.
• Add search, filter, status toggle, drawer, and modal interactions.
• Optimize this existing page without changing the overall system style.

---

3. Inapplicable Scenarios

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

• The user wants to start a brand new product from an empty directory.
• The user only needs a marketing website or landing page.
• The user requests development of backend APIs, databases, or production services.
• The user needs technical architecture documentation, not a prototype.
• The user only asks for generating visual images or static screenshots.
• The current task is primarily 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 start writing code immediately upon receiving a request.

First, check docs/product/ for the product experience baseline corresponding to the current project and front-end (c-end/ or admin/). If a baseline exists, read its product terminology, navigation, page patterns, visual and interaction rules; it supplements the technical conventions of the project source code 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 reveals cross-page patterns that are repeatedly encountered but not yet defined as product rules, it is recommended to use product-experience-foundation first. Ordinary single-feature prototypes must not arbitrarily create or rewrite the global product baseline.

First, inspect the existing project for:

• Adjacent pages.
• Page layout framework.
• Route structure.
• Component directory.
• Common 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.

Need to understand the existing project's:

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

New additions should look like a natural extension of the existing system, not a complete overhaul.

2. Prioritize Reuse, Don't Reinvent the Wheel

Prioritize reusing existing project components:

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

Do not create a second set of component systems if the existing project already has the capabilities.

3. Isolate Prototype Entry by Default

The prototype must be implemented based on the existing source code, not as a static website detached from the project; it must also be isolated from formal business entry points by default.

Prefer one of the following methods supported by the project's existing conventions:

• An independent prototype route, e.g., /__prototype/<feature> or an existing project demo route convention.
• 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, e.g., a query parameter, dev menu, or temporary navigation item.

The prototype entry should 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 has existing prototype conventions, they must be followed first; if not, choose the approach with the least impact on production code and that is easy to remove, and specify its location in the final response.

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

Prioritize:

• Product review.
• Business demonstration.
• Requirements discussion.
• Alignment between design and development.
• Rapid iteration.

Prioritize direct, easy-to-modify implementation methods.

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

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

5. Use Mock Data, Don't Rush to Develop Backend

Unless explicitly requested by the user, do not:

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

Place mock data close to the page or current feature to facilitate adjustments by the Product Manager.

Use local state to simulate:

• Add.
• Edit.
• Delete.
• Search.
• Filter.
• Sort.
• Tab switching.
• Selection.
• State changes.
• Drawer open.
• Modal open.
• 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 the Product Manager needs to review during evaluation 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 involves multiple steps, ensure the flow can be fully navigated, rather than leaving several unrelated static pages.

7. Don't Make a Business System Look Like a Marketing Website

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

• Do not create oversized hero section headlines.
• Do not prioritize marketing-style visual composition.
• Do not use extensive decorative gradients and backgrounds as primary visuals.
• Do not drastically reduce information density for the sake of visual effect.
• Do not replace genuine business controls with marketing-style cards.

---

5. Analysis Required Before Coding

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

• Product goal.
• Target user or role.
• Core tasks the user needs to accomplish.
• Pages to be added or modified.
• Existing similar pages.
• Page entry points.
• Main user flow.
• Necessary fields.
• Necessary states.
• Permission differences for different roles.
• Interactions that must be implemented.
• Mock data requirements.
• Product assumptions.
• Business rules not yet clarified.

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

If only presentation-layer details are missing, reasonable assumptions can be made.

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

---

6. Project Inspection Process

Step 1: Identify the Tech Stack

Confirm:

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

Step 2: Find Similar Pages

Prioritize finding:

• Same type of list page.
• Same type of detail page.
• Same type of form.
• Same type of data dashboard.
• Same type of modal or drawer.
• Same type of business process.
• Same type of empty, loading, and error states.

Use these pages as reference for implementing the new page.

Step 3: Identify Reusable Content

List what should be reused for this task:

• Components.
• Hooks.
• Design tokens.
• Utility functions.
• Page layout.
• Interaction patterns.

Avoid re-implementing 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 located and how it is isolated from the formal entry.
• The new prototype pages or modules needed.
• 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 reflected.
• Which product assumptions are necessary.
• Which product-level page patterns are reused by the current feature.
• Which new patterns are exclusive to the current feature and which could be candidates for future promotion.

---

7. 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 try to 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 discover page and interaction issues.

---

8. Product Assumption Rules

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

• Example names.
• Example dates.
• Example list data.
• Empty state text.
• Success and error messages.
• Common filter criteria.
• Interaction patterns consistent with the existing project.

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 assumptions must be made for the sake of demonstration, they should be collectively stated in the final response.

If a new interaction conflicts with the product experience baseline, it must not be silently overridden. Follow the confirmed baseline, or list the reason for deviation and "whether to backfill the baseline" as a pending confirmation item.

---

9. UI and Interaction Standards

1. Information Architecture

Prioritize:

• Clear hierarchy.
• Reasonable grouping.
• Effective field selection.
• Prominent primary actions.
• Consistent information density.
• Easy-to-scan pages.

2. Control Selection

Prioritize controls familiar to users:

• Tool actions use icon buttons.
• Mode switching uses segmented controls.
• Binary settings use toggle switches or checkboxes.
• Numeric settings use input boxes, sliders, or steppers.
• Multiple options use menus or dropdowns.
• Same-level views use Tabs.
• Secondary tasks use drawers or modals.

3. Card Usage

Avoid nesting cards within cards.

Cards are suitable for:

• Repeated list items.
• Modals.
• Drawers.
• Independent tools.
• Data groups needing clear bounding.

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

4. Decoration Control

Avoid:

• Decorative gradient orbs.
• Floating spheres.
• Bokeh effects.
• Meaningless SVG decorations.
• Purely ambient backgrounds.
• Marketing-style hero sections.
• Single color tones filling the page.

After implementation, check the CSS; if the page is almost entirely one color scheme, adjust 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:

• Word wrap.
• Text truncation.
• Min and max widths.
• Stable grids.
• aspect-ratio.
• Container-relative dimensions.

Do not dynamically scale fonts based on viewport width.

Unless required by the existing design system, keep letter-spacing at 0.

6. Don't Explain the Prototype Within the Product Interface

Do not display explanations on the page such as:

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

Only add in-interface explanations if the product itself genuinely needs help content.

---

10. Responsive Scope

Desktop Backend Systems

If the project is clearly a desktop backend:

• Prioritize getting the desktop version right.
• Maintain consistent information density.
• Ensure it doesn't completely break on smaller screens.
• Avoid key actions becoming inaccessible.
• Minimize unnecessary horizontal scrolling.

Mobile or Consumer Products

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

• Similarly, carefully design mobile layout and interactions.
• Check touch target sizes.
• Check for control cropping.
• Check fixed-position elements.
• Check safe area insets.
• Check keyboard and form behavior as needed.

All Pages Need to Check

• Text overlap.
• Control cropping.
• Hidden action entry points.
• Broken page navigation.
• Horizontal overflow.
• Unreadable tables.
• Unusable drawers or modals.

---

11. Implementation Process

Step 1: Read the Existing Project

Inspect relevant project structure and similar pages.

Step 2: Define Prototype Entry and Scope

Organize:

• Location of prototype pages, routes, or feature directories.
• Method of isolation from formal business entry points.
• Existing pages or modules to be modified only if explicitly requested by the user.
• Core user flow.
• Interactions that must be implemented.
• Mock data states.
• Reusable components.

Step 3: Implement Isolated Prototype Following Existing Project Methods

Maintain existing:

• Tech framework.
• Component system.
• Styling approach.
• 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.
• Unauthorized state.
• Data unavailable state.

Step 6: Actually Run the Project

Start the existing local development server if needed.

Do not declare the task complete before the project can be previewed.

Step 7: Perform Visual and Interaction Checks

Check:

• Page is not blank.
• Styles load correctly.
• Icons and resources display correctly.
• Text does not visibly overflow.
• Layout does not jump erratically.
• Core interactions work.
• Navigation has no dead ends.
• Responsive behavior is acceptable.

If possible, verify using browser inspection or screenshots.

---

12. Final Deliverables

Depending on the actual task, the final outcome should include:

• New or modified frontend source code.
• Independent prototype page, feature directory, or route, along with entry point instructions.
• Existing business pages modified only if explicitly requested by the user.
• Reused common components.
• Local mock data.
• Core clickable interactions.
• Related empty, loading, validation, disabled, success, and error states.
• Properly functioning page navigation.
• Instructions for running or previewing the project.
• Product assumption notes.
• A list of business rules yet to be clarified.
• If demo.md is created, record review conclusions and pending items; it serves only as a handover marker and does not replace the project's own engineering artifacts.

Unless it helps with running or reviewing, do not create extensive additional documentation or architecture files.

---

13. Completion Criteria

The prototype is considered complete only when the following conditions are met:

• The prototype page or module exists in the current project and is isolated from formal business entry points (unless the user explicitly requested to override the original entry point).
• The visual style is consistent with the existing project.
• Existing components and design tokens have been reasonably reused.
• The core user flow can be completed from start to finish.
• Every major action has clear feedback.
• Page navigation has no dead ends.
• Mock data updates after key actions.
• Relevant page states are reflected.
• Text does not visibly overflow.
• The project runs locally without blocking errors.
• The confirmed product scope has not been arbitrarily expanded.
• The final response clearly states product assumptions and pending rules.

---

14. Final Response Requirements

After completion, explain in a way that is easy for the Product Manager to understand:

• Which pages, modules, and flows were added or modified.
• The location of the prototype entry point and how it is isolated from the formal business entry point.
• Which interactions are now clickable.
• Which mock data and page states were added.
• Which existing components and project conventions were reused.
• What product assumptions were made.
• Which business rules are still pending confirmation.
• How to run or preview the prototype.
• Which visual and interaction checks were completed.
• Which product experience baselines were reused; if repeated new patterns appear, explain whether they are only candidates and have not been abstracted into global rules until confirmed.
• After review confirmation, implementation will be done by development based on the prototype; do not fake engineering artifacts during the prototype phase, nor arbitrarily implement production code.

The final response should be concise, focusing on the content the Product Manager needs to review.