Agile PM Requirement Delivery Workflow (Agile PM Workflow)

Trigger Condition

When a user provides an initial idea or requirement description, guide them strictly in accordance with the following 7 steps. 🚨 Mandatory Instruction: You must execute step-by-step! Under no circumstances should you output results of all steps at once. After each step marked with [Wait for User Confirmation], you must stop outputting and wait for the user's response!

Step 1: Dialogue-Based Requirement Collection and Confirmation

Novices often struggle to articulate their requirements fully at once. The AI should first adopt a "flexible dialogue-based" approach to guide users, proactively assess, gently follow up, and summarize for confirmation. Do not rush to create files or folders until requirements are clear.

1.1 Receive Requirements

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.2 Core Dimension Assessment and Feedback

After receiving the user's initial requirements, you must directly present the assessment results of the following 7 key dimensions to the user, informing them which dimensions are clear and which are missing:

Background/Pain Points: Why is this being done? What problems exist in the current situation? (Mandatory)
Business Objectives: What results are expected after completion? (Mandatory)
Users and Scenarios: Who will use it and in what specific situations? (Mandatory)
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)
Existing Solutions: How do they currently solve this problem? (Important)
Business Rules: What restrictions or specific processes must be followed? (Important)
References/Competitors: Are there any benchmark products you like? (Bonus)

1.3 In-Depth Follow-Up and Multiple Rounds of Confirmation [Wait for User Confirmation]

🚨 Key Rule: Do not rush to summarize; you must conduct at least 3 rounds of in-depth heuristic follow-ups!

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.

Step 2: Project Initialization and Directory Structure Setup

Before starting to produce documents after requirements are confirmed, you must first help users establish a clear and standardized project folder structure to avoid file chaos later.

2.1 Establish Standard Directory Tree

Proactively create an exclusive root folder for the current project (e.g., named after the project), and create the following standard subdirectories within it:

```
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
```
).

2.2 Confirm Structure

Show the created directory structure to the user and inform them that subsequent deliverables will be stored in these corresponding folders by category.

Step 3: Output "Detailed First Draft PRD"

🚨 Key Rule: The initial PRD must also be very detailed, not just an empty framework.

3.1 Deliverable Content

Based on the confirmed information from Step 1, directly generate a detailed initial HTML format document (stored in the

prd/

directory). This initial PRD must have a complete document structure skeleton (refer to the standard directory in Section 6.1), and must deeply fill in the following parts:

Basic Project Information
Requirement Background and Objectives: Must include a four-column table (Objective Type, Description, Measurement Indicator, Target Value).
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.
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")

3.2 User Confirmation [Wait for User Confirmation]

Ask the user: "This is the detailed first version of the product's architecture and business logic. Is the direction and basic logic accurate? If there are no issues, we will proceed to [Prototype Design] to further clarify interaction details and possible missing features through specific interfaces." 🛑 Mandatory Pause: You must stop outputting here! Wait for the user's reply of approval before proceeding to Step 4.

Step 4: Produce High-Fidelity HTML Prototype (Core Verification Phase)

This is the most distinctive part of this workflow. Novices often discover logical loopholes (such as missing back buttons, unconsidered empty states) only after seeing specific interfaces.

4.1 Prototype Specifications

Produce single-file HTML prototypes with complete CSS styles.
Mandatory use of Tailwind CSS, adopting a modern, concise design style.
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
```
).
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.

4.2 💡 Highly Recommended to Use Impeccable Skills

Before generating the prototype, the AI must proactively recommend the industry's top frontend design instruction set to the user:

"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."

4.3 Prototype Review and Bidirectional Synchronous Update of PRD (Core Iteration Loop) [Wait for User Feedback]

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.

Step 5: Output Flowchart (Mermaid)

After the prototype is validated, the business logic is relatively clear, and it's time to draw the flowchart.

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

Step 6: Produce Final PRD (Embedded Prototype and Slices)

Integrate all results from the previous four steps to output the final detailed product requirement document.

6.1 Format and Structure Requirements

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.)

6.2 Detailed Plan Design (Independent Feature Modular Display)

The core part of the PRD is the "Detailed Plan". Must abandon traditional plain text or simple tables and switch to modular block layout.

For each core feature point, it must include the following three parts:

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

How to perform prototype slicing and sandbox locking?

Hash Route Positioning: Ensure the prototype HTML supports URL Hash routing (e.g.,
```
index.html#login
```
).
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.
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;
```
  .
Sandbox Isolation: Add the
```
sandbox="allow-scripts allow-same-origin"
```
attribute to the iframe.

HTML Structure Example:

html

<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>

6.3 Delivery Check

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.

Step 7: Version Iteration and Management (Version Control)

When the project enters the subsequent iteration phase (e.g., upgrading from

v1.0

v1.1

), strict structured version control must be implemented to ensure traceability of history without destroying previous versions.

7.1 File Physical Isolation and Replication

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.

7.2 Version Switcher in PRD Interface

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").

7.3 Change Log and Bidirectional Linkage

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.

agile-pm-workflow

NPX Install

Tags

SKILL.md Content (Chinese)