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, 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
1---2name: prompt-optimizer3description: Transform vague prompts into precise, well-structured specifications using EARS (Easy Approach to Requirements Syntax) methodology. This skill should be used when users provide loose requirements, ambiguous feature descriptions, or need to enhance prompts for AI-generated code, products, or documents. Triggers include requests to "optimize my prompt", "improve this requirement", "make this more specific", or when raw requirements lack detail and structure.4---5
6# Prompt Optimizer
7
8## Overview
9
10Optimize 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.
11
12**Methodology inspired by:** This skill's approach to combining EARS with domain theory grounding was inspired by [阿星AI工作室 (A-Xing AI Studio)](https://mp.weixin.qq.com/s/yUVX-9FovSq7ZGChkHpuXQ), which demonstrated practical EARS application for prompt enhancement.
13
14**Four-layer enhancement process:**
15
161. **EARS syntax transformation** - Convert descriptive language to normative specifications
172. **Domain theory grounding** - Apply relevant industry frameworks (GTD, BJ Fogg, Gestalt, etc.)
183. **Example extraction** - Surface concrete use cases with real data
194. **Structured prompt generation** - Format using Role/Skills/Workflows/Examples/Formats framework
20
21## When to Use
22
23Apply when:
24- User provides vague feature requests ("build a dashboard", "create a reminder app")
25- Requirements lack specific conditions, triggers, or measurable outcomes
26- Natural language descriptions need conversion to testable specifications
27- User explicitly requests prompt optimization or requirement refinement
28
29## Six-Step Optimization Workflow
30
31### Step 1: Analyze Original Requirement
32
33Identify weaknesses:
34- **Overly broad** - "Add user authentication" → Missing password requirements, session management
35- **Missing triggers** - "Send notifications" → Missing when/why notifications trigger
36- **Ambiguous actions** - "Make it user-friendly" → No measurable usability criteria
37- **No constraints** - "Process payments" → Missing security, compliance requirements
38
39### Step 2: Apply EARS Transformation
40
41Convert requirements to EARS patterns. See `references/ears_syntax.md` for complete syntax rules.
42
43**Five core patterns:**
441. **Ubiquitous**: `The system shall <action>`
452. **Event-driven**: `When <trigger>, the system shall <action>`
463. **State-driven**: `While <state>, the system shall <action>`
474. **Conditional**: `If <condition>, the system shall <action>`
485. **Unwanted behavior**: `If <condition>, the system shall prevent <unwanted action>`
49
50**Quick example:**
51```
52Before: "Create a reminder app with task management"
53
54After (EARS):
551. When user creates a task, the system shall guide decomposition into executable sub-tasks
562. When task deadline is within 30 minutes AND user has not started, the system shall send notification with sound alert
573. When user completes a sub-task, the system shall update progress and provide positive feedback
58```
59
60**Transformation checklist:**
61- [ ] Identify implicit conditions and make explicit
62- [ ] Specify triggering events or states
63- [ ] Use precise action verbs (shall, must, should)
64- [ ] Add measurable criteria ("within 30 minutes", "at least 8 characters")
65- [ ] Break compound requirements into atomic statements
66- [ ] Remove ambiguous language ("user-friendly", "fast")
67
68### Step 3: Identify Domain Theories
69
70Match requirements to established frameworks. See `references/domain_theories.md` for full catalog.
71
72**Common domain mappings:**
73- **Productivity** → GTD, Pomodoro, Eisenhower Matrix
74- **Behavior Change** → BJ Fogg Model (B=MAT), Atomic Habits
75- **UX Design** → Hick's Law, Fitts's Law, Gestalt Principles
76- **Security** → Zero Trust, Defense in Depth, Privacy by Design
77
78**Selection process:**
791. Identify primary domain from requirement keywords
802. Match to 2-4 complementary theories
813. Apply theory principles to specific features
824. Cite theories in enhanced prompt for credibility
83
84### Step 4: Extract Concrete Examples
85
86Generate specific examples with real data:
87- User scenarios: "When user logs in on mobile device..."
88- Data examples: "Product: 'Laptop', Price: $999, Stock: 15"
89- Workflow examples: "Task: Write report → Sub-tasks: Research (2h), Draft (3h), Edit (1h)"
90
91Examples must be **realistic**, **specific**, **varied** (success/error/edge cases), and **testable**.
92
93### Step 5: Generate Enhanced Prompt
94
95Structure using the standard framework:
96
97```markdown
98# Role
99[Specific expert role with domain expertise]
100
101## Skills
102- [Core capability 1]
103- [Core capability 2]
104[List 5-8 skills aligned with domain theories]
105
106## Workflows
1071. [Phase 1] - [Key activities]
1082. [Phase 2] - [Key activities]
109[Complete step-by-step process]
110
111## Examples
112[Concrete examples with real data, not placeholders]
113
114## Formats
115[Precise output specifications:
116- File types, structure requirements
117- Design/styling expectations
118- Technical constraints
119- Deliverable checklist]
120```
121
122**Quality criteria:**
123- **Role specificity**: "Product designer specializing in time management apps" > "Designer"
124- **Theory grounding**: Reference frameworks explicitly
125- **Actionable workflows**: Clear inputs/outputs and decision points
126- **Concrete examples**: Real data, not "Example 1", "Example 2"
127- **Measurable formats**: Specific requirements, not "good design"
128
129### Step 6: Present Optimization Results
130
131Output in structured format:
132
133```markdown
134## Original Requirement
135[User's vague requirement]
136
137**Identified Issues:**
138- [Issue 1: e.g., "Lacks specific trigger conditions"]
139- [Issue 2: e.g., "No measurable success criteria"]
140
141## EARS Transformation
142[Numbered list of EARS-formatted requirements]
143
144## Domain & Theories
145**Primary Domain:** [e.g., Authentication Security]
146
147**Applicable Theories:**
148- **[Theory 1]** - [Brief relevance]
149- **[Theory 2]** - [Brief relevance]
150
151## Enhanced Prompt
152[Complete Role/Skills/Workflows/Examples/Formats prompt]
153
154---
155
156**How to use:**
157[Brief guidance on applying the prompt]
158```
159
160## Advanced Techniques
161
162For complex scenarios, see `references/advanced_techniques.md`:
163- **Multi-stakeholder requirements** - EARS statements for each user type
164- **Non-functional requirements** - Performance, security, scalability with quantified thresholds
165- **Complex conditional logic** - Nested conditions with boolean operators
166
167## Quick Reference
168
169**Do's:**
170✅ Break down compound requirements (one EARS statement per requirement)
171✅ Specify measurable criteria (numbers, timeframes, percentages)
172✅ Include error/edge cases
173✅ Ground in established theories
174✅ Use concrete examples with real data
175
176**Don'ts:**
177❌ Avoid vague language ("fast", "user-friendly")
178❌ Don't assume implicit knowledge
179❌ Don't mix multiple actions in one statement
180❌ Don't use placeholders in examples
181
182## Resources
183
184Load these reference files as needed:
185
186- **`references/ears_syntax.md`** - Complete EARS syntax rules, all 5 patterns, transformation guidelines, benefits
187- **`references/domain_theories.md`** - 40+ theories mapped to 10 domains (productivity, UX, gamification, learning, e-commerce, security, etc.)
188- **`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
189- **`references/advanced_techniques.md`** - Multi-stakeholder requirements, non-functional specs, complex conditional logic patterns
190
191**When to load references:**
192- EARS syntax clarification needed → `ears_syntax.md`
193- Domain theory selection requires extensive options → `domain_theories.md`
194- User requests multiple optimization examples → `examples.md`
195- Complex requirements with multiple stakeholders or non-functional specs → `advanced_techniques.md`