prompt-optimizer

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 attribution: EARS + domain-theory grounding の組み合わせは外部記事に着想を得たもの (出典は frontmatter metadata.origin)。

Four-layer enhancement process:

1. EARS syntax transformation - Convert descriptive language to normative specifications
2. Domain theory grounding - Apply relevant industry frameworks (GTD, BJ Fogg, Gestalt, etc.)
3. Example extraction - Surface concrete use cases with real data
4. 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:

1. Ubiquitous: The system shall <action>
2. Event-driven: When <trigger>, the system shall <action>
3. State-driven: While <state>, the system shall <action>
4. Conditional: If <condition>, the system shall <action>
5. 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:

• Identify implicit conditions and make explicit
• Specify triggering events or states
• Use precise action verbs (shall, must, should)
• Add measurable criteria ("within 30 minutes", "at least 8 characters")
• Break compound requirements into atomic statements
• Remove ambiguous language ("user-friendly", "fast")

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:

1. Identify primary domain from requirement keywords
2. Match to 2-4 complementary theories
3. Apply theory principles to specific features
4. 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"

ステップ 6：最適化の結果を提示する

構造化された形式で出力します：

## 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]

高度なテクニック

複雑なシナリオについては、references/advanced_techniques.md を参照してください：

• 複数のステークホルダーが関わる要件 - ユーザーの種類ごとの EARS ステートメント
• 非機能要件 - 定量化されたしきい値を含むパフォーマンス、セキュリティ、スケーラビリティ
• 複雑な条件ロジック - ブール演算子を使った入れ子の条件

クイックリファレンス

推奨事項： ✅ 複合要件を分解する（要件ごとに EARS ステートメントを 1 つ作成する） ✅ 測定可能な基準を指定する（数値、期間、割合） ✅ エラーケースやエッジケースを含める ✅ 確立された理論に基づかせる ✅ 実際のデータを使った具体例を使用する

避けるべきこと： ❌ 曖昧な表現（「速い」「使いやすい」）を避ける ❌ 暗黙の知識を前提としない ❌ 1 つのステートメントに複数のアクションを混在させない ❌ 例にプレースホルダーを使用しない

リソース

必要に応じて、以下のリファレンスファイルを読み込んでください：

• references/ears_syntax.md - EARS 構文規則の全容、5 つのパターンすべて、変換ガイドライン、利点
• references/domain_theories.md - 10 のドメイン（生産性、UX、ゲーミフィケーション、学習、e コマース、セキュリティなど）に分類された 40 以上の理論
• references/examples.md - 4 つの完全な変換例（先延ばし防止アプリ、e コマースの商品ページ、学習ダッシュボード、パスワードリセットのセキュリティ）。変換前後の比較と再利用可能なテンプレートを含みます
• references/advanced_techniques.md - 複数のステークホルダーが関わる要件、非機能仕様、複雑な条件ロジックのパターン

リファレンスの読み込みが必要な場合：

• EARS 構文の確認が必要 → ears_syntax.md
• ドメイン理論の選定に幅広い選択肢が必要 → domain_theories.md
• ユーザーが複数の最適化例を求めている → examples.md
• 複数のステークホルダーが関わる複雑な要件、または非機能仕様がある → advanced_techniques.md