Generate complete PRD documents with SolarWire wireframes, Mermaid diagrams, and SVG exports. v2.0 - Enhanced with brainstorming best practices: project context exploration, incremental validation, spec self-review, and user review gates.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Generate complete PRD documents with SolarWire wireframes, Mermaid diagrams, and SVG exports. v2.0 - Enhanced with brainstorming best practices: project context exploration, incremental validation, spec self-review, and user review gates.
SolarWire PRD Generator v2.0
Configuration
Output Directory: .solarwire (modify here if needed)
Overview
This skill generates complete Product Requirements Documents (PRD), including:
Complete PRD Document (.md format)
Mermaid Flowcharts/Sequence Diagrams
SolarWire Wireframes (each page with complete information and element descriptions)
SVG Rendered Images (with notes and without notes versions)
Workflow
Phase 0: Exploration & Preparation
Goal: Understand project context and scope before collecting requirements
Step 0: Explore Project Context
Check existing code files (if any)
Check existing documentation (if any)
Check recent git commits (if any)
Understand project background and goals
Step 1: Scope Check
Determine if project needs to be decomposed into multiple sub-projects
If too large, help user decompose and select first sub-project
Decomposition criteria:
5 independent modules → needs decomposition
10 pages → needs decomposition
Multiple independent business flows → needs decomposition
Step 2: Multiple Approaches Comparison (Optional)
Provide 2-3 design approaches
Each with trade-off analysis
Recommend one approach
Phase 1: Requirements Collection
Goal: Confirm user requirements step by step, don't rush to generate
Step 3: Product Type Confirmation
What type of application is this?
- 📱 Mobile App
- 💻 Web Client
- ⚙️ Admin Dashboard
- 📺 Other (please describe)
Please select or describe your product type.
Step 4: Core Features Confirmation
What core features/pages does this product need?
For example:
- User Login/Register
- Home Page
- Profile Center
- Product List
- Order Management
...
Step 5: Multi-language Confirmation
Does this project require multi-language support?
If yes:
- Which languages need to be supported?
- Common options: English, 中文, 日本語, 한국어, Deutsch, Français, Español, etc.
- The default language will be set based on your primary language.
If no:
- All notes will be written in default language only.
- No i18n information will be added to any elements.
⚠️ IMPORTANT: Multi-language Rules
Only when explicitly confirmed: Add i18n information ONLY when user explicitly confirms multi-language support is needed
Never add i18n if not requested: If user says no multi-language, absolutely DO NOT add any i18n information
All meaningful elements: If multi-language is confirmed, ALL meaningful text elements MUST include i18n translations
Default language: Based on user's primary language (the language they use to communicate)
Elements requiring i18n (if multi-language is confirmed):
Button text
Label text
Placeholder text
Error/Success messages
Table headers
Menu items
Page titles
Status values
Elements NOT requiring i18n:
User input data (usernames, comments, etc.)
System generated data (IDs, timestamps, etc.)
Decorative elements
Icons
Phase 2: Requirements Validation
Step 6: Requirements Summary
Here's my understanding of requirements:
**Product Type**: [Type]
**Core Pages**:
1. [Page 1] - [Brief description]
2. [Page 2] - [Brief description]
3. ...
**Multi-language**: [Yes/No + Languages]
**Special Requirements**:
- [Requirement 1]
- [Requirement 2]
Is this understanding correct? Any adjustments or additions needed?
Step 7: Requirements Confirmation Gate
User MUST confirm requirements
If adjustments needed, go back to Phase 1
Phase 3: Generate & Quality
Step 8: Generate PRD
Generate complete PRD document
Save to .solarwire/[project-name]/solarwire-prd.md
Step 9: Spec Self-Review
Check 1: Placeholder Scan
Check items:
- Any "TBD", "To Be Determined", "待定"
- Any "TODO", "待完成"
- Incomplete sections
- Vague requirement descriptions
If found:
- Fix or clarify immediately
- No placeholders allowed
Check 2: Internal Consistency
Check items:
- Product type matches page design
- Core features list matches page details
- Multi-language rules are consistent throughout document
- Color standards are used consistently
- Font standards are used consistently
If contradictions found:
- Priority: Page details > Feature list > Product type
- Unify standards
Check 3: Scope Check
Check items:
- Focused on implementable scope
- Not too many independent subsystems
- Doesn't need decomposition
Criteria:
- If >5 independent modules → needs decomposition
- If >10 pages → needs decomposition
- If multiple independent business flows → needs decomposition
If needs decomposition:
- Go back to Phase 0 Step 1
- Help user decompose and select first sub-project
Check 4: Ambiguity Check
Check items:
- Requirements with two possible interpretations
- Vague business rules (e.g., "appropriate", "reasonable")
- Undefined terms
If ambiguity found:
- Choose one interpretation and make it explicit
- Add term definitions to Appendix
- Clarify business rules (e.g., "appropriate permissions" → "read-only permissions")
**Note: Visual ambiguity is allowed**
- Visual descriptions like "appropriate spacing", "reasonable layout" don't need quantification
- But functional requirements must be clear (e.g., "user can edit" not "user might be able to edit")
Fix Principle:
Fix all issues immediately, no need to re-review
Proceed to Step 10 after fixing
Step 10: User Review Gate
✅ PRD generated and passed self-review
**File Location:** `.solarwire/[project-name]/solarwire-prd.md`
**Includes:**
- Product Overview (1.1-1.4)
- Feature Scope (2.1-2.2)
- Business Flow (3.1-3.2)
- Page Design (4.1-5.x)
- Non-functional Requirements (6.1-6.3)
- Appendix (7.1-7.2)
**Please review:**
1. Completeness - Any missing features?
2. Accuracy - Any misunderstandings?
3. Page Design - Matches expectations?
4. Business Logic - Correct?
**Review Method:**
- Edit directly in file
- Or tell me what needs adjustment
**After review approval, I will:**
- Generate SVGs for all pages (with notes and without notes)
- Complete entire PRD generation process
Please start reviewing, let me know if you have any questions.
User Review Gate Rules:
MUST wait for user to explicitly confirm "ok" or "no problem"
If user requests changes, go back to Step 8 to regenerate PRD
If user only needs minor adjustments, can fix before Step 11
Phase 4: Output
Step 11: Generate SVG
Run node generate-svg.js .solarwire/[project-name]/solarwire-prd.md
Generate SVGs with notes and without notes
Multiple Approaches Comparison
Trigger Conditions:
When project has multiple viable design approaches
When user is uncertain about implementation approach
Extract all solarwire code blocks from the markdown file
Generate two SVG files for each block:
[page-name]-with-notes.svg - Includes note annotations
[page-name]-without-notes.svg - Clean wireframe only
Save files to the same directory as the markdown file (the requirement folder)
Updating Dependencies:
If you need to update the bundled dependencies:
# Build the latest parser and renderercd SolarWire/packages/core/parser && npm run build
cd SolarWire/packages/core/renderer-svg && npm run build
# Copy to skill lib directorycp -r SolarWire/packages/core/parser/dist/* solarwire-prd/lib/parser/
cp -r SolarWire/packages/core/renderer-svg/dist/* solarwire-prd/lib/renderer-svg/
PRD Document Structure
# Product Requirements Document - [Project Name]## Document Information
| Project Name | [Project Name] |
|-------------|----------------|
| Version | v1.0 |
| Created Date | [Date] |
| Author | [Author] |
---
## 1. Product Overview### 1.1 Product Background
[Brief description of product background and goals]
### 1.2 Target Users
[Description of target user groups]
### 1.3 Core Value
[Core value provided to users by product]
### 1.4 User Stories**Format: As a [user role], I want to [action], so that [benefit]**
| ID | User Story | Acceptance Criteria | Priority |
|----|------------|---------------------|----------|
| US-001 | As a [role], I want to [action], so that [benefit] | - Given [context], when [action], then [result] | P0 |
| US-002 | As a [role], I want to [action], so that [benefit] | - Given [context], when [action], then [result] | P0 |
| US-003 | As a [role], I want to [action], so that [benefit] | - Given [context], when [action], then [result] | P1 |
**User Story Writing Guidelines:**-**User Role**: Identify who the user is (e.g., "As a registered user", "As an admin")
-**Action**: What the user wants to do (e.g., "I want to reset my password")
-**Benefit**: Why the user wants this (e.g., "so that I can regain access to my account")
-**Acceptance Criteria**: Use Given-When-Then format to define testable conditions
-**Priority**: P0 (Must have), P1 (Should have), P2 (Nice to have)
---
## 2. Feature Scope### 2.1 Feature List
| Module | Feature | Priority | Description |
|--------|---------|----------|-------------|
| [Module 1] | [Feature 1] | P0 | [Description] |
| [Module 1] | [Feature 2] | P1 | [Description] |
### 2.2 Feature Boundary- Included: [List included features]
- Not Included: [List excluded features]
---
## 3. Business Flow### 3.1 Core Business Flowchart```mermaid
flowchart TD
A[Start] --> B[Step 1]
B --> C[Step 2]
C --> D{Decision}
D -->|Yes| E[Step 3]
D -->|No| F[Step 4]
E --> G[End]
F --> G
3.2 Interaction Sequence Diagram
sequenceDiagram
participant U as User
participant F as Frontend
participant B as Backend
participant D as Database
U->>F: Send Request
F->>B: API Call
B->>D: Data Query
D-->>B: Return Data
B-->>F: Response Result
F-->>U: Display Result
4. Page Design
4.1 Page List
Page Name
Page Type
Description
[Page 1]
Main Page
[Description]
[Page 2]
Modal
[Description]
5. Page Details
Core Principle: All element descriptions are integrated into the SolarWire wireframe notes for "what you see is what you read"
5.1 [Page Name]
Page Overview: [One sentence describing core functionality of page]
!title="[Page Name]"
!c=#111827
!size=13
!bg=#E5E7EB
!r=0
// Container Rectangle
[] @(0,0) w=1440 h=900 bg=#FFFFFF
// Page Content - Each element has detailed note description
["Logo"] @(50,50) w=120 h=60 note="""Logo
1. Click action
- Return to homepage"""
"User Login" @(100,150) size=24 bold
"Username" @(100,220)
["Enter phone or email"] @(100,245) w=300 h=44 bg=#FFFFFF b=#E5E7EB note="""Username input
1. Input rules
- Supports phone number or email
- Automatically trims leading/trailing spaces
- Max length: 50 characters
2. Validation
- Format: 11-digit phone number or email format
- Error message: 'Please enter a valid phone number or email'"""
"Password" @(100,310)
["Enter password"] @(100,335) w=300 h=44 bg=#FFFFFF b=#E5E7EB note="""Password input
1. Input rules
- Password displayed as dots
- Min length: 6 characters, Max: 32 characters
- Must contain letters and numbers
2. Interaction
- Show/hide toggle icon on right"""
[""] @(100,400) w=16 h=16 note="""Remember me checkbox
1. Behavior
- When checked: Stay logged in for 7 days
- Unchecked by default"""
"Remember Me" @(124,402)
"Forgot Password?" @(320,400) c=#3B82F6 note="""Forgot password link
1. Click action
- Navigate to password recovery page"""
["Login"] @(100,450) w=300 h=48 bg=#3B82F6 c=#FFFFFF size=16 note="""Login button
1. Click action
- Validate username and password
2. Success handling
- Save login state
- Redirect to homepage
3. Failure handling
- Display modal: 'Invalid username or password'
- Clear password field
4. Disabled conditions
- Disabled when username or password is empty"""
"Or login with" @(160,530) c=#9CA3AF
[?"WeChat Work"] @(120,560) w=40 h=40 note="""WeChat Work login
1. Click action
- WeChat Work QR code login"""
[?"DingTalk"] @(180,560) w=40 h=40 note="""DingTalk login
1. Click action
- DingTalk QR code login"""
[?"WeChat"] @(240,560) w=40 h=40 note="""WeChat login
1. Click action
- WeChat authorization login"""
**NOTE ATTRIBUTE MUST USE TRIPLE QUOTES """: note="""Note content""" (never use single or double quotes)
**⚠️ CRITICAL: Always use triple quotes `"""` for notes**
- Triple quotes allow any characters inside, including newlines and double quotes
- No need to escape anything inside triple quotes
- DO NOT use single quotes `'` or double quotes `"` for notes
**Correct Example:**
```solarwire
["Login"] @(100,50) w=100 h=40 bg=#3B82F6 c=#FFFFFF note="""Submit login form"""
"Username" @(100,100)
(("Avatar")) @(100,150) w=40 // Circle with text - MUST use double quotes
Incorrect Examples:
["Login"] // ❌ No coordinates
["Login"] [w=100 h=40] // ❌ Attributes in brackets
["Login"] @(100,50) w=100 // ❌ Missing height
((Avatar)) @(100,50) w=40 // ❌ Text without double quotes - WRONG!
(("Avatar")) @(100,50) w=40 // ✅ Correct - text in double quotes
⚠️ IMPORTANT: All text content MUST be wrapped in double quotes ""
Element
Correct
Incorrect
Rectangle
["Button"]
[Button]
Circle
(("Avatar"))
((Avatar))
Rounded
("Card")
(Card)
Plain Text
"Label"
Label
2. Element Selection Principles
Choose appropriate element types based on actual UI components:
Mobile: w=375 h=812 (iPhone X) or w=390 h=844 (iPhone 12+)
Web: w=1440 h=900 or as needed
Admin Dashboard: w=1920 h=1080
Container Size Principle: Container must contain all child elements
Forbidden: Child elements extending beyond parent container boundaries.
5. Note Writing Guidelines
Core Principle: Notes describe functional behavior and business logic, not visual details or technical implementation
0. When to Read EXAMPLES.md
📖 Read EXAMPLES.md when you encounter:
Scenario
What to Look Up
Writing complex button notes
"Button with Permission Control", "Batch Operations", "Form Submission"
Writing input field notes
"Input Field with Validation", "Search Bar with Filters", "Data Linkage"
Writing data table notes
"Data Table", "Table with Actions Column"
Writing statistics notes
"Statistics Card", "Calculated Field"
Writing navigation notes
"Pagination Component"
Handling special states
"Loading States", "Empty State Handling"
Unsure about note quality
"Common Mistakes" section
📖 EXAMPLES.md contains:
Complete note examples for each element type
Good vs Bad comparisons
All edge cases and error handling examples
⚠️ Important:
SKILL.md contains rules (what must be included)
EXAMPLES.md contains examples (how to write it)
Always follow rules in SKILL.md, use EXAMPLES.md for reference
1. When to Write Notes
Write notes for:
Interactive elements (buttons, links, etc.)
Input elements with validation or logic
Dropdowns (selection behavior, options source)
Data display elements with complex rules (tables, lists)
Elements with business logic (calculations, conditions)
Complex concepts requiring additional explanation
Skip notes for:
Pure visual elements (dividers, containers, decorative icons)
Static labels and titles
Common Sense Exemption (no note needed unless special behavior):
Back button (standard behavior: return to previous page)
Close button
Page selector
Number stepper/incrementer
Note: If exempted elements have special validation or interaction, they MUST be documented.
2. Note Structure Format
Format Rules:
First line: Element definition (what this element is, NOT element type)
First level: Numbered (1. 2. 3.)
Second level: - or # (if third level exists)
Third level: -- or -
Example:
["Enter password"] @(100,100) w=280 h=40 note="""Password input
1. Input rules
- Password displayed as dots
- Minimum 6 characters, maximum 32 characters
- Must contain both letters and numbers
2. Interaction
- Show/hide toggle icon on right
- Validate format on blur
- Display error on format failure: 'Invalid password format'
3. Special notes
- Lock account for 15 minutes after 5 consecutive errors"""
3. First Line: Element Definition
The first line of a note MUST define what this element is (functional description, NOT element type).
Correct
Incorrect
Password input
[Password Field]
Username input
[Input Field]
User data table
[Data Table]
Submit form button
[Primary Button]
4. Content Requirements by Element Type
Interactive/Operational Elements:
Must include:
What happens on click/operation
Success/failure handling
Disabled conditions
Special handling (debounce, throttle, etc.)
📖 See EXAMPLES.md: "Button with Permission Control", "Batch Operations", "Form Submission"
Elements with Logic:
Must include:
Show/hide conditions
Calculation rules
Validation rules
State transitions
Data Display Elements:
Must include ALL of the following sections:
Section
Required
Description
1. Data source
✅ Required
Where data comes from, filtering conditions, sorting rules
2. Display rules
✅ Required
Field meanings, formats, empty value handling
3. Business rules
Optional
Status mappings, conditional display, calculations
4. Sorting/Filtering
Optional
If applicable, describe sorting and filtering behavior
📖 See EXAMPLES.md: "Data Table", "Table with Actions Column", "Statistics Card", "Status Badge"
Input Fields:
Must include:
Input rules (format, length, allowed characters)
Validation (required, format check, error messages)
Business rules (unique check, duplicate check)
📖 See EXAMPLES.md: "Input Field with Validation", "Search Bar with Filters", "Data Linkage"
Dropdowns/Selects:
Must include:
Data source (options source, static or dynamic)
Display rules (default, selected, options list)
Business rules (required, default value, dependencies)
📖 See EXAMPLES.md: "Dropdown Options", "Data Linkage (Cascading Select)"
Empty State Handling:
Data Type
Empty Display
Example
Text
'-' or 'Not set'
"Contact: -"
Number
'0' or '--'
"Amount: ¥ --"
Date
'-' or 'Not specified'
"Last login: -"
Status
Default status
"Status: Pending"
List/Table
Empty state message
"No data available"
📖 See EXAMPLES.md: "Empty State Handling", "Loading States"
Tooltip/Toast:
Describe directly in note, no separate wireframe needed.
📖 See EXAMPLES.md: "Tooltip/Toast Examples"
5. Note Writing Principles
Principle
Description
Necessity
Only write for meaningful elements, avoid over-documentation
Completeness
Fully describe element, cover all aspects
Single Responsibility
Only describe current element; affected elements document in their own notes
Organization
Use standard format, clear hierarchy
Self-explanatory
Element definition should be clear, no need for secondary explanation
Business-focused
Describe business logic, avoid technical implementation details
5.3 Required Content by Element Type (Quick Reference)
Always describe status values with their visual representation:
"跟进中" @(100,50) note="""Lead status
1. Display rules
- Status values with visual style:
- 待分配: Gray tag (#D1D5DB background)
- 跟进中: Blue tag (#3B82F6 background)
- 已转化: Green tag (#22C55E background)
- 无效: Red tag (#EF4444 background)
- All tags: White text, rounded corners, 4px padding"""
6. Content Forbidden in Notes
NEVER include:
Forbidden
Example (Don't Write)
Colors
"Button is blue", "Text color #333"
Fonts
"Font size 14px", "Bold text"
Sizes
"Width 100px", "Height 40px"
Spacing
"Margin 16px", "Padding 8px"
Border
"Border radius 8px"
Shadows
"Box shadow 0.2px 4px"
Animations
"Fade in 0.3s"
Technical details
"API: /api/login", "Database: user_id"
Why? These are:
Already shown visually in wireframe
Design decisions to be made later
Subject to change during implementation
7. Multi-language (i18n) Support
⚠️ CRITICAL: Only add i18n when user explicitly confirms multi-language support is needed
If user does NOT need multi-language:
Do NOT add any i18n information to any element
Write notes in the user's primary language only
If user confirms multi-language support:
ALL meaningful text elements MUST include i18n translations
Use full language names (e.g., "English", "中文", "日本語") instead of language codes
Default language is based on user's primary language
Table-level note: Add note attribute to the table element ## for overall table description
Row-level note: note attribute is NOT supported on table rows #
If you need to describe a table, put all information in the table-level note
Common Attributes
Attribute
Description
Example
wh
Width, Height
w=100 h=40
bg
Background color
bg=#3B82F6
c
Text color
c=#FFFFFF or c=#111827
b
Border color
b=#E5E7EB
r
Border radius
r=8
size
Font size
size=16
bold
Bold text
bold
opacity
Element opacity (0-1)
opacity=0.5 for 50% transparency
colspan
Column span for table cells
colspan=2 (merge 2 columns)
rowspan
Row span for table cells
rowspan=2 (merge 2 rows)
note
Functional description
note="Click to submit form"
Table Row Attributes
Table rows (#) support the following attributes:
bg – Background color for the entire row
c, size, bold, italic, align – Text style defaults for all cells in the row
⚠️ Important Rules:
note attribute is NOT supported on table rows #
To describe a table, add note to the table element ## instead
Row-level attributes serve as defaults for all cells in that row
Individual cells can override row-level attributes with their own values
Example:
## @(100,50) w=500 border=1 note="""User list table
1. Data source
- User list data from User Management module
2. Field descriptions
- ID: Unique user identifier
- Name: User display name
- Actions: Edit and delete operations"""
# bg=#F9FAFB c=#111827 bold // Header row
["ID"]
["Name"]
["Actions"] colspan=2 // Merge 2 columns for actions
# bg=#F9FAFB // Data row: alternating color
["1"]
["John Doe"]
["Edit"] // Each button in separate cell
["Delete"]
Creating Clean, Realistic Wireframes
Goal: Wireframes should look like actual UI, clean and professional
Key Principles
Use Realistic Placeholder Content
Use actual placeholder text, not generic labels
Example: ["Enter your email..."] instead of ["Input"]
i18n Only When Confirmed - Add multi-language support ONLY when user explicitly confirms; if not confirmed, absolutely NO i18n information; if confirmed, ALL meaningful elements MUST include i18n translations using full language names (English, 中文, 日本語)
