domains / agent-tooling / prompt-optimization / prompt-optimizer

prompt-optimizer

Skill card

combined

The two skills share the name and the high-level goal of improving prompts, but they define different procedures. The daymade skill is a requirements-refinement workflow that converts vague feature requests into EARS specifications and then wraps them in a Role/Skills/Workflows/Examples/Formats prompt. The getsentry skill is an engineering workflow for agent/system prompts that emphasizes eval sets, model-family porting, external context inventory, and a candidate-generation optimization loop. Neither copy is a shortened or wrapped version of the other; each contains material steps and constraints the other lacks, so crowning one would hide a real alternative.

Repositories

Other copies

Combined skill

---
name: prompt-optimizer
description: >-
  Optimizes vague prompts, feature requests, and agent system prompts into precise, testable specifications. Use when requirements lack triggers or measurable outcomes, when the user asks to "optimize my prompt", or when building, refining, or porting agent prompts across model families.
---

# Prompt Optimizer

## Overview

This skill combines two complementary approaches:
1. **Requirements Refinement**: Transform vague feature requests into EARS (Easy Approach to Requirements Syntax) specifications grounded in domain theories.
2. **Agent Prompt Engineering**: Iteratively refine agent/system prompts using eval sets, model-family strategies, and external context inventory.

Choose the appropriate path based on the input:
- If the input is a **vague feature request** (e.g., "build a dashboard"), follow the **Requirements Refinement** path.
- If the input is an **existing agent/system prompt** or a request to **port/debug** a prompt, follow the **Agent Prompt Engineering** path.

## Path A: Requirements Refinement (EARS + Domain Theory)

### Step A1: Analyze Original Requirement
Identify weaknesses:
- Overly broad scope
- Missing triggers or conditions
- Ambiguous actions
- No constraints or measurable criteria

### Step A2: Apply EARS Transformation
Convert requirements to EARS 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>`

Checklist:
- Make implicit conditions explicit
- Specify triggering events or states
- Use precise action verbs (shall, must, should)
- Add measurable criteria
- Break compound requirements into atomic statements
- Remove ambiguous language

### Step A3: Identify Domain Theories
Match requirements to established frameworks:
- Productivity → GTD, Pomodoro, Eisenhower Matrix
- Behavior Change → BJ Fogg Model, Atomic Habits
- UX Design → Hick's Law, Fitts's Law, Gestalt Principles
- Security → Zero Trust, Defense in Depth

Apply 2-4 complementary theories and cite them in the enhanced prompt.

### Step A4: Extract Concrete Examples
Generate specific examples with real data:
- User scenarios
- Data examples
- Workflow examples

Examples must be realistic, specific, varied (success/error/edge cases), and testable.

### Step A5: Generate Enhanced Prompt
Structure using the Role/Skills/Workflows/Examples/Formats framework:

```markdown
# Role
[Specific expert role with domain expertise]

## Skills
- [Core capability 1]
- [Core capability 2]

## Workflows
1. [Phase 1] - [Key activities]
2. [Phase 2] - [Key activities]

## Examples
[Concrete examples with real data]

## Formats
[Precise output specifications]
```

### Step A6: Present Optimization Results
Output in structured format:
- Original Requirement
- Identified Issues
- EARS Transformation
- Domain & Theories
- Enhanced Prompt
- How to use

## Path B: Agent Prompt Engineering (Evals + Model Strategy)

### Step B1: Capture Contract
Record before editing:
- Task type: new, refine, port, or debug
- Target model family and snapshot
- Prompt surface: system, developer, user, tool descriptions, examples, schemas
- Layer owners: platform, deployer/persona, retrieved context, user payload
- Objective and non-goals
- Inputs, tools, and external files available
- Required output shape
- Success criteria and failure cases
- Hard constraints: latency, verbosity, safety, budget, tool use, style

If success criteria or examples are missing, create a small eval set first.

### Step B2: Inventory External Context
For repo or agent prompts, list stable context by exact path:
- Agent rules (e.g., `AGENTS.md`, `CLAUDE.md`)
- Specs (e.g., `specs/*.md`)
- Policies (e.g., `SECURITY.md`)
- Examples (e.g., `examples/`, `tests/fixtures/`)

Rules:
- Reference stable files by repo-relative path instead of copying them.
- Paste only excerpts needed for the prompt or eval case.
- Mark whether a file is `loaded`, `referenced`, or `out of scope`.
- Avoid vague context pointers.

### Step B3: Choose Model Strategy
- Known family: optimize for that family.
- Unknown family: write a portable base plus short adapter notes.
- Snapshot changes: rerun evals.
- Cross-family divergence: specialize only the failing layer.

### Step B4: Shape Prompt
- Put stable policy in `system` or `developer`.
- Put task-local facts, retrieved context, and variables in user-facing sections.
- Keep one owner per behavior rule.
- Use headings or tags only to separate content types.
- Put tool policy in prompt text; keep schemas in provider-native tools.
- Keep persona light unless it changes behavior.
- Use the shortest wording that preserves the constraint.
- Cut filler, repeated reminders, dead examples, and rationale that does not affect evals.

### Step B5: Optimize
1. Baseline the current prompt on the same eval slice.
2. Cluster failures by root cause.
3. Write concrete edit criticisms.
4. Generate two to four candidates:
   - minimal-diff repair
   - structure-first rewrite
   - examples-first or tool-rule variant
   - provider adapter when needed
5. Compare candidates on the same cases.
6. Keep a short optimization log.
7. Validate the winner on holdout cases.
8. Stop on plateau, oscillation, overfit, excessive cost, or non-prompt bottleneck.

### Step B6: Return Package
Return:
1. `Target`
2. `Success Criteria`
3. `External Context`
4. `Optimized Prompt`
5. `Adapter Notes`
6. `Eval Set`
7. `Optimization Log`
8. `Residual Risks`

For existing prompts, include a concise diff-style note of the main behavioral changes.

## Conflicts

- **daymade/claude-code-skills** uses EARS transformation and domain theory grounding as core steps, while **getsentry/skills** uses eval-based optimization and model-family strategy as core steps. These are distinct methodologies for different prompt types.
- **daymade/claude-code-skills** outputs a Role/Skills/Workflows/Examples/Formats prompt, while **getsentry/skills** outputs a structured package including eval sets, optimization logs, and residual risks.
- **daymade/claude-code-skills** does not mention model families or evals, while **getsentry/skills** does not mention EARS or domain theories.