df2e654b1d
Add new prompt-optimizer skill (v1.1.0) for transforming vague prompts into precise EARS specifications: New Features: - EARS (Easy Approach to Requirements Syntax) transformation with 5 patterns - 6-step optimization workflow (analyze, transform, theories, examples, enhance, present) - Domain theory grounding (40+ frameworks across 10 domains) - Role/Skills/Workflows/Examples/Formats prompt enhancement framework - Progressive disclosure with 4 bundled reference files Skill Improvements (v1.0.0 → v1.1.0): - Reduced SKILL.md from 369 to 195 lines (47% reduction) - Added advanced_techniques.md (325 lines) for complex scenarios - Added 4th complete example (password reset security) - Added attribution to 阿星AI工作室 (A-Xing AI Studio) - Enhanced reference loading guidance Marketplace Updates: - Updated marketplace to v1.11.0 (17 → 18 skills) - Updated all documentation (README.md, README.zh-CN.md, CLAUDE.md) - Added Chinese and English descriptions with attribution 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com>
124 lines
3.9 KiB
Markdown
124 lines
3.9 KiB
Markdown
# EARS (Easy Approach to Requirements Syntax)
|
|
|
|
## Overview
|
|
|
|
EARS (Easy Approach to Requirements Syntax) is a structured requirements writing methodology created by Rolls-Royce in 2009. It transforms natural language descriptions into precise, actionable specifications.
|
|
|
|
## Core Principle
|
|
|
|
Convert requirements from **descriptive** to **normative** by decomposing them into:
|
|
|
|
1. **Entity** - What component/system is involved
|
|
2. **Action** - What operation/behavior should occur
|
|
3. **Relationship** - How entities interact
|
|
4. **Scope** - Under what conditions/constraints
|
|
|
|
## EARS Sentence Patterns
|
|
|
|
### Pattern 1: Ubiquitous (Unconditional)
|
|
|
|
**Format:** `系统应 <action>`
|
|
**English:** `The system shall <action>`
|
|
|
|
**Use when:** Requirement always applies, no preconditions
|
|
|
|
**Example:**
|
|
- Natural: "The app needs a login page"
|
|
- EARS: "The system shall provide a login interface"
|
|
|
|
### Pattern 2: Event-Driven
|
|
|
|
**Format:** `当 <trigger> 时,系统应 <action>`
|
|
**English:** `When <trigger>, the system shall <action>`
|
|
|
|
**Use when:** Requirement applies upon specific event
|
|
|
|
**Example:**
|
|
- Natural: "Send reminder before deadline"
|
|
- EARS: "When the task deadline is within 30 minutes, the system shall send a reminder notification"
|
|
|
|
### Pattern 3: State-Driven
|
|
|
|
**Format:** `在 <state> 状态下,系统应 <action>`
|
|
**English:** `While <state>, the system shall <action>`
|
|
|
|
**Use when:** Requirement applies during a specific state
|
|
|
|
**Example:**
|
|
- Natural: "Show loading spinner during data fetch"
|
|
- EARS: "While data is being fetched, the system shall display a loading spinner"
|
|
|
|
### Pattern 4: Optional Feature
|
|
|
|
**Format:** `若 <condition>,系统应 <action>`
|
|
**English:** `If <condition>, then the system shall <action>`
|
|
|
|
**Use when:** Requirement is conditional
|
|
|
|
**Example:**
|
|
- Natural: "Premium users get extra features"
|
|
- EARS: "If the user has a premium subscription, the system shall enable advanced analytics features"
|
|
|
|
### Pattern 5: Unwanted Behavior
|
|
|
|
**Format:** `若 <condition>,系统应避免 <unwanted action>`
|
|
**English:** `If <condition>, the system shall prevent <unwanted action>`
|
|
|
|
**Use when:** Specifying constraints or prohibited behaviors
|
|
|
|
**Example:**
|
|
- Natural: "Don't allow duplicate submissions"
|
|
- EARS: "If a submission is already in progress, the system shall prevent duplicate form submissions"
|
|
|
|
## Complex EARS Patterns
|
|
|
|
### Multi-Condition Events
|
|
|
|
**Format:** `当 <condition1> 且 <condition2> 时,系统应 <action>`
|
|
|
|
**Example:**
|
|
```
|
|
When the task deadline is within 30 minutes
|
|
AND the user has not started the task,
|
|
the system shall trigger a notification with encouraging message and sound alert.
|
|
```
|
|
|
|
### Conditional Actions with Alternatives
|
|
|
|
**Format:**
|
|
```
|
|
When <trigger>:
|
|
- If <condition1>, the system shall <action1>
|
|
- If <condition2>, the system shall <action2>
|
|
- Otherwise, the system shall <default action>
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
When user submits a form:
|
|
- If all required fields are filled, the system shall process the submission
|
|
- If any required field is empty, the system shall highlight missing fields
|
|
- Otherwise, the system shall display a general error message
|
|
```
|
|
|
|
## EARS Transformation Checklist
|
|
|
|
When converting natural language to EARS:
|
|
|
|
- [ ] Identify all implicit conditions and make them explicit
|
|
- [ ] Specify the triggering event or state
|
|
- [ ] Define the actor (usually "the system")
|
|
- [ ] Use precise action verbs (shall, should, must)
|
|
- [ ] Specify measurable outcomes where possible
|
|
- [ ] Break compound requirements into atomic statements
|
|
- [ ] Remove ambiguous language ("user-friendly", "fast", "intuitive")
|
|
- [ ] Add quantitative criteria ("within 30 minutes", "at least 8 characters")
|
|
|
|
## Benefits
|
|
|
|
1. **Clarity** - Eliminates ambiguity through structured syntax
|
|
2. **Completeness** - Forces specification of conditions and triggers
|
|
3. **Testability** - Clear requirements enable automated testing
|
|
4. **Atomicity** - Each requirement is independent and self-contained
|
|
5. **Traceability** - Easy to map requirements to features
|