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.
86
80%
Does it follow best practices?
Impact
96%
1.62xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./prompt-optimizer/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-crafted description that excels at completeness and trigger term quality, clearly stating both what the skill does and when to use it with natural user phrases. The main weakness is that the specificity of capabilities could be stronger — it describes the general transformation but doesn't enumerate the specific concrete actions or outputs the skill produces. The EARS methodology mention adds good distinctiveness.
Suggestions
Add more specific concrete actions beyond 'transform', such as 'categorize requirements by type (ubiquitous, event-driven, state-driven), identify missing edge cases, and output structured EARS-formatted specifications'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (prompt/requirement transformation) and mentions the EARS methodology, but the concrete actions are limited to 'transform vague prompts into precise, well-structured specifications' — it doesn't list multiple distinct actions like parsing, structuring, categorizing, or outputting specific formats. | 2 / 3 |
Completeness | Clearly answers both 'what' (transform vague prompts into precise specifications using EARS methodology) and 'when' (explicit 'Use when' equivalent with trigger phrases and situational descriptions like 'when raw requirements lack detail and structure'). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'optimize my prompt', 'improve this requirement', 'make this more specific', 'loose requirements', 'ambiguous feature descriptions'. These are phrases users would naturally say when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The EARS methodology reference and the specific focus on prompt/requirement refinement create a clear niche. The trigger terms are distinct enough ('optimize my prompt', 'improve this requirement') to avoid conflicting with general coding or document skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
70%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured skill with strong workflow clarity and excellent progressive disclosure through reference files. Its main weaknesses are moderate verbosity (explaining concepts Claude already understands, like what makes requirements vague) and actionability gaps in the domain theory grounding step, which names frameworks without showing concrete application. The EARS transformation section is the strongest part, with clear patterns and a useful before/after example.
Suggestions
Trim Step 1 (Analyze Original Requirement) significantly—Claude already knows how to identify vague requirements; the four bullet examples are unnecessary padding.
Make Step 3 (Domain Theories) more actionable by showing a concrete example of how a theory actually transforms a requirement, rather than just listing theory names and a generic selection process.
Remove the attribution paragraph—it consumes tokens without adding actionable guidance for Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary elaboration (e.g., the attribution paragraph, explaining what EARS stands for multiple times, the domain theory selection process) but is generally reasonably structured. The methodology overview and step descriptions could be tighter—Claude doesn't need to be told what 'overly broad' means with examples of obvious weaknesses. | 2 / 3 |
Actionability | The skill provides concrete EARS patterns and a transformation example, plus a structured output template. However, much of the guidance is meta-level (how to think about optimization) rather than directly executable. The 'domain theory grounding' step is vague—listing theory names without showing how to actually apply them to transform requirements. The output templates use placeholders rather than fully worked examples. | 2 / 3 |
Workflow Clarity | The six-step workflow is clearly sequenced with explicit inputs/outputs at each stage. The transformation checklist in Step 2 serves as a validation checkpoint, and the final output format in Step 6 provides a clear deliverable structure. Each step has a defined purpose and the sequence is logical. | 3 / 3 |
Progressive Disclosure | Excellent use of progressive disclosure—the main skill provides a complete overview with clear pointers to four reference files (ears_syntax.md, domain_theories.md, examples.md, advanced_techniques.md). References are one level deep, clearly signaled with descriptions, and include guidance on when to load each file. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
80e94fd
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.