• Accept user input in any form (a sentence, screenshot, sketch, plain language).
• Do not require users to fill out complex fixed templates to reduce cognitive barriers.

1. Background/Pain Points: Why is this being done? What problems exist in the current situation? (Mandatory)
2. Business Objectives: What results are expected after completion? (Mandatory)
3. Users and Scenarios: Who will use it and in what specific situations? (Mandatory)
4. Core User Journey: What is the key path for users from contact to achieving their goals? What touchpoints and pain points are there in between? (Mandatory)
5. Existing Solutions: How do they currently solve this problem? (Important)
6. Business Rules: What restrictions or specific processes must be followed? (Important)
7. References/Competitors: Are there any benchmark products you like? (Bonus)

• Follow-Up Method: Abandon rigid options (A/B/C), use open-ended, heuristic questions to guide users to think about the requirement from multiple perspectives and more comprehensively.
• Number of Follow-Ups: Each follow-up must include 3 to 5 questions.
• Cycle Mechanism: Based on the user's previous answer, dig out new blind spots and continue to follow up, conducting at least 3 rounds of dialogue.
• Final Confirmation: Only when you have a full understanding of all details of the requirement through multiple rounds of follow-ups, and the user clearly states "No more additions, we can start writing", can you conduct a structured retelling and proceed to the next step.
• 🛑 Mandatory Pause: You must stop outputting after each round of questions! Wait for the user's reply before proceeding to the next action.

• prd/

  : Used to store all product requirement documents (e.g.,

  prd_v1.0.html

  ).

• prototype/

  : Used to store all high-fidelity HTML prototype files.

• flowcharts/

  : Used to store Mermaid flowcharts or exported images.

• annex/

  : Used to store various attachments (e.g., original Excel/CSV data dictionaries, original requirement drafts, reference materials, etc.).

• templates/

  : Used to store workflow templates or reference files (e.g.,

  prd_template.md

  ).

prd/

1. Basic Project Information
2. Requirement Background and Objectives: Must include a four-column table (Objective Type, Description, Measurement Indicator, Target Value).
3. User Scenarios and Journey Map: Must use a table or clear structure to describe the User Journey Map, including: Phase, User Touchpoint, User Behavior, Pain Point/Emotion, Product Opportunity, with a strong sense of immersion.
4. Detailed Feature List and Basic Logic: Do not only list modules and names; must sort out the core operation mainline, preconditions, basic business rules, and data flow in detail. (Subsequent chapters such as modules with prototypes in the detailed plan, overall flowcharts, etc., can be left blank first and marked with "To be supplemented after prototype confirmation")

1. Produce single-file HTML prototypes with complete CSS styles.
2. Mandatory use of Tailwind CSS, adopting a modern, concise design style.
3. Must include key interaction states (e.g., default page, expanded pop-up, success prompt, etc.). Page switching can be achieved through simple native JavaScript or URL Hash (

   #page1

   ).
4. Sandbox Lock Support (Focus Mode): When writing native JavaScript, you must add URL parameter parsing logic (e.g.,

   ?focus=feature_id

   ). When in focus mode, lock or mask other irrelevant interaction areas (e.g., set

   pointer-events: none; opacity: 0.5

   ), allowing users to only operate the corresponding feature point. This is to meet the requirement of "only displaying the corresponding feature interaction" when embedding the prototype in the PRD later.

"To make the prototype achieve professional-level advanced UI effects, I strongly recommend using the design skill library provided by Impeccable. If you have installed instructions such as

frontend-design

or

teach-impeccable

in your editor (e.g., Trae/Cursor), please let me know, and I will call these professional frontend design specifications to generate a beautiful interface for you."

• Present the generated HTML code or preview to the user.
• Guide the user to think: "Looking at this interface, what do you think the prompt should be if the network is disconnected after the user clicks this button? Is the information display comprehensive enough?"
• 🛑 Mandatory Pause: You must stop outputting here! Wait for the user's feedback and modification suggestions.
• Modify the prototype based on the user's feedback.
• 🚨 Key Rule (Real-Time PRD Synchronization): Every time the user proposes modifications to the prototype (such as adding features, modifying interaction logic, adjusting page flow), the AI must synchronously update the corresponding "Detailed Plan" table in the second version (detailed version) of the PRD while modifying the HTML prototype. Not only update the logical description, but also ensure that the slice reference path is consistent with the latest prototype.
• Only when the user expresses "fully satisfied" or "can proceed to the next step" with the prototype can you proceed to Step 5.

1. Use Mermaid syntax (

   flowchart TD

   or

   sequenceDiagram

   ).
2. Focus on depicting: The user's core operation mainline, as well as the exception branches discovered during the prototype review.
3. Ensure there are no special characters in the code that would cause rendering errors (such as unescaped Chinese parentheses).

• Must be output in HTML format to ensure it can run independently.
• Typesetting and UI Specifications:
  • Dynamic UI Upgrade (Impeccable Skills): If the user installs Impeccable Skills during the workflow execution, you must call relevant instructions (such as

    /typeset

    ,

    /arrange

    ,

    /colorize

    ) when generating or updating the PRD to perform advanced UI upgrades on the PRD's typesetting and colors.
  • Table of Contents (TOC): A floating directory navigation must be provided on the left or top of the page for quick jumps.
  • Font Hierarchy and Spacing: Strictly distinguish between H1 (page title), H2 (chapter title), H3 (module title), set appropriate

    line-height

    (e.g., 1.6) and paragraph spacing (e.g.,

    margin-bottom: 1.5rem

    ) to ensure a comfortable reading experience.
• The PRD must be organized strictly in accordance with the following standard directory structure:
  1. Project Information and Version Records (reserved for a version switch dropdown menu in the upper right corner)
  2. I. Requirement Background (current problems, why do it now)
  3. II. Requirement Objectives (objective type, description, measurement indicator, target value)
  4. III. Users and Usage Scenarios (typical users and User Journey)
  5. IV. Requirement Feature List (skeleton and priority)
  6. V. Detailed Plan (with prototype sandbox slices, see Section 6.2 below)
  7. VI. Business Flowchart (Mermaid format)
  8. VII. Exception and Boundary Handling (disconnection, empty state, no permission, etc.)
  9. VIII. Data Tracking and Buried Points (optional)
  10. IX. Future Evolution Plan (Roadmap)
  11. X. Attachments (data dictionary/process standards, etc.)

1. Interaction Logic Flowchart: Use Mermaid to draw the specific interaction branches and exception flows of the feature.
2. Detailed Rule Description: Text description of trigger conditions, interaction feedback, exception handling (such as disconnection, empty data).
3. Focus Mode Sandbox Slice: Embed the corresponding prototype using

   <iframe>

   .

1. Hash Route Positioning: Ensure the prototype HTML supports URL Hash routing (e.g.,

   index.html#login

   ).
2. Focus Mode Parameter: Add the focus parameter to the iframe's src (e.g.,

   ?sandbox=true&focus=login

   ), and the prototype code will lock irrelevant features accordingly.
3. Size Control (Web vs Mobile):
   • Mobile prototype: Mandatorily set the iframe's width (e.g.,

     width: 375px; height: 812px;

     ), which can be scaled down via CSS

     transform: scale(0.7)

     .
   • Web/backend prototype: Use responsive width (e.g.,

     width: 100%; height: 600px;

     ).
   • Remove border: Add

     border: none; background: transparent;

     .
4. Sandbox Isolation: Add the

   sandbox="allow-scripts allow-same-origin"

   attribute to the iframe.

<div class="feature-module">
  <h3>Feature: User Login</h3>
  <div class="feature-content" style="display: flex; gap: 20px;">
    <div class="logic-rules" style="flex: 1;">
      <h4>Interaction Flowchart</h4>
      <div class="mermaid">
        flowchart TD
        ...
      </div>
      <h4>Rule Description</h4>
      <ul>
        <li><strong>Trigger Condition</strong>: ...</li>
        <li><strong>Interaction Feedback</strong>: ...</li>
      </ul>
    </div>
    <div class="sandbox-preview">
      <iframe src="../prototype.html?focus=login#login" style="width:375px; height:812px; border:none;" sandbox="allow-scripts allow-same-origin"></iframe>
    </div>
  </div>
</div>

• Includes a clear User Journey Map.
• In the detailed plan, each feature point has a corresponding Mermaid flowchart.
• In the detailed plan, each prototype sandbox has enabled Focus Mode that locks irrelevant features.
• Exception situations (disconnection, empty data, insufficient permissions) have been added to the document.

• Never directly overwrite historical versions.
• When iterating to

  v1.1

  , enter the

  prd/

  and

  prototype/

  folders, copy

  prd_v1.0.html

  and

  prototype_v1.0.html

  , and rename them to

  prd_v1.1.html

  and

  prototype_v1.1.html

  .
• All subsequent modifications are only made in the

  v1.1

  files, keeping

  v1.0

  as a historical snapshot.

• In the upper right corner of the generated PRD HTML page, a "Version Switch Dropdown Menu" must be added.
• Users can switch between different versions such as

  v1.0

  and

  v1.1

  with one click via the dropdown menu.
• Tip: If viewing a historical version, add a prominent warning banner at the top of the page (e.g., "You are viewing historical version v1.0, click here to go to the latest version v1.1").

• In the [Version Records] table of the new PRD, record in detail the specific feature points added, modified, or removed in this iteration.
• Strong Linkage Between PRD and Prototype: In

  prd_v1.1.html

  , all prototype slice paths embedded via iframe must be uniformly modified to point to

  ../prototype/prototype_v1.1.html

  to ensure rigorous correspondence between document and prototype versions.