Release v1.11.0: Add prompt-optimizer skill with EARS methodology

Add new prompt-optimizer skill (v1.1.0) for transforming vague prompts into precise EARS specifications: New Features: - EARS (Easy Approach to Requirements Syntax) transformation with 5 patterns - 6-step optimization workflow (analyze, transform, theories, examples, enhance, present) - Domain theory grounding (40+ frameworks across 10 domains) - Role/Skills/Workflows/Examples/Formats prompt enhancement framework - Progressive disclosure with 4 bundled reference files Skill Improvements (v1.0.0 → v1.1.0): - Reduced SKILL.md from 369 to 195 lines (47% reduction) - Added advanced_techniques.md (325 lines) for complex scenarios - Added 4th complete example (password reset security) - Added attribution to 阿星AI工作室 (A-Xing AI Studio) - Enhanced reference loading guidance Marketplace Updates: - Updated marketplace to v1.11.0 (17 → 18 skills) - Updated all documentation (README.md, README.zh-CN.md, CLAUDE.md) - Added Chinese and English descriptions with attribution 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-16 23:41:14 +08:00
parent 15582e2538
commit df2e654b1d
11 changed files with 1401 additions and 11 deletions
--- a/prompt-optimizer/references/advanced_techniques.md
+++ b/prompt-optimizer/references/advanced_techniques.md
@@ -0,0 +1,325 @@
+# Advanced Prompt Optimization Techniques
+
+## Overview
+
+This reference covers advanced EARS transformation patterns for complex requirements involving multiple stakeholders, non-functional constraints, and sophisticated conditional logic.
+
+## Multi-Stakeholder Requirements
+
+When requirements involve multiple user types with different needs and permissions:
+
+### Approach
+
+1. Create EARS statements for each stakeholder
+2. Identify conflicting requirements (admin vs. user permissions)
+3. Specify role-based conditions explicitly
+4. Use nested conditions when access depends on multiple factors
+
+### Patterns
+
+**Basic role-based access:**
+```
+If user role is 'Admin', the system shall display all user management controls
+If user role is 'Editor', the system shall display content editing controls
+If user role is 'Viewer', the system shall prevent access to editing functions
+```
+
+**Hierarchical permissions:**
+```
+If user role is 'Owner' OR 'Admin', the system shall allow deletion of any content
+If user role is 'Editor' AND content.author is current user, the system shall allow editing of that content
+If user role is 'Viewer', the system shall display content in read-only mode
+```
+
+**Context-dependent access:**
+```
+When user requests sensitive data:
+  - If user role is 'Manager' AND user.department matches data.department, the system shall grant access
+  - If user role is 'Executive', the system shall grant access regardless of department
+  - Otherwise, the system shall deny access and log the attempt
+```
+
+### Example: Content Management System
+
+**Requirement:** "Different users should have different permissions"
+
+**EARS transformation:**
+```
+1. When user logs in with 'Admin' role, the system shall display dashboard with user management, content moderation, and system settings
+
+2. When user logs in with 'Author' role, the system shall display dashboard with create post, edit own posts, and view analytics
+
+3. When 'Author' attempts to publish post, the system shall set post status to 'pending review'
+
+4. When 'Editor' reviews pending post, the system shall provide approve/reject/request changes options
+
+5. If 'Author' attempts to access another author's draft, the system shall prevent access and display "Access Denied" message
+
+6. When 'Admin' accesses any post, the system shall grant full permissions (view, edit, delete, publish) regardless of author
+```
+
+## Non-Functional Requirements
+
+Performance, security, scalability, and reliability requirements need precise quantification.
+
+### Approach
+
+1. Quantify constraints explicitly (no vague terms like "fast" or "secure")
+2. Specify measurement methods (how to verify the requirement)
+3. Include threshold values (acceptable ranges)
+4. Define degradation behavior (what happens when thresholds are exceeded)
+
+### Patterns
+
+**Performance requirements:**
+```
+When search query is submitted, the system shall return results within 200ms for 95% of requests
+When page load is initiated, the system shall display first contentful paint within 1.5 seconds for 90% of requests
+While concurrent user count exceeds 10,000, the system shall maintain response time below 500ms
+```
+
+**Security requirements:**
+```
+When user authentication fails 5 times within 15 minutes, the system shall lock the account for 30 minutes
+When password is created, the system shall enforce minimum 12 characters, 1 uppercase, 1 number, 1 special character
+While session is active, the system shall invalidate session after 30 minutes of inactivity
+If SQL injection pattern is detected in input, the system shall sanitize input and log security event
+```
+
+**Scalability requirements:**
+```
+When concurrent user count reaches 50,000, the system shall auto-scale to additional server instances
+When database query time exceeds 100ms, the system shall use read replicas for load balancing
+While system is under load, the system shall queue requests beyond 100,000/second and process FIFO
+```
+
+**Reliability requirements:**
+```
+When service fails, the system shall attempt retry with exponential backoff (1s, 2s, 4s, 8s)
+When database connection is lost, the system shall failover to backup database within 5 seconds
+While maintenance window is active, the system shall display maintenance page and queue incoming requests
+If data corruption is detected, the system shall rollback to last known good state within 10 minutes
+```
+
+### Example: E-commerce Checkout
+
+**Requirement:** "The checkout should be fast and secure"
+
+**EARS transformation:**
+```
+1. When user clicks "Place Order", the system shall process payment within 3 seconds for 95% of transactions
+
+2. When payment processing exceeds 5 seconds, the system shall display "Processing..." indicator and prevent duplicate submissions
+
+3. When payment is processed, the system shall use TLS 1.3 encryption for all data transmission
+
+4. When credit card number is entered, the system shall tokenize the number and never store raw card data
+
+5. When payment gateway is unavailable, the system shall retry 3 times with 2-second intervals, then display user-friendly error
+
+6. If payment fails after retries, the system shall store order in "pending" state for 24 hours and email user with recovery link
+
+7. When concurrent checkout requests exceed 1,000/second, the system shall queue additional requests and process within 10 seconds
+
+8. When fraud detection score exceeds 70, the system shall require additional verification (SMS code or manual review)
+```
+
+## Complex Conditional Logic
+
+Multi-condition requirements with nested logic, boolean operators, and priority rules.
+
+### Approach
+
+1. Use nested conditions with clear hierarchy
+2. Specify boolean operators explicitly (AND, OR, NOT)
+3. Define priority when conditions conflict
+4. Use parentheses to clarify precedence
+5. Provide fallback behavior for unmatched conditions
+
+### Patterns
+
+**Nested conditions:**
+```
+When user submits form:
+  If all required fields are filled:
+    If email format is valid:
+      If password strength is 'strong' OR 'very strong':
+        The system shall create account and send verification email
+      Else:
+        The system shall reject with "Password too weak" message
+    Else:
+      The system shall highlight email field and display format example
+  Else:
+    The system shall highlight missing fields and prevent submission
+```
+
+**Complex boolean logic:**
+```
+If (user is logged in AND subscription is active) OR (user has free trial remaining AND trial end date > today):
+  The system shall grant access to premium features
+  If free trial:
+    The system shall display "X days remaining in trial" banner
+  If subscription expires within 7 days:
+    The system shall show renewal reminder in header
+Else:
+  The system shall redirect to pricing page with upgrade prompt
+```
+
+**Priority-based rules:**
+```
+When content moderation is triggered:
+  Priority 1: If content contains profanity, the system shall immediately hide content and flag for manual review
+  Priority 2: Else if content reports exceed 10, the system shall hide content and notify moderator
+  Priority 3: Else if AI toxicity score > 0.8, the system shall add warning label "potentially sensitive content"
+  Priority 4: Else if content is flagged but reports < 10, the system shall add to moderation queue
+  Default: The system shall display content normally
+```
+
+**Time-based conditions:**
+```
+When user accesses course content:
+  If (current date >= course.start_date) AND (current date <= course.end_date):
+    If user.enrollment_status is 'active':
+      The system shall grant full access to all lessons
+    Else if user.enrollment_status is 'pending':
+      The system shall display "Enrollment pending approval" message
+  Else if current date < course.start_date:
+    The system shall display "Course starts on [date]" countdown
+  Else if (current date > course.end_date) AND (user.completion_rate >= 100%):
+    The system shall grant read-only access to completed course materials
+  Else:
+    The system shall display "Course has ended" message with re-enrollment option
+```
+
+### Example: Dynamic Pricing System
+
+**Requirement:** "Prices should change based on demand, inventory, and user type"
+
+**EARS transformation:**
+```
+When user views product page:
+  Base calculation: system shall retrieve base_price from product.price
+
+  Apply inventory adjustments:
+    If inventory_count < 10:
+      system shall multiply price by 1.2 (20% scarcity premium)
+    Else if inventory_count < 50:
+      system shall multiply price by 1.1 (10% low stock premium)
+    Else if inventory_count > 500:
+      system shall multiply price by 0.9 (10% overstock discount)
+
+  Apply demand adjustments:
+    If view_count in last 24 hours > 1000:
+      system shall multiply price by 1.15 (15% high demand premium)
+    If purchase_count in last hour > 50:
+      system shall multiply price by 1.1 (10% trending premium)
+
+  Apply user-specific adjustments:
+    If user is 'VIP' AND lifetime_purchase_value > $10,000:
+      system shall apply 15% discount
+    Else if user is 'VIP':
+      system shall apply 10% discount
+    Else if user is logged in AND first_purchase:
+      system shall apply 5% first-time discount
+    Else if user has abandoned cart for this product:
+      system shall apply 8% re-engagement discount
+
+  Apply time-based promotions:
+    If current time is within flash_sale.time_window:
+      system shall apply flash_sale.discount_percentage
+    Else if current date is user.birthday:
+      system shall apply 20% birthday discount
+
+  Final validation:
+    If calculated_price < product.minimum_price:
+      system shall set price to product.minimum_price
+    If calculated_price > product.maximum_price:
+      system shall set price to product.maximum_price
+
+  Display:
+    system shall display final calculated price rounded to nearest $0.99
+    If discount > 0:
+      system shall show original price crossed out with discount percentage badge
+```
+
+## Combining Techniques
+
+Real-world requirements often combine multiple techniques:
+
+### Example: Healthcare Appointment System
+
+**Requirement:** "Different user types should be able to book appointments with various rules"
+
+**Combined EARS transformation:**
+```
+Multi-stakeholder + Non-functional + Complex conditional:
+
+When user attempts to book appointment:
+
+  Authentication & Authorization:
+    If user role is 'Patient':
+      If user has verified insurance AND insurance.status is 'active':
+        system shall allow booking appointments with in-network providers
+      Else if user has no insurance OR insurance.status is 'expired':
+        system shall allow booking with cash payment option only
+      Else if user.insurance_verification is 'pending':
+        system shall display "Insurance verification in progress" message
+
+    If user role is 'Provider':
+      system shall display manage schedule, view appointments, update availability options
+
+    If user role is 'Admin':
+      system shall grant full access to all appointments, schedules, and patient records
+
+  Availability checking (Performance requirement):
+    When user selects provider and date:
+      system shall retrieve available time slots within 100ms
+      If query exceeds 100ms:
+        system shall use cached availability data with staleness indicator
+
+  Booking constraints (Complex conditional):
+    If selected_time is within 24 hours AND user role is 'Patient':
+      system shall require phone verification for last-minute bookings
+    Else if selected_time is more than 90 days in future:
+      system shall prevent booking and display "Cannot book more than 90 days ahead"
+
+    If (appointment_count for user this_month >= 5) AND (user.subscription_tier is 'Basic'):
+      system shall prevent booking and prompt upgrade to 'Premium' tier
+    Else if (appointment_count for provider this_day >= 20):
+      system shall prevent booking and suggest alternative providers or dates
+
+  Concurrent booking prevention (Non-functional - reliability):
+    When booking is confirmed:
+      system shall use distributed lock to prevent double-booking for 60 seconds
+      If lock cannot be acquired within 5 seconds:
+        system shall display "This time slot is being booked by another user" and refresh available slots
+
+  Notification rules (Multi-stakeholder):
+    When appointment is successfully booked:
+      system shall send confirmation email to patient within 30 seconds
+      system shall send notification to provider via SMS and in-app notification
+      system shall add appointment to provider's calendar with patient details
+      If appointment is within 48 hours:
+        system shall schedule reminder SMS 24 hours before appointment
+        system shall schedule reminder email 2 hours before appointment
+```
+
+## Best Practices for Advanced Techniques
+
+1. **Layer incrementally** - Start with basic EARS, then add advanced patterns
+2. **Test each condition** - Ensure every branch has a testable outcome
+3. **Document assumptions** - Make implicit business rules explicit
+4. **Use tables for complex logic** - Decision tables clarify multi-condition scenarios
+5. **Validate with stakeholders** - Confirm priority and precedence with domain experts
+6. **Consider edge cases** - What happens at boundaries (0, max, negative, null)?
+7. **Plan for exceptions** - Every rule needs an "otherwise" clause
+8. **Quantify everything** - Replace "many" with numbers, "fast" with milliseconds
+
+## Common Pitfalls
+
+❌ **Circular conditions** - "If A then B, if B then A" creates infinite loops
+❌ **Unreachable branches** - Conditions that can never be true
+❌ **Ambiguous precedence** - When multiple conditions match, which wins?
+❌ **Missing default cases** - What if none of the conditions match?
+❌ **Vague thresholds** - "High traffic" → Define "high" numerically
+❌ **Incomplete error handling** - What happens when external systems fail?
--- a/prompt-optimizer/references/domain_theories.md
+++ b/prompt-optimizer/references/domain_theories.md
@@ -0,0 +1,245 @@
+# Domain Theories for Prompt Enhancement
+
+## Purpose
+
+When enhancing prompts, grounding the solution in established domain theories provides:
+- Proven methodologies and frameworks
+- Industry best practices
+- Credibility and rigor
+- Structured problem-solving approaches
+
+## Common Domain Theory Mappings
+
+### Productivity & Time Management
+
+**Applicable for:** Task management apps, productivity tools, scheduling systems
+
+**Relevant Theories:**
+1. **Getting Things Done (GTD)** - David Allen
+   - Capture, Clarify, Organize, Reflect, Engage
+   - Next action principle
+   - Context-based task organization
+
+2. **Pomodoro Technique** - Francesco Cirillo
+   - 25-minute focused work intervals
+   - Regular breaks
+   - Distraction management
+
+3. **Eisenhower Matrix**
+   - Urgent/Important prioritization
+   - Four quadrants for task classification
+
+4. **Pareto Principle (80/20 Rule)**
+   - Focus on high-impact activities
+   - Effort vs. outcome optimization
+
+5. **Timeboxing**
+   - Fixed time allocations
+   - Deadline-driven focus
+
+### Behavior Change & Habit Formation
+
+**Applicable for:** Health apps, learning platforms, goal-tracking systems
+
+**Relevant Theories:**
+1. **BJ Fogg Behavior Model (B=MAT)**
+   - Behavior = Motivation × Ability × Trigger
+   - Tiny habits principle
+   - Behavioral chains
+
+2. **Atomic Habits** - James Clear
+   - 1% improvement philosophy
+   - Habit stacking
+   - Identity-based habits
+
+3. **Operant Conditioning**
+   - Positive/negative reinforcement
+   - Reward schedules
+   - Immediate feedback loops
+
+4. **Self-Determination Theory**
+   - Autonomy, competence, relatedness
+   - Intrinsic vs. extrinsic motivation
+
+### User Experience & Interface Design
+
+**Applicable for:** UI/UX projects, web applications, mobile apps
+
+**Relevant Theories:**
+1. **Hick's Law**
+   - Choice overload reduction
+   - Decision time optimization
+
+2. **Fitts's Law**
+   - Target size and distance relationship
+   - Touch target optimization
+
+3. **Miller's Law (7±2)**
+   - Cognitive load management
+   - Chunking information
+
+4. **Jakob's Law**
+   - Familiar design patterns
+   - User expectations
+
+5. **Progressive Disclosure**
+   - Layered information architecture
+   - Complexity management
+
+6. **Gestalt Principles**
+   - Proximity, similarity, closure
+   - Visual hierarchy
+
+### Gamification & Engagement
+
+**Applicable for:** Learning apps, fitness trackers, social platforms
+
+**Relevant Theories:**
+1. **Octalysis Framework** - Yu-kai Chou
+   - 8 core drives of gamification
+   - White hat vs. black hat mechanics
+
+2. **Self-Determination Theory in Games**
+   - Challenge and mastery
+   - Social connection
+   - Autonomy in gameplay
+
+3. **Flow Theory** - Mihaly Csikszentmihalyi
+   - Skill-challenge balance
+   - Immediate feedback
+   - Clear goals
+
+4. **Variable Reward Schedules**
+   - Unpredictability and anticipation
+   - Dopamine-driven engagement
+
+### Learning & Education
+
+**Applicable for:** E-learning platforms, training systems, educational apps
+
+**Relevant Theories:**
+1. **Bloom's Taxonomy**
+   - Knowledge → Comprehension → Application → Analysis → Synthesis → Evaluation
+   - Learning objective hierarchy
+
+2. **Spaced Repetition**
+   - Forgetting curve optimization
+   - Long-term memory consolidation
+
+3. **Active Recall**
+   - Retrieval practice
+   - Testing effect
+
+4. **Cognitive Load Theory**
+   - Intrinsic, extraneous, germane load
+   - Working memory limitations
+
+5. **Zone of Proximal Development**
+   - Scaffolding
+   - Guided learning
+
+### Data Visualization & Analytics
+
+**Applicable for:** Dashboard design, reporting tools, analytics platforms
+
+**Relevant Theories:**
+1. **Tufte's Principles**
+   - Data-ink ratio
+   - Chartjunk elimination
+   - Small multiples
+
+2. **Gestalt Principles for Data**
+   - Pre-attentive attributes
+   - Visual encoding
+
+3. **Information Scent**
+   - Navigation cues
+   - Progressive exploration
+
+### E-commerce & Conversion
+
+**Applicable for:** Online stores, checkout flows, landing pages
+
+**Relevant Theories:**
+1. **Cialdini's Principles of Persuasion**
+   - Reciprocity, commitment, social proof
+   - Scarcity, authority, liking
+
+2. **AIDA Model**
+   - Attention → Interest → Desire → Action
+   - Conversion funnel optimization
+
+3. **Paradox of Choice**
+   - Option limitation
+   - Decision fatigue reduction
+
+### Information Architecture
+
+**Applicable for:** Content-heavy sites, knowledge bases, documentation
+
+**Relevant Theories:**
+1. **Information Foraging Theory**
+   - Scent trails
+   - Cost-benefit of navigation
+
+2. **Card Sorting Principles**
+   - User mental models
+   - Category optimization
+
+3. **LATCH Framework** (Location, Alphabet, Time, Category, Hierarchy)
+   - Information organization patterns
+
+### Security & Trust
+
+**Applicable for:** Authentication systems, privacy-sensitive apps, financial platforms
+
+**Relevant Theories:**
+1. **Zero Trust Architecture**
+   - Never trust, always verify
+   - Least privilege access
+
+2. **Defense in Depth**
+   - Layered security controls
+   - Multiple fail-safes
+
+3. **Privacy by Design**
+   - Proactive privacy measures
+   - User control over data
+
+### Accessibility
+
+**Applicable for:** Inclusive design, government services, public platforms
+
+**Relevant Theories:**
+1. **WCAG Principles** (POUR)
+   - Perceivable, Operable, Understandable, Robust
+
+2. **Universal Design**
+   - Equitable use
+   - Flexibility in use
+   - Simple and intuitive
+
+## How to Select Theories
+
+1. **Identify the domain** from user requirements
+2. **Match to primary objective** (engagement, learning, conversion, etc.)
+3. **Select 2-4 relevant theories** that complement each other
+4. **Apply principles** to specific features and workflows
+5. **Cite theories** in enhanced prompts to add credibility
+
+## Example Theory Selection
+
+**Requirement:** "Build a habit tracker app"
+
+**Domain:** Behavior Change & Habit Formation
+
+**Selected Theories:**
+- BJ Fogg Behavior Model (for trigger design)
+- Atomic Habits (for habit stacking)
+- Gamification (for motivation and rewards)
+
+**Application:**
+- Use tiny habits to lower barrier to entry
+- Implement trigger notifications at optimal times
+- Add streak tracking and badges for engagement
+- Enable habit chains for compound behavior
--- a/prompt-optimizer/references/ears_syntax.md
+++ b/prompt-optimizer/references/ears_syntax.md
@@ -0,0 +1,123 @@
+# EARS (Easy Approach to Requirements Syntax)
+
+## Overview
+
+EARS (Easy Approach to Requirements Syntax) is a structured requirements writing methodology created by Rolls-Royce in 2009. It transforms natural language descriptions into precise, actionable specifications.
+
+## Core Principle
+
+Convert requirements from **descriptive** to **normative** by decomposing them into:
+
+1. **Entity** - What component/system is involved
+2. **Action** - What operation/behavior should occur
+3. **Relationship** - How entities interact
+4. **Scope** - Under what conditions/constraints
+
+## EARS Sentence Patterns
+
+### Pattern 1: Ubiquitous (Unconditional)
+
+**Format:** `系统应 <action>`
+**English:** `The system shall <action>`
+
+**Use when:** Requirement always applies, no preconditions
+
+**Example:**
+- Natural: "The app needs a login page"
+- EARS: "The system shall provide a login interface"
+
+### Pattern 2: Event-Driven
+
+**Format:** `当 <trigger> 时,系统应 <action>`
+**English:** `When <trigger>, the system shall <action>`
+
+**Use when:** Requirement applies upon specific event
+
+**Example:**
+- Natural: "Send reminder before deadline"
+- EARS: "When the task deadline is within 30 minutes, the system shall send a reminder notification"
+
+### Pattern 3: State-Driven
+
+**Format:** `在 <state> 状态下,系统应 <action>`
+**English:** `While <state>, the system shall <action>`
+
+**Use when:** Requirement applies during a specific state
+
+**Example:**
+- Natural: "Show loading spinner during data fetch"
+- EARS: "While data is being fetched, the system shall display a loading spinner"
+
+### Pattern 4: Optional Feature
+
+**Format:** `若 <condition>,系统应 <action>`
+**English:** `If <condition>, then the system shall <action>`
+
+**Use when:** Requirement is conditional
+
+**Example:**
+- Natural: "Premium users get extra features"
+- EARS: "If the user has a premium subscription, the system shall enable advanced analytics features"
+
+### Pattern 5: Unwanted Behavior
+
+**Format:** `若 <condition>,系统应避免 <unwanted action>`
+**English:** `If <condition>, the system shall prevent <unwanted action>`
+
+**Use when:** Specifying constraints or prohibited behaviors
+
+**Example:**
+- Natural: "Don't allow duplicate submissions"
+- EARS: "If a submission is already in progress, the system shall prevent duplicate form submissions"
+
+## Complex EARS Patterns
+
+### Multi-Condition Events
+
+**Format:** `当 <condition1> 且 <condition2> 时,系统应 <action>`
+
+**Example:**
+```
+When the task deadline is within 30 minutes
+AND the user has not started the task,
+the system shall trigger a notification with encouraging message and sound alert.
+```
+
+### Conditional Actions with Alternatives
+
+**Format:**
+```
+When <trigger>:
+- If <condition1>, the system shall <action1>
+- If <condition2>, the system shall <action2>
+- Otherwise, the system shall <default action>
+```
+
+**Example:**
+```
+When user submits a form:
+- If all required fields are filled, the system shall process the submission
+- If any required field is empty, the system shall highlight missing fields
+- Otherwise, the system shall display a general error message
+```
+
+## EARS Transformation Checklist
+
+When converting natural language to EARS:
+
+- [ ] Identify all implicit conditions and make them explicit
+- [ ] Specify the triggering event or state
+- [ ] Define the actor (usually "the system")
+- [ ] Use precise action verbs (shall, should, must)
+- [ ] Specify measurable outcomes where possible
+- [ ] Break compound requirements into atomic statements
+- [ ] Remove ambiguous language ("user-friendly", "fast", "intuitive")
+- [ ] Add quantitative criteria ("within 30 minutes", "at least 8 characters")
+
+## Benefits
+
+1. **Clarity** - Eliminates ambiguity through structured syntax
+2. **Completeness** - Forces specification of conditions and triggers
+3. **Testability** - Clear requirements enable automated testing
+4. **Atomicity** - Each requirement is independent and self-contained
+5. **Traceability** - Easy to map requirements to features
--- a/prompt-optimizer/references/examples.md
+++ b/prompt-optimizer/references/examples.md
@@ -0,0 +1,321 @@
+# Prompt Optimization Examples
+
+> **Attribution:** Example 1 (Procrastination Eliminator App) is adapted from [阿星AI工作室 (A-Xing AI Studio)](https://mp.weixin.qq.com/s/yUVX-9FovSq7ZGChkHpuXQ), which pioneered the practical application of EARS methodology combined with domain theory grounding for AI prompt enhancement.
+
+## Example 1: Procrastination Eliminator App (from 阿星AI工作室)
+
+### Original Requirement (Vague)
+
+```
+帮我开发一个拖延症消除器网页应用,需要有提醒功能和任务管理功能。
+比如可以提醒大家通过拆解步骤完成工作,把大任务拆解为小任务
+
+Translation: Help me develop a procrastination eliminator web app with reminder and task management features. For example, it can remind people to complete work by breaking down steps, decomposing big tasks into small tasks.
+```
+
+**Problems:**
+- Functional description too broad, lacks specific details
+- Technical solution standardized, lacks specificity
+- No consideration of behavioral psychology factors
+- Missing specific interaction design guidance
+
+### EARS Transformation
+
+**Requirement rewritten using EARS syntax:**
+
+1. When a user creates a new task, the system shall guide the user to decompose the large task into executable small task steps
+
+2. When a user sets task timing, the system shall send scheduled reminder notifications
+
+3. When a user completes a sub-task, the system shall update overall task progress and provide positive feedback
+
+4. When a user accesses the application, the system shall display the to-do task list and completion statistics
+
+### Domain Theory Identification
+
+**Domain:** Behavior Psychology, Time Management, Human-Computer Interaction Design
+
+**Relevant Mature Theories:**
+- **Getting Things Done (GTD)** - David Allen's task management methodology
+- **Pomodoro Technique** - Time segmentation management technique
+- **Behavior Change Theory** - BJ Fogg's Behavior Model (B=MAT)
+- **Gamification Design Theory** - Enhance user engagement through reward mechanisms
+
+### Enhanced Prompt Output
+
+```markdown
+# Role
+You are a professional product designer and frontend development engineer, specializing in time management applications and user experience design, with a background in psychology, deeply understanding the causes and solutions of procrastination.
+
+## Skills
+- Design intuitive and easy-to-use task management interfaces
+- Implement scientific task decomposition guidance mechanisms
+- Develop effective reminder and notification systems
+- Apply behavioral psychology principles to enhance user stickiness
+- Master modern frontend development technology stack
+- Understand user experience design best practices
+
+## Workflows
+1. Requirement analysis - Deeply understand procrastination user pain points and usage scenarios
+2. Function design - Design task decomposition process based on GTD theory
+3. Interface planning - Create simple and efficient user interface layout
+4. Interaction design - Design guided task creation and management process
+5. Technical implementation - Use modern web technologies to develop responsive applications
+6. Testing optimization - Verify user experience and functional completeness
+
+## Examples
+**Large task example:** Complete quarterly work report → Decompose into: Collect data (2 hours) → Analyze data (3 hours) → Write initial draft (4 hours) → Revise and improve (2 hours) → Format adjustment (1 hour)
+
+**Reminder function:** Set daily 9 AM reminder "Start today's most important task", Pomodoro timer 25-minute work reminder
+
+**Progress visualization:** Display "This week completed tasks 8/12, progress 67%", with progress bar and achievement badges
+
+## Formats
+Output a complete HTML web application, including:
+- Responsive design layout
+- Task creation and decomposition forms
+- Task list and progress display
+- Reminder setting functionality
+- Local storage data persistence
+- Modern UI design style
+- Interactive animations and feedback effects
+```
+
+---
+
+## More Examples
+
+### Example 2: E-commerce Product Page
+
+**Original (Vague):**
+```
+Create a product page with add to cart button and reviews
+```
+
+**EARS Transformation:**
+```
+1. When a user visits a product page, the system shall display product images, title, price, and description
+2. When a user clicks "Add to Cart", the system shall add the item to their shopping cart and show confirmation
+3. When a product page loads, the system shall display customer reviews sorted by most helpful
+4. When a user scrolls below the fold, the system shall lazy-load additional review content
+```
+
+**Domain Theories:**
+- Cialdini's Principles of Persuasion (social proof through reviews)
+- AIDA Model (Attention, Interest, Desire, Action)
+- Progressive Disclosure (lazy loading)
+
+**Enhanced Prompt:**
+```markdown
+# Role
+Expert e-commerce UX designer with deep knowledge of conversion optimization and persuasion psychology
+
+## Skills
+- Design high-converting product pages
+- Apply social proof principles effectively
+- Optimize for mobile and desktop experiences
+- Implement performance best practices (lazy loading, image optimization)
+
+## Workflows
+1. Product information architecture - Hero image, pricing, key features above fold
+2. Social proof integration - Star ratings, review count, verified purchases
+3. Call-to-action optimization - Prominent "Add to Cart" with clear availability status
+4. Progressive content loading - Reviews load on scroll to optimize initial page load
+5. Mobile-first responsive design - Touch-optimized buttons, readable typography
+
+## Examples
+- Hero section: Large product image gallery, price with strikethrough for discounts
+- Reviews section: "4.8/5 stars (1,247 reviews)" with filter by rating
+- CTA: "Add to Cart - In Stock" button, green color, 48px height for easy tapping
+
+## Formats
+Responsive HTML/CSS product page with:
+- Image carousel with thumbnails
+- Sticky add-to-cart bar on scroll
+- Collapsible product details
+- Paginated reviews with helpful/not helpful voting
+```
+
+### Example 3: Learning Platform Dashboard
+
+**Original (Vague):**
+```
+Build a dashboard for students to track their courses and progress
+```
+
+**EARS Transformation:**
+```
+1. When a student logs in, the system shall display enrolled courses with current progress percentages
+2. When a course deadline is within 7 days, the system shall highlight it with an urgent indicator
+3. When a student completes a lesson, the system shall update the course progress bar and award points
+4. When a student accesses the dashboard, the system shall show recommended next lessons based on learning path
+```
+
+**Domain Theories:**
+- Bloom's Taxonomy (learning progression)
+- Gamification (points, progress bars)
+- Information Architecture (dashboard layout)
+- Spaced Repetition (recommended next lessons)
+
+**Enhanced Prompt:**
+```markdown
+# Role
+Educational technology designer specializing in learning management systems and student engagement
+
+## Skills
+- Design effective learning dashboards
+- Apply gamification principles ethically
+- Visualize learning progress clearly
+- Implement personalized learning paths
+- Understand educational psychology
+
+## Workflows
+1. Dashboard layout - Course cards in grid, progress visualization prominent
+2. Progress tracking - Circular progress indicators, percentage complete, estimated time remaining
+3. Gamification elements - Points system, achievement badges, streak tracking
+4. Recommendation engine - Next lessons based on prerequisites and learning velocity
+5. Urgent/deadline management - Color-coded priorities, countdown timers
+
+## Examples
+- Course card: "Python Fundamentals | 67% complete | 5 hours remaining | Due in 3 days"
+- Achievement: "7-day streak! Keep going 🔥"
+- Recommendation: "Ready for the next lesson: Advanced Functions (15 min)"
+
+## Formats
+Dashboard with:
+- Grid layout of course cards (responsive 1-3 columns)
+- Progress rings with percentage labels
+- Upcoming deadlines section (sorted by urgency)
+- Achievements sidebar
+- "Continue Learning" CTA for most recent course
+```
+
+---
+
+## Transformation Pattern Template
+
+Use this template for any prompt optimization task:
+
+```markdown
+### Original Requirement
+[Paste user's vague requirement here]
+
+### EARS Transformation
+1. When <trigger>, the system shall <action>
+2. When <trigger>, the system shall <action>
+[Add more EARS statements as needed]
+
+### Domain Theories
+**Domain:** [Identify the primary domain]
+
+**Relevant Theories:**
+- Theory 1 - [Brief description]
+- Theory 2 - [Brief description]
+- Theory 3 - [Brief description]
+
+### Enhanced Prompt
+# Role
+[Specific expert role with domain expertise]
+
+## Skills
+- [Skill 1]
+- [Skill 2]
+[List 5-8 relevant skills]
+
+## Workflows
+1. [Step 1] - [Brief description]
+2. [Step 2] - [Brief description]
+[List complete workflow steps]
+
+## Examples
+[Extract concrete examples from original requirement or create relevant ones]
+
+## Formats
+[Specify exact output format requirements]
+```
+
+---
+
+## Example 4: Password Reset Feature (Security-Focused)
+
+### Original Requirement (Vague)
+
+```
+Build me a password reset feature
+```
+
+**Problems:**
+- No specification of reset method (email, SMS, security questions)
+- Missing security constraints (rate limiting, token expiration)
+- No UX flow defined (how user initiates, confirms reset)
+- Lack of error handling requirements
+
+### EARS Transformation
+
+```
+1. When user clicks "Forgot Password", the system shall display email input field
+
+2. When user submits valid email, the system shall send password reset link valid for 1 hour
+
+3. When user clicks reset link, the system shall verify token has not expired
+
+4. When token is valid, the system shall display password creation form requiring minimum 12 characters, 1 uppercase, 1 number, 1 special character
+
+5. When user submits new password meeting requirements, the system shall hash password with bcrypt and invalidate reset token
+
+6. When user attempts password reset more than 3 times in 1 hour, the system shall block further attempts for 1 hour
+
+7. If reset token has expired, the system shall display error message and option to request new link
+```
+
+### Domain Theories
+
+**Domain:** Authentication Security, User Experience Design
+
+**Relevant Theories:**
+- **Zero Trust Architecture** - Never trust input; verify token at each step
+- **Defense in Depth** - Multiple security layers (rate limiting, token expiration, password complexity)
+- **Progressive Disclosure** - Guide user through multi-step flow without overwhelming
+
+### Enhanced Prompt
+
+```markdown
+# Role
+Senior security engineer and UX designer specializing in authentication systems, with expertise in OWASP security standards and user-friendly security design.
+
+## Skills
+- Design secure password reset flows resistant to common attacks (brute force, token leakage)
+- Implement cryptographic best practices (bcrypt, secure token generation)
+- Apply UX principles to security-sensitive interactions
+- Handle edge cases and error states gracefully
+- Comply with GDPR and data protection regulations
+
+## Workflows
+1. Request initiation - User enters email, client-side validation for format
+2. Token generation - Server generates cryptographically random token (256-bit), stores with 1-hour expiration
+3. Email delivery - Send reset link via transactional email service with clear instructions
+4. Link validation - Verify token exists, not expired, not already used
+5. Password creation - Enforce complexity requirements with real-time feedback
+6. Password storage - Hash with bcrypt (cost factor 12), invalidate token, log security event
+7. Rate limiting - Track attempts by IP and email, implement exponential backoff
+
+## Examples
+- **Reset email:** Subject: "Password Reset Request", Body: "Click here to reset your password (link expires in 1 hour): https://example.com/reset?token=abc123..."
+- **Password requirements:** "Minimum 12 characters, at least 1 uppercase letter (A-Z), 1 number (0-9), 1 special character (!@#$%)"
+- **Error messages:** "This reset link has expired. Please request a new password reset link."
+- **Rate limiting:** "Too many reset attempts. Please try again in 59 minutes."
+
+## Formats
+Implement the following:
+- Backend API endpoints: POST /api/auth/forgot-password, POST /api/auth/reset-password
+- Email template (HTML) with reset link and instructions
+- Frontend pages: Forgot password form, Reset password form
+- Database schema: password_reset_tokens table (token, email, created_at, expires_at, used)
+- Security measures: Rate limiting middleware, token hashing in database, HTTPS-only cookies
+- Error handling: User-friendly messages, detailed server logs
+```
+
+**How to use:**
+Provide this to an AI code assistant or development team. The EARS requirements enable test-driven development, the theories justify security decisions, and the examples provide concrete test cases.
+
+**Next steps:** Implement the password reset feature using this specification, or iterate with additional security requirements (2FA, account recovery, etc.)