--- name: Prompt Optimization Loop slug: prompt-optimization-loop category: AI Engineering description: Prompt Optimization Loop improves an existing prompt by making one targeted edit at a time and re-running a user-provided eval command to see whether the score rises. It is for prompts that already have a measurable metric, not for writing prompts from scratch or changing model settings. github: "https://github.com/gaasher/Agent-Loop-Skills/tree/main/loops/prompt-optimize" language: Python stars: 166 forks: 19 install: "npx degit https://github.com/gaasher/Agent-Loop-Skills/tree/main/loops/prompt-optimize ~/.claude/skills/prompt-optimize" installs_to: ~/.claude/skills/prompt-optimize source_path: loops/prompt-optimize/SKILL.md collection_size: 25 category_size: 3670 collection_url: "https://dirskills.com/collections/gaasher/Agent-Loop-Skills" added: 2026-09-08T05:34:44.513Z last_synced: 2026-09-08T05:34:44.513Z canonical_url: "https://dirskills.com/skills/prompt-optimization-loop" --- # Prompt Optimization Loop Prompt Optimization Loop improves an existing prompt by making one targeted edit at a time and re-running a user-provided eval command to see whether the score rises. It is for prompts that already have a measurable metric, not for writing prompts from scratch or changing model settings. **Install:** ```bash npx degit https://github.com/gaasher/Agent-Loop-Skills/tree/main/loops/prompt-optimize ~/.claude/skills/prompt-optimize ``` ## README # Prompt Optimize Loop An **evolutionary optimizer for a prompt** (OpenEvolve / AlphaEvolve-style). The artifact is a prompt that feeds the user's system; the feedback signal is a **scalar metric printed by the user's own evaluation command**. Each iteration proposes one quality-focused edit, re-runs the eval, and keeps the edit only if the metric improves — evolving the prompt toward higher scores. The eval is a black-box oracle the loop runs but never edits, so the optimization tracks what actually matters rather than gaming a number. ## When to use Use this when the user has a prompt and a command that scores the system using it, and wants the prompt improved to raise that score. Default to diagnosing the prompt's biggest current weakness each round and applying the one operator that addresses it; if the eval feedback points elsewhere, follow the feedback. Not for authoring a prompt from nothing, tuning weights/hyperparameters, or making a single manual edit with no score to compare against. ## Setup Resolve bindings interactively. If `loop.run.yaml` exists in the working dir, load it, confirm the values in one line, and skip to the loop. Otherwise: on Claude Code (the `AskUserQuestion` tool is available) infer a likely value for each binding and present it as the recommended option; on other hosts ask each as a quoted plain-text prompt. Then write `loop.run.yaml` (format: `examples/run.example.yaml`) and confirm the values before creating any other files. | binding | meaning | default | how to infer | |---|---|---|---| | `` | the prompt to optimize — the artifact the loop evolves | — | scan the working dir for the prompt/template file the eval reads | | `` | **required.** Command that scores the current ``; prints the metric (see output convention below). Treated as a black box — never edited | — | ask the user; look for `eval`/`score`/`bench` scripts | | `` | `maximize` or `minimize`, plus one line on what the metric measures | `maximize` | ask the user | | `` | optional score at which to stop early | — | ask the user; else leave unbound | | `` | where prompt snapshots + ledger live | `./sandbox` | — | | `` | max iterations | 10 | — | | `` | stop after N consecutive non-improving iterations (plateau) | 3 | — | **Eval output convention.** `` must print, on its **last line**, either a JSON object `{"score": , "feedback": "", ...any extra metrics...}` or a bare number. Higher is better unless `` is `minimize`. The `feedback` field, when present, is the richest signal — read it like AlphaEvolve's artifacts side-channel to decide the next edit. **Eval runs in the user's environment.** `` may call an inference endpoint or any tooling the user has installed; the loop just shells out and reads the last line. If instead the prompt is executed by *you* (interactive development with no separate endpoint), first run the current prompt over the user's eval inputs to produce outputs, write them where `` reads, then run `` to score them. ## The loop Copy this checklist and tick items off: - [ ] Iteration 0 — baseline: run `` on ``, record its score as the current best, snapshot the prompt. - [ ] Diagnose the prompt's single biggest weakness from the latest score, the eval feedback, and the history. - [ ] Apply one targeted edit (one operator from the toolkit) to ``. - [ ] Measure: re-run `` and read the new score from its last line. - [ ] Keep if the metric improves (require a margin if the eval is stochastic), else revert to the best snapshot. - [ ] Append a ledger row; if stuck, branch from an earlier high-scoring variant; stop on ``, plateau (``), or ``. **Iteration 0 — baseline.** Run ``, record its score as the best, snapshot `` to `/iter0/`, and start the history (`{iter, edit, score, feedback}` per row). **Then, until stop (target, plateau, or budget):** 1. **Diagnose.** From the latest score, the `` feedback, and recent history, name the prompt's single biggest current weakness — the one thing most likely holding the metric back. 2. **Make one targeted edit** — pick the toolkit operator that addresses that weakness: - **Clarity** — remove ambiguity, contradictions, and vague wording. - **Context** — supply missing domain knowledge, definitions, or background the task needs. - **Specificity** — make instructions concrete; pin down the output format; define what "good" is. - **Structure** — order the prompt into steps/sections; add a short checklist. - **Examples** — add one or two demonstrations of the desired input → output. - **Decomposition** — split a complex instruction into explicit ordered sub-steps. - **Guardrails** — state edge cases and what to avoid. One change per iteration, so its effect on the metric is attributable. 3. **Measure.** Snapshot the edited prompt to `/iter/`, run ``, and read the new score off the last line. 4. **Keep or revert.** **Keep** if the metric improves per `` (if the eval is stochastic, require a small margin so noise alone does not drive a keep); otherwise **revert** `` to the previous best snapshot. Append `{edit, score, feedback}` to the history either way. 5. **Escape local optima.** If the score has not improved for a couple of iterations, stop making tiny tweaks — branch from an earlier high-scoring snapshot, or try a bolder restructuring (a different decomposition, a fresh set of examples). Diversity beats grinding the same local hill. When stopping, restore the **best** prompt to `` and report the score trajectory, which edits moved the metric (and which did not), and the final prompt. ## Ledger `/ledger.tsv`, tab-separated, never commas in the text. Header: ``` iter score status edit ``` `status` ∈ {`baseline`, `keep`, `revert`}. Example (metric = task accuracy, maximize): ``` iter score status edit 0 0.42 baseline original prompt 1 0.61 keep specificity: define each output label and the exact output format 2 0.61 revert examples: add 3 few-shot demos — no metric gain 3 0.78 keep context: add the domain rules the task assumes but never states ``` Report the **best** iteration, not necessarily the last. ## Constraints - **The metric is the user's.** Never edit ``, its data, or its scoring — that games the number instead of improving the prompt, and the eval is the only ground truth the loop has. - **Optimize the prompt only, and preserve the task's intent.** Improve *how* the task is instructed, not *what* is being asked; do not tailor the prompt to exploit eval quirks that would break real use. - **One edit per iteration**, and compare the *metric* by re-running the full ``, not a single sample, so each score delta is attributable to that one edit. - **Report the best variant, not the last.** The sandbox is self-contained — no `../` escapes. - Do not pause the loop to ask whether to continue; run until target, plateau, or budget. ## Stops - **Target** — the score reaches `` (if set). - **Plateau** — no iteration improved the best for `` consecutive rounds (every non-improving iteration counts toward patience; a keep resets it). - **Budget** — `` iterations reached.