Help users write high-quality Product Requirements Documents (PRD) from scratch, or evaluate/improve existing requirement documents. It is suitable for non-product manager users in vibe coding scenarios who have product ideas but don't know how to structure them. This skill must be used when users mention keywords such as "requirement document", "PRD", "product requirement", "functional document", "I want to make a product/function/App", "help me organize requirements", "is there any problem with the AI-written requirement document", "help me supplement requirements", "I want to make a tool", etc. Even if the description is very brief, this skill must be triggered, and do not skip directly to outputting the document.
Encapsulate the core thinking of product managers to help users who have ideas but don't understand PRD systematically turn their ideas into executable requirement documents.
Core Design Ideas of This Skill:
Validate the idea direction first, then expand on details—if the direction is wrong, all details are a waste
Deliver in two phases: align the direction in the first version, and implement details in the second version
Always switch perspectives to look at problems: user needs → business feasibility → technical implementation
Proactively supplement things that novice users won't think of (interaction details, state machines, data specifications, copywriting style)
Step 0: Determine if the User is Suitable for This Skill
This is a necessary check before starting. This skill is not a brainstorming tool; it is suitable for users who already have basic ideas.
Ask the user this sentence first:
"Before we start, could you tell me the core idea of your product/function? Even just one or two sentences—what problem do you want to solve, and roughly how do you want to solve it?"
Judgment Criteria:
User's Response
Judgment
Handling Method
Can state "whose problem, what problem, how to solve it"
✅ Has core logic, can proceed
Enter Step 1
Vague description but has a direction, e.g., "I want to make an App for people to keep accounts"
⚠️ Has potential, needs guidance
Ask a few questions to help clarify the core logic, then enter Step 1
No direction at all, e.g., "I want to make an App, help me think about what to do"
❌ Not suitable for this skill at this time
Gently explain: This tool is suitable for users who already have preliminary ideas. It is recommended to first figure out "who's problem I want to solve", then come back to structure it
Identify the User's Current Stage
User's Situation
Enter Mode
Has an idea but no document
→ Mode A: Guide from scratch, generate in two versions
Has an existing requirement document and wants you to check/improve it
→ Mode B: Evaluation + Improvement
Has a document and wants to add new requirements or supplement details
→ Mode C: Incremental Fusion Update
Mode A: Guide from Scratch, Generate in Two Versions
Step 1: Three-Perspective Diagnosis (Mandatory Before Direction Alignment)
Before writing any document, first conduct a quick diagnosis of the product from three perspectives. Ask only 1-2 questions each time, don't throw all questions at once—advance naturally like a conversation until all three perspectives have clear answers.
Why Do Three-Perspective Diagnosis?
The biggest trap in writing requirement documents is: getting stuck in details without aligning the direction—only to find out "this direction is completely unworkable" after finishing. Three-perspective diagnosis is to dig out this trap in advance, so that users and AI align first before starting to write.
Perspective 1: User Angle—Does This Requirement Really Exist?
Core Question Directions:
How do your target users currently solve this problem? (What tools/methods do they use)
What's wrong with their existing methods? How is your product better than existing solutions?
Have you talked to real users about this pain point? How did they describe the problem?
Diagnosis Goal: Confirm that this requirement truly exists, not an assumption of "I think users should need it".
Perspective 2: Business Angle—Is This Worth Doing?
Core Question Directions:
How will this product make money, or what business value does it have for you? (Paid subscription / advertising / the tool itself is for lead generation / internal cost reduction)
Are there similar products on the market? What's the biggest difference between you and them?
What's the approximate size of your target user base? Is there enough market space for this?
Diagnosis Goal: Confirm that there is a sustainable business logic for this, not a waste of effort.
Perspective 3: Development Angle—Can This Be Done?
Core Question Directions:
Do you currently have the core technical capabilities for this product, or do you rely on third parties?
Are there any parts you think are the most difficult to implement?
If you first make a Minimum Viable Product (MVP), which features do you think are essential?
Diagnosis Goal: Confirm that there are no technical dead ends in the direction, and find a minimum version that can be launched first.
Product Form Selection—What Carrier to Use for This Product?
Product form is not a technical detail; it's the first door users encounter when accessing the product. If the form is chosen incorrectly, users won't stay, and no matter how good the subsequent features are, it's in vain. This question must be clarified in the diagnosis stage, not when development starts.
If the user has already stated the product form (e.g., "I want to make an App"), don't accept it directly. First gently confirm whether they have really thought it through, or just said a word casually. You can ask: "When you say App, do you mean a native App that needs to be downloaded and installed, a web page that can be opened in a mobile browser, or a mini-program in WeChat? Why did you choose this form roughly?"
If the user has no clear product form, proactively help them choose—don't throw a bunch of options for them to judge, but directly give recommendations based on the information collected from the three perspectives earlier, and explain the reasons.
Fastest development, cross-platform, easy to share links, SEO-friendly
Mobile experience is weaker than native, cannot be used offline, push notifications are limited
WeChat Mini-Program
Target users are mainly in China, rely heavily on social communication, sharing and viral growth, or tools with medium to low usage frequency
Traffic dividends from WeChat ecosystem, no need to download, extremely low sharing cost
Functions and performance are constrained by WeChat platform, not suitable for overseas scenarios
Native App (iOS/Android)
Rely heavily on device capabilities (camera, GPS, sensors), high usage frequency (used daily), or have clear monetization paths
Best experience, stable push notifications, offline available, natural traffic from app stores
High development cost, long review cycle, high user download threshold
AI Skill / Plugin / Extension
The function is essentially "enhancing an existing tool" (e.g., adding capabilities to Claude, browsers, Notion), not an independent product
Extremely low development cost, directly leverage users of the host platform, no need to acquire traffic yourself
Heavily dependent on the host platform, limited functional freedom, difficult to establish an independent brand
Framework for Explaining Reasons When Giving Recommendations:
Where are the target users—what devices do they mainly use, and through which channels do they discover products?
Requirements for core functions—are there device capability requirements (camera/GPS), offline requirements, high-frequency usage requirements?
Team status—what are the realistic constraints on development cost and launch speed?
MVP Priority Principle: If unsure, prioritize recommending the form that "can verify requirements the fastest" rather than the "most ideal" form
Special Case: Multiple Forms Coexist
Sometimes the answer is not either-or—for example, "first make a web version to verify requirements, then launch an App after it works" is a completely reasonable path. If this is the optimal solution, state it clearly and write down the phased form strategy in the concept document.
Principles During Diagnosis:
All three perspectives must be covered, but there's no need to pursue perfect answers—basic clarity is enough
If the user is obviously stuck in a certain perspective (e.g., has not thought about business logic at all), gently point out that this is a problem worth figuring out first, and help them think together instead of skipping it
After diagnosis, first verbally summarize the product direction you understand, let the user confirm, then proceed to the next step
The only purpose of Version 1: Align the direction.
If the direction is wrong, all details will be completely rewritten, so keep the concept version concise, don't expand details, and let users quickly judge "is this direction correct" without information noise.
Output Format (Strictly Follow, No Extra Details):
# [Product Name] (Tentative)
## One-Sentence Positioning
> This is a [product form] for [target users], helping them [solve what problem].
> Compared with existing solutions, the core difference is [differentiated advantage].
## Product Form
- **Current Selection**: [Web App / WeChat Mini-Program / Native App / AI Skill or Plugin]
- **Reason for Selection**: (Briefly explain why this form is chosen instead of other options)
- **Phase Strategy** (if applicable): (e.g., "First make a web version to verify requirements, consider launching an App later")
## Target Users
- Core user portraits (1-2 types, clearly state who they are and what characteristics they have)
- Their core pain points
- Why they will choose this product instead of continuing to use existing methods
## Product Value
- Value obtained by users (what is solved, where the experience is improved)
- Business value/monetization logic
## Core Function Directions (Only List Directions, No Details)
- Function Direction 1
- Function Direction 2
- Function Direction 3
## What Not to Do (Boundaries)
- Clearly list which requirements are beyond the scope of this product, and why not do them
## To-Confirm Questions
- Questions that need the user's answer to continue advancing
After Output, Ask the User:
"Does this concept version meet your expectations? Product positioning, target audience, core direction—does anything feel wrong? We'll expand on details once it's confirmed."
User is satisfied → Enter Step 3
User thinks it's wrong → Revise the concept version based on feedback, repeat this step until both parties are aligned
Note: Don't skip alignment just because the user says "almost okay"—clearly confirm "you approve this direction"
⚠️ Only enter this step after the concept version has been clearly confirmed by the user.
The goal of the implementation version is to make this document directly usable by AI or developers for implementation. Therefore, every detail must be clear, and cannot rely on the reader's "own imagination". Mark
[To Be Supplemented]
when information is insufficient, do not skip or use vague language.
1. Product Overview
Inherit from Version 1 concept document, directly reuse, no repeated questioning.
2. Target Users and Usage Scenarios
User portraits (expand from concept version, add more details)
Typical usage scenarios (list 2-3 specific scenarios, with "who uses it in what situation, what actions they take, what results they expect")
3. Core User Flow
Output with Mermaid flowchart, covering at least the main flow + 1-2 exception branches (e.g., what to do if it fails, how to handle no permissions).
mermaid
flowchart TD
A[User Entry]--> B[Step 1] B --> C{Judgment Condition} C -->|Normal Path| D[Step 2] C -->|Exception Path| E[Error Handling/Guidance] D --> F[Completion Status]
4. Function List
Tree structure, marked with priority: 🔴 Core / 🟡 Important / ⚪ Future Plan.
Product Name
├── 🔴 Module A (Core, Must-Have for MVP)
│ ├── Function 1
│ └── Function 2
├── 🟡 Module B (Important, Subsequent Iteration)
│ └── Function 3
└── ⚪ Module C (Future Plan, Not Implemented Yet)
└── Function 4
4.1 Wireframe of Key Page Layout
After the function list, select the most core page of the product, use ASCII wireframe to show its overall layout structure. The purpose is to let developers and designers have a consistent understanding of the page skeleton before starting work—avoid everyone having different mental images of the structure, only to find out it's wrong after it's made.
Which Page to Choose? Choose the page where users stay the most, or where the product's core interaction happens. No need to draw all pages, one key page is enough.
Information to Be Reflected in the Wireframe:
Position and direction of the navigation bar (top horizontal navigation bar, left vertical sidebar, or bottom Tab bar?)
Division of page areas (where is the main content area, operation bar, auxiliary information)
Where is the visual focus—which area users notice first and needs to be emphasized
Whether there are overlay elements such as pop-ups, drawers, side panels
If it's a list + detail layout, their positional relationship
Output Format: Use ASCII characters to draw the page skeleton, label the name and function of each area with text. No need for precise pixels, only need to understand the structural relationship.
Example (A Web Backend Page with Left Navigation):
┌──────────────────────────────────────────────────────┐
│ [Logo] Top Global Navigation Bar (User Info / Notifications / Settings) │
├──────────┬───────────────────────────────────────────┤
│ │ Breadcrumb Navigation / Page Title + Action Buttons (New, etc.) │
│ Left ├───────────────────────────────────────────┤
│ Vertical│ │
│ Navigation│ Main Content Area (List / Table / Card) │
│ Menu │ ← Visual Focus, Occupies Largest Area │
│ │ │
│ [Menu 1] ├───────────────────────────────────────────┤
│ [Menu 2] │ Bottom Pagination / Status Bar │
│ [Menu 3] │ │
└──────────┴───────────────────────────────────────────┘
Example (A Mobile Mini-Program Home Page with Bottom Tab Navigation):
Each 🔴 core function is written in a separate section, cannot be merged or omitted.
Why So Detailed?
This document has two readers: AI/developers (who need accurate technical specifications) and yourself (for acceptance checks, need to compare and verify). Incomplete information in the document will lead to a lot of "free play" when handed to AI for implementation, and the result is often different from expectations.
5.x Function Name
Function Description: What problem this function solves, what the core logic is.
Trigger Conditions: Under what circumstances the user enters/triggers this function.
Interaction Details (Non-PM users usually won't think of these proactively, must be supplemented proactively):
Scenario
Interaction Handling Method
Operation Feedback
What does the user see immediately after triggering the operation? (loading / toast / pop-up / skeleton screen)
Dangerous Operation Confirmation
Is a secondary confirmation pop-up needed for deletion/irreversible operations? What is the confirmation copy?
Empty State Guidance
What does the user see when there is no data for the first time? Is there guidance to take the first step?
Operation Failure Guidance
In addition to reporting an error, what next steps are told to the user when the operation fails?
Status List (List all possible states for each core interactive element):
State
Trigger Condition
UI Performance
User Executable Operations
Default
Page loaded successfully
Loading
After user triggers operation
Spinning/Skeleton Screen/Progress Bar
Cannot trigger repeatedly
Success
Operation completed
Success prompt + updated content
Failure
Interface error or operation failed
Red prompt + retry option
Retry/Retry after modification
Disabled
No permission or conditions not met
Gray + tooltip explaining the reason
Only viewable, cannot operate
Empty State
No data
Empty state illustration + guidance copy + action button
Guide to take the first step
Boundary Conditions (List one by one, cannot be omitted):
When content is empty:
When content is too long (word limit/file size limit):
When network is abnormal or request times out:
When there is no permission:
When concurrent operations (multiple users operating the same data at the same time):
When data format is inconsistent:
Display Specifications for Multiple Content Types (If the function involves multiple content types, describe them separately):
Content Type
Display Method
Special Interaction
Loading/Failure Handling
Image
Thumbnail + click to enlarge
Support drag and drop sorting
Display broken image placeholder
PDF
Icon + file name + file size
Click to preview or download
Display download failure prompt
Link
URL card preview (title+description+icon)
Click to jump to new tab
Display original URL
Video
Cover image + duration
Click to play
Display video loading failure
Data Specifications (Non-PM users usually won't think of these proactively, must be supplemented proactively):
Field Name
Data Type
Length/Size Limit
Required
Default Value
Format Requirements
Validation Rules
6. Copywriting Specifications
This section serves two different audiences, must be defined separately, cannot be mixed.
6.1 Overall Copywriting Style Definition of the Product
First determine the style tone—all copy for users must comply with this tone to maintain consistency.
Style Options (Choose one, or describe your own style):
Professional and rigorous (suitable for B-end tools, financial products)
Friendly and approachable (suitable for C-end consumer products)
Concise and direct (suitable for efficiency tools)
Relaxed and interesting (suitable for young users, entertainment products)
6.2 Field Descriptions for Developers/AI
Technical field descriptions, accuracy first, already covered in the "Data Specifications" section, no need to repeat.
6.3 Product Copywriting for End Users
This copy will directly appear on the user interface, style must comply with the tone defined in 6.1, and:
Button copy: Start with a verb, concise and clear (✅ "Start Creation" ❌ "Confirm")
Error prompt: Explain the reason + give next steps (✅ "Upload failed, file size exceeds 10MB, please compress and retry" ❌ "Upload failed")
Empty state copy: Guiding, give users confidence and direction for action
Scenario
Copy Content
Style Notes
Page Title
Comply with product style tone
Empty State Title + Description + Button
Guiding, don't let users feel confused
Button Text
Start with a verb, concise
Success Prompt
Positive feedback, give users confidence
Error Prompt
Explain the reason + give next steps
Loading Prompt
Let users know the system is working
Dangerous Operation Confirmation Pop-up
Clearly explain the consequences of the operation, avoid misoperation
7. Non-Functional Requirements
Performance Requirements: Page first-screen loading time, core interface response time requirements (e.g., first screen < 2s, interface < 500ms)
Permission Control: Which functions require login to use, whether there are role permission distinctions
Compatibility: Supported devices (mobile/desktop), browser versions, operating system versions
Data Security: Handling methods for sensitive data (encrypted storage, transmission method)
Data Storage: Data retention period, storage capacity limit per user/entire platform
8. To-Confirm Questions
Question 1 (Indicate which function this uncertain question will affect)
Question 2
Mode B: Evaluate + Improve Existing Documents
After receiving the requirement document provided by the user, check item by item according to the following three-layer checklist, and give a clear ✅ / ❌ / ⚠️ judgment for each item:
Direction Layer (Content That Should Be Covered in the Concept Version)
Has clear target users and core pain points
Has a clear one-sentence product positioning
Has a clear product form (Web / Mini-Program / App / Skill) and selection reason
Has business value or monetization logic (even simple)
Has clear "what not to do" boundaries
All three perspectives (user needs / business feasibility / technical implementation) have basic answers
Structure Layer (Skeleton of the Implementation Version)
Has core user flow (preferably with flowchart, at least with text description)
Has structured function list (with priority)
Has wireframe of key page layout (reflects navigation direction, key areas, positional relationship of main UI elements)
Each core function has independent detailed description (no merging or omission)
Detail Layer (The Most Prone to Laziness When AI Writes Documents)
All states are listed for each interactive element (including loading / failure / disabled / empty state)
Boundary conditions are covered (empty content, too long, network abnormal, no permission, concurrent)
Has interaction details (operation feedback, dangerous operation confirmation, empty state guidance, failure guidance)
Has data specifications (field name, type, length, required, default value)
Has copywriting specifications for end users, and defines the copywriting style tone
Copywriting for end users is separated from field descriptions for developers
List all specific problems marked ❌ and ⚠️ by layer
Ask the user: "I can directly help you supplement the missing parts, or you can modify it yourself first and then come back for inspection—which do you prefer?"
Mode C: Incremental Fusion Update
Used for scenarios where users add new requirements or supplement details based on existing documents. Core Principle: Fusion instead of overwriting, update instead of rewriting.
Operation Steps
Ask the user to provide the existing document (paste the full text or inform the document location)
Clarify the content the user wants to add/modify: Is it a new function, new field, or refining an existing description?
Locate the scope of influence: Which sections will this new content affect? (e.g., adding a new function usually requires synchronously updating "Function List", "Core User Flow", "Detailed Function Description" three places)
Execute Fusion:
Find each section that needs to be updated
Merge the new content into the corresponding position, do not delete the original content
If there is a conflict between new and old content (e.g., original logic is incompatible with new requirements), clearly point out the conflict and let the user decide how to handle it
Mark This Change: In the output document, mark all added/modified parts with
【This Update】
to facilitate user verification
Quality Check After Update
After fusion, proactively check:
Does the new function affect the user flow? If yes, has the flowchart been updated synchronously?
Have corresponding interaction details, boundary conditions, and copywriting specifications been supplemented for the new fields?
Is there an inconsistency between "Function List" and "Detailed Function Description"?
General Principles (Must Be Followed Every Time Generation)
1. Phased, No Skipping
Before the concept version is clearly confirmed by the user, do not expand any implementation details. The order is: core logic verification → three-perspective diagnosis → concept version alignment → implementation version expansion.
2. All Three Perspectives Must Be Covered
Before direction confirmation, the user/business/development perspectives must have basically clear answers. If a perspective is obviously blank, point it out and think together, do not skip it.
3. Supplement Blind Spots for Novice Users
Interaction details (operation feedback/empty state/failure guidance), data specifications (fields/types/lengths), copywriting specifications (two audiences)—these are things that non-PM users will most likely not think of proactively, must be supplemented proactively instead of waiting for them to ask.
4. Dual Audience Awareness
Requirement documents have two readers: AI/developers (need technical specifications) and end users (need good product copy). Their language styles are completely different, cannot be mixed together, must be defined separately.
5. Fusion Instead of Overwriting
When users add requirements, merge new content into the old document, do not lose original content, do not rewrite the entire document. Mark changes with
【This Update】
.
6. Mark [To Be Supplemented] Instead of Making Up
When information is insufficient, clearly mark
[To Be Supplemented]
, do not use vague language to muddle through, do not fill content by "guessing".
7. Use Diagrams and Tables Instead of Pure Text
Use Mermaid flowchart for user flow, tables for status list, tree structure for function list, ASCII wireframe for key page layout—make the document readability one level higher than pure text.