anneal-prompt
アニール・ループを使用して、パフォーマンスの低いプロンプトを最適化します。安価なモデル(Haiku)で不安定または低品質の出力を生成するプロンプトを取得し、突然変異の多様性制約を伴う反復的な最適化を実行して、92%以上の精度を達成するプロンプトに昇格させます。ガイド付きフロー(人間参加型)または自律型(サブエージェント)として機能します。/anneal-promptで呼び出すか、「このプロンプトをアニールして」と発話することで利用できます。
description の原文を見る
Optimize an underperforming prompt using the anneal loop. Takes a prompt that produces inconsistent or low-quality outputs on a cheap model (Haiku), runs iterative optimization with mutation diversity constraints, and graduates a prompt hitting 92%+ accuracy. Works as guided flow (human-in-the-loop) or autonomous (subagent). Invoke with /anneal-prompt or say "anneal this prompt."
SKILL.md 本文
Anneal Prompt
安価なモデル(Haiku)で高級モデル(Opus)と同等の品質を実現するよう、プロンプトを最適化します。特定の定義済みタスクが対象です。
実行する前にこのリポジトリの METHODOLOGY.md をお読みください。 ここでは、オプティマイザが独自のテストセットで結果を操作しないようにする変異の多様性ルールが定義されています。
前提条件
- Claude Code (CLI、デスクトップ、またはIDE拡張機能)
- Bunランタイム (
bun --version) - このリポジトリをローカルにクローン
2つのモード
モード1: ガイド付き(人間ループ)
出力を確認して最適化をコントロールしたい場合に使用します。
モード2: 自動(サブエージェント)
最適化を任せて結果を受け取りたい場合に使用します。プロンプトのパフォーマンス低下時にメインセッションから起動します。
ステップ1: シナリオの定義または特定
新規で開始する場合:
bun setup.mjs --name [scenario-name]
オプション:
--description "このプロンプトが行うこと"--dimensions "accuracy:0.5,format:0.3,style:0.2"(ルーブリック寸法と重み)--threshold 0.92(精度目標)--budget 800(最大プロンプトトークン数)--iterations 10(デフォルトループ回数)
必要なすべてのディレクトリとテンプレートを含む scenarios/[name]/ をスキャフォールドします。
既存のシナリオを再開する場合:
scenarios/[name]/evals/loop-state.json を読んで現在の状態を確認します。
ステップ2: テストデータの準備
入力(最小12個、推奨15個)
scenarios/[name]/inputs/ に1つのテストケースあたり1つのJSONファイルを作成します:
{
"company_name": "Acme Corp",
"description": "Acme manufactures industrial widgets for automotive OEMs..."
}
入力スキーマはタスクに応じて異なります。これらはプロンプトが処理する必要のある実際のケースです。
選択基準:
- プロンプトが現在失敗しているケースを含める(それがここにいる理由です)
- 簡単なケースも含める(回帰を検出するため)
- エッジケースを含める(異常な入力、境界条件)
- ハッピーパスだけでなく、実世界の分布を表す
グラウンドトゥルース(Opusで生成、人間検証)
各入力について、scenarios/[name]/ground-truth/ に対応するファイルを作成します:
{
"id": "acme-corp",
"split": "train",
"input": { "company_name": "Acme Corp", "description": "..." },
"ground_truth": { "field1": "expected value", "field2": "expected value" }
}
グラウンドトゥルースの生成:
- 各入力をタスクプロンプトの詳細版を使ってOpusで実行する
- 人間がすべての出力をレビュー — 間違っている部分を修正する
- これが品質基準です。グラウンドトゥルースが間違っていると、オプティマイザは間違いに向けて最適化します。
スプリットの割り当て:
| スプリット | % | 目的 | スコア時期 |
|---|---|---|---|
train | 60% | ここでの失敗が変異を駆動する | すべてのイテレーション |
val | 30% | 一般化シグナル | すべてのイテレーション |
holdout | 10% | 最終テスト — ループ中に見たことがない | 卒業時のみ |
ホールドアウトには、利用した例にマッピングされない「難しい」ケースを最低1つ含める必要があります。
ベースラインプロンプト
現在のプロンプトを scenarios/[name]/prompts/v001.md に貼り付けます。これが開始点です。
ステップ3: ベースラインの実行(人間がレビュー)
すべての入力に対してv001を実行します:
bun scenarios/[name]/evals/run-eval.mjs --version v001
生の出力テーブルを表示:
| 入力 | 出力 | グラウンドトゥルース | スコア |
|---|---|---|---|
| Acme Corp | [Haikuが生成したもの] | [期待される内容] | 0.XX |
出力をレビューします。以下に注目してください:
- どの入力が失敗し、その理由
- ルーブリック寸法が正しいか
- グラウンドトゥルースを調整する必要があるか
これは自動モード開始前の最後の人間チェックポイントです。
ステップ4: Annealループの実行
ガイド付き: 1イテレーションずつ実行し、出力をレビューし、ステアリングします。
自動: 「go iterate」と言うか、ループを起動してすべての10イテレーションを実行します。
各イテレーションで起こること:
- 失敗を分析 — 頻度と重大度を構造化したパターン
- 変異タイプを選択 — フェーズ制約に従う:
| フェーズ | イテレーション | ルール |
|---|---|---|
| ブートストラップ | 1-3 | 例が許可される。基本パターンを教える |
| 一般化 | 4-7 | 例がブロックされる。 構造的推論のみ。 |
| ポーランド | 8-10 | 減法的変異が推奨される。ノイズを削除し、検証する。 |
- 変異プロンプトを生成 — 優先度の高い失敗をターゲットに
- 実行とスコア — 訓練+検証入力に対して
- 生の出力テーブルを表示 — 交渉の余地なし、すべてのイテレーション
- 停止条件をチェック — しきい値、過学習、収束、トークン予算
変異の多様性ルール(ハード制約)
- 概念あたり最大4つの例。 それ以上は照索表になります。
- 2回連続したサンプル集約的な変異は禁止。
- イテレーション4-7: 新しい例は禁止。 推論を修正し、暗記ではなく。
- イテレーション8: 減法チェック。 例の50%を削除します。スコアが0.05未満低下した場合、精緻版を保持します。
停止条件
| 条件 | トリガー | 意味 |
|---|---|---|
| しきい値に達する | val >= 0.92 | 成功 |
| 最大イテレーション | iteration >= max | 時間切れ |
| 収束プラトー | 3回連続val差分 < 0.02 | スタック |
| 過学習 | train-val差分 > しきい値 | 暗記している |
| トークン予算 | tokens > budget | プロンプトが長すぎる |
ステップ5: 卒業
threshold-reached でループが停止したとき:
- 最良版をホールドアウトセットに対してスコア付けする
- 一般化メトリクスを計算:
- Val-Train Gap (正常: -0.05 ~ +0.05)
- Holdout-Val Gap (正常: > -0.08)
- Example Density (正常: < 0.01 examples/token)
- Structural Ratio (正常: structural mutations / total > 0.40)
- holdout-val差分 < -0.10の場合: 卒業しない (過学習)
- それ以外: YAML frontmatterを付けて
library/[scenario].mdに書き込む
例: 実際の結果
ICP分類(4イテレーション、val 0.925)
タスク: B2B アウトバウンドリード生成への適合度に基づいて企業を分類します。
v001 (baseline) -> val 0.622 | 267 tokens
v002 (additive) -> val 0.640 | 295 tokens
v003 (additive) -> val 0.640 | 340 tokens
v004 (consolid.) -> val 0.925 | 388 tokens <- 卒業
重要な洞察: 統合変異(冗長なルールを簡潔なものにマージする)が最大の単一ジャンプを生み出しました。
見込み客の特定(9イテレーション、val 0.928)
タスク: 企業説明が与えられたときに、理想的な顧客ビジネスタイプと意思決定者タイトルを特定します。
v001 (baseline) -> val 0.563 | 364 tokens
v002 (additive) -> val 0.583 | 420 tokens | +reasoning step
v003 (consolidation)-> val 0.644 | 467 tokens | +negative example
v004 (targeted) -> val 0.841 | 509 tokens | +budget-holder examples <- breakthrough
v005 (additive) -> val 0.794 | 604 tokens | +train examples (val dipped)
v006 (targeted) -> val 0.806 | 668 tokens | +M&A example
v007 (targeted) -> val 0.863 | 695 tokens | +CIO/logistics fixes
v008 (targeted) -> val 0.906 | 683 tokens | +packaging refinement
v009 (consolidation)-> val 0.928 | 648 tokens | mirror rule <- 卒業
重要な洞察: 変異の60%は例ベースで、スコアを上げましたが暗記のリスクがあります。これが METHODOLOGY.md が現在一般化フェーズ(イテレーション4-7は例をブロック)を強制する理由です。最大の一般化可能な利得は、例からではなく構造的なリフレーム(v003のbuyer-not-seller、v009のmirror rule)から得られました。
ファイル参照
| ファイル | 目的 |
|---|---|
setup.mjs | 新しいシナリオをスキャフォールド |
METHODOLOGY.md | 変異の多様性ルール、一般化セーフガード |
scenarios/[name]/scenario.json | ルーブリック、しきい値、設定 |
scenarios/[name]/inputs/*.json | テストケース入力 |
scenarios/[name]/ground-truth/*.json | スプリット付き専門家参照出力 |
scenarios/[name]/prompts/vNNN.md | プロンプト版 |
scenarios/[name]/evals/loop-state.json | ループトラッキングとスコア履歴 |
scenarios/[name]/evals/vNNN-raw.json | イテレーションあたりの生モデル出力 |
scenarios/[name]/evals/vNNN.json | イテレーションあたりのスコア付き結果 |
library/[name].md | 精度メタデータ付き卒業プロンプト |
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- MitchellkellerLG
- ライセンス
- MIT
- 最終更新
- 2026/4/7
Source: https://github.com/MitchellkellerLG/auto-prompt-creator / ライセンス: MIT