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:
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, benefitsreferences/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 templatereferences/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
