Prompt Optimizer
Overview
Optimize vague prompts into precise, actionable specifications using EARS (Easy Approach to Requirements Syntax) - a Rolls-Royce methodology for transforming natural language into structured, testable requirements.
Methodology inspired by: This skill's approach to combining EARS with domain theory grounding was inspired by 阿星AI工作室 (A-Xing AI Studio), which demonstrated practical EARS application for prompt enhancement.
Four-layer enhancement process:
- •EARS syntax transformation - Convert descriptive language to normative specifications
- •Domain theory grounding - Apply relevant industry frameworks (GTD, BJ Fogg, Gestalt, etc.)
- •Example extraction - Surface concrete use cases with real data
- •Structured prompt generation - Format using Role/Skills/Workflows/Examples/Formats framework
When to Use
Apply when:
- •User provides vague feature requests ("build a dashboard", "create a reminder app")
- •Requirements lack specific conditions, triggers, or measurable outcomes
- •Natural language descriptions need conversion to testable specifications
- •User explicitly requests prompt optimization or requirement refinement
Six-Step Optimization Workflow
Step 1: Analyze Original Requirement
Identify weaknesses:
- •Overly broad - "Add user authentication" → Missing password requirements, session management
- •Missing triggers - "Send notifications" → Missing when/why notifications trigger
- •Ambiguous actions - "Make it user-friendly" → No measurable usability criteria
- •No constraints - "Process payments" → Missing security, compliance requirements
Step 2: Apply EARS Transformation
Convert requirements to EARS patterns. See references/ears_syntax.md for complete syntax rules.
Five core patterns:
- •Ubiquitous:
The system shall <action> - •Event-driven:
When <trigger>, the system shall <action> - •State-driven:
While <state>, the system shall <action> - •Conditional:
If <condition>, the system shall <action> - •Unwanted behavior:
If <condition>, the system shall prevent <unwanted action>
Quick example:
Before: "Create a reminder app with task management" After (EARS): 1. When user creates a task, the system shall guide decomposition into executable sub-tasks 2. When task deadline is within 30 minutes AND user has not started, the system shall send notification with sound alert 3. When user completes a sub-task, the system shall update progress and provide positive feedback
Transformation checklist:
- • Identify implicit conditions and make explicit
- • Specify triggering events or states
- • Use precise action verbs (shall, must, should)
- • Add measurable criteria ("within 30 minutes", "at least 8 characters")
- • Break compound requirements into atomic statements
- • Remove ambiguous language ("user-friendly", "fast")
Step 3: Identify Domain Theories
Match requirements to established frameworks. See references/domain_theories.md for full catalog.
Common domain mappings:
- •Productivity → GTD, Pomodoro, Eisenhower Matrix
- •Behavior Change → BJ Fogg Model (B=MAT), Atomic Habits
- •UX Design → Hick's Law, Fitts's Law, Gestalt Principles
- •Security → Zero Trust, Defense in Depth, Privacy by Design
Selection process:
- •Identify primary domain from requirement keywords
- •Match to 2-4 complementary theories
- •Apply theory principles to specific features
- •Cite theories in enhanced prompt for credibility
Step 4: Extract Concrete Examples
Generate specific examples with real data:
- •User scenarios: "When user logs in on mobile device..."
- •Data examples: "Product: 'Laptop', Price: $999, Stock: 15"
- •Workflow examples: "Task: Write report → Sub-tasks: Research (2h), Draft (3h), Edit (1h)"
Examples must be realistic, specific, varied (success/error/edge cases), and testable.
Step 5: Generate Enhanced Prompt
Structure using the standard framework:
# Role [Specific expert role with domain expertise] ## Skills - [Core capability 1] - [Core capability 2] [List 5-8 skills aligned with domain theories] ## Workflows 1. [Phase 1] - [Key activities] 2. [Phase 2] - [Key activities] [Complete step-by-step process] ## Examples [Concrete examples with real data, not placeholders] ## Formats [Precise output specifications: - File types, structure requirements - Design/styling expectations - Technical constraints - Deliverable checklist]
Quality criteria:
- •Role specificity: "Product designer specializing in time management apps" > "Designer"
- •Theory grounding: Reference frameworks explicitly
- •Actionable workflows: Clear inputs/outputs and decision points
- •Concrete examples: Real data, not "Example 1", "Example 2"
- •Measurable formats: Specific requirements, not "good design"
Step 6: Present Optimization Results
Output in structured format:
## Original Requirement [User's vague requirement] **Identified Issues:** - [Issue 1: e.g., "Lacks specific trigger conditions"] - [Issue 2: e.g., "No measurable success criteria"] ## EARS Transformation [Numbered list of EARS-formatted requirements] ## Domain & Theories **Primary Domain:** [e.g., Authentication Security] **Applicable Theories:** - **[Theory 1]** - [Brief relevance] - **[Theory 2]** - [Brief relevance] ## Enhanced Prompt [Complete Role/Skills/Workflows/Examples/Formats prompt] --- **How to use:** [Brief guidance on applying the prompt]
Advanced Techniques
For complex scenarios, see references/advanced_techniques.md:
- •Multi-stakeholder requirements - EARS statements for each user type
- •Non-functional requirements - Performance, security, scalability with quantified thresholds
- •Complex conditional logic - Nested conditions with boolean operators
Quick Reference
Do's: ✅ Break down compound requirements (one EARS statement per requirement) ✅ Specify measurable criteria (numbers, timeframes, percentages) ✅ Include error/edge cases ✅ Ground in established theories ✅ Use concrete examples with real data
Don'ts: ❌ Avoid vague language ("fast", "user-friendly") ❌ Don't assume implicit knowledge ❌ Don't mix multiple actions in one statement ❌ Don't use placeholders in examples
Resources
Load these reference files as needed:
- •
references/ears_syntax.md- Complete EARS syntax rules, all 5 patterns, transformation guidelines, benefits - •
references/domain_theories.md- 40+ theories mapped to 10 domains (productivity, UX, gamification, learning, e-commerce, security, etc.) - •
references/examples.md- Four complete transformation examples (procrastination app, e-commerce product page, learning dashboard, password reset security) with before/after comparisons and reusable template - •
references/advanced_techniques.md- Multi-stakeholder requirements, non-functional specs, complex conditional logic patterns
When to load references:
- •EARS syntax clarification needed →
ears_syntax.md - •Domain theory selection requires extensive options →
domain_theories.md - •User requests multiple optimization examples →
examples.md - •Complex requirements with multiple stakeholders or non-functional specs →
advanced_techniques.md