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---56# Prompt Optimizer78## Overview910Optimize 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.1112**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.1314**Four-layer enhancement process:**15161. **EARS syntax transformation** - Convert descriptive language to normative specifications172. **Domain theory grounding** - Apply relevant industry frameworks (GTD, BJ Fogg, Gestalt, etc.)183. **Example extraction** - Surface concrete use cases with real data194. **Structured prompt generation** - Format using Role/Skills/Workflows/Examples/Formats framework2021## When to Use2223Apply when:24- User provides vague feature requests ("build a dashboard", "create a reminder app")25- Requirements lack specific conditions, triggers, or measurable outcomes26- Natural language descriptions need conversion to testable specifications27- User explicitly requests prompt optimization or requirement refinement2829## Six-Step Optimization Workflow3031### Step 1: Analyze Original Requirement3233Identify weaknesses:34- **Overly broad** - "Add user authentication" → Missing password requirements, session management35- **Missing triggers** - "Send notifications" → Missing when/why notifications trigger36- **Ambiguous actions** - "Make it user-friendly" → No measurable usability criteria37- **No constraints** - "Process payments" → Missing security, compliance requirements3839### Step 2: Apply EARS Transformation4041Convert requirements to EARS patterns. See `references/ears_syntax.md` for complete syntax rules.4243**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>`4950**Quick example:**51```52Before: "Create a reminder app with task management"5354After (EARS):551. When user creates a task, the system shall guide decomposition into executable sub-tasks562. When task deadline is within 30 minutes AND user has not started, the system shall send notification with sound alert573. When user completes a sub-task, the system shall update progress and provide positive feedback58```5960**Transformation checklist:**61- [ ] Identify implicit conditions and make explicit62- [ ] Specify triggering events or states63- [ ] Use precise action verbs (shall, must, should)64- [ ] Add measurable criteria ("within 30 minutes", "at least 8 characters")65- [ ] Break compound requirements into atomic statements66- [ ] Remove ambiguous language ("user-friendly", "fast")6768### Step 3: Identify Domain Theories6970Match requirements to established frameworks. See `references/domain_theories.md` for full catalog.7172**Common domain mappings:**73- **Productivity** → GTD, Pomodoro, Eisenhower Matrix74- **Behavior Change** → BJ Fogg Model (B=MAT), Atomic Habits75- **UX Design** → Hick's Law, Fitts's Law, Gestalt Principles76- **Security** → Zero Trust, Defense in Depth, Privacy by Design7778**Selection process:**791. Identify primary domain from requirement keywords802. Match to 2-4 complementary theories813. Apply theory principles to specific features824. Cite theories in enhanced prompt for credibility8384### Step 4: Extract Concrete Examples8586Generate 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)"9091Examples must be **realistic**, **specific**, **varied** (success/error/edge cases), and **testable**.9293### Step 5: Generate Enhanced Prompt9495Structure using the standard framework:9697```markdown98# Role99[Specific expert role with domain expertise]100101## Skills102- [Core capability 1]103- [Core capability 2]104[List 5-8 skills aligned with domain theories]105106## Workflows1071. [Phase 1] - [Key activities]1082. [Phase 2] - [Key activities]109[Complete step-by-step process]110111## Examples112[Concrete examples with real data, not placeholders]113114## Formats115[Precise output specifications:116- File types, structure requirements117- Design/styling expectations118- Technical constraints119- Deliverable checklist]120```121122**Quality criteria:**123- **Role specificity**: "Product designer specializing in time management apps" > "Designer"124- **Theory grounding**: Reference frameworks explicitly125- **Actionable workflows**: Clear inputs/outputs and decision points126- **Concrete examples**: Real data, not "Example 1", "Example 2"127- **Measurable formats**: Specific requirements, not "good design"128129### Step 6: Present Optimization Results130131Output in structured format:132133```markdown134## Original Requirement135[User's vague requirement]136137**Identified Issues:**138- [Issue 1: e.g., "Lacks specific trigger conditions"]139- [Issue 2: e.g., "No measurable success criteria"]140141## EARS Transformation142[Numbered list of EARS-formatted requirements]143144## Domain & Theories145**Primary Domain:** [e.g., Authentication Security]146147**Applicable Theories:**148- **[Theory 1]** - [Brief relevance]149- **[Theory 2]** - [Brief relevance]150151## Enhanced Prompt152[Complete Role/Skills/Workflows/Examples/Formats prompt]153154---155156**How to use:**157[Brief guidance on applying the prompt]158```159160## Advanced Techniques161162For complex scenarios, see `references/advanced_techniques.md`:163- **Multi-stakeholder requirements** - EARS statements for each user type164- **Non-functional requirements** - Performance, security, scalability with quantified thresholds165- **Complex conditional logic** - Nested conditions with boolean operators166167## Quick Reference168169**Do's:**170✅ Break down compound requirements (one EARS statement per requirement)171✅ Specify measurable criteria (numbers, timeframes, percentages)172✅ Include error/edge cases173✅ Ground in established theories174✅ Use concrete examples with real data175176**Don'ts:**177❌ Avoid vague language ("fast", "user-friendly")178❌ Don't assume implicit knowledge179❌ Don't mix multiple actions in one statement180❌ Don't use placeholders in examples181182## Resources183184Load these reference files as needed:185186- **`references/ears_syntax.md`** - Complete EARS syntax rules, all 5 patterns, transformation guidelines, benefits187- **`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 template189- **`references/advanced_techniques.md`** - Multi-stakeholder requirements, non-functional specs, complex conditional logic patterns190191**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`