prompt-optimizer

プロンプトオプティマイザー

評価を使ってプロンプトを最適化します。すべての指示、例、外部コンテキストへの参照が因果関係を保つようにしてください。

必要なものだけを読み込む

必要なもの	読むもの
新しいプロンプト	references/core-patterns.md、references/model-family-notes.md、references/transformed-examples.md
既存のプロンプト	references/meta-optimization-loop.md、references/core-patterns.md、references/model-family-notes.md
モデルファミリーへの移植	references/model-family-notes.md、references/core-patterns.md
繰り返し発生する失敗	references/meta-optimization-loop.md、references/core-patterns.md
弱い、または曖昧な草案	references/transformed-examples.md
出典	SOURCES.md

ステップ 1：契約を記録する

編集前に、以下を記録します。

• タスクの種類：新規、改善、移植、またはデバッグ
• 対象モデルのファミリーとスナップショット（判明している場合）
• プロンプトの適用箇所：system、developer、user、ツールの説明、例、スキーマ
• 各レイヤーの所有者：プラットフォーム、デプロイヤー／ペルソナ、取得したコンテキスト、ユーザーのペイロード
• 目的と対象外
• 利用可能な入力、ツール、外部ファイル
• 必須の出力形式
• 成功基準と失敗ケース
• 厳格な制約：レイテンシ、詳細さ、安全性、予算、ツールの使用、スタイル

成功基準や例がない場合は、まず小規模な評価セットを作成します。 ボトルネックがモデルの選択、検索、ツールのスキーマ、または評価の不足にある場合は、書き換える前にその旨を伝えます。

ステップ 2：外部コンテキストを一覧にする

リポジトリやエージェントのプロンプトでは、安定したコンテキストを正確なパスで列挙します。

コンテキストの種類	例
エージェントのルール	AGENTS.md、CLAUDE.md
仕様	specs/*.md、docs/api.md
ポリシー	SECURITY.md、docs/releasing.md
例	examples/、tests/fixtures/

ルール：

• 安定したファイルはコピーせず、リポジトリ相対パスで参照します。
• プロンプトや評価ケースに必要な抜粋だけを貼り付けます。
• ファイルが loaded、referenced、out of scope のどれに該当するかを明記します。
• 「ドキュメントを読む」のような曖昧なコンテキスト参照は避けます。

ステップ 3：モデル戦略を選ぶ

references/model-family-notes.md を読みます。

• ファミリーが判明している場合：そのファミリーに合わせて最適化します。
• ファミリーが不明な場合：移植可能な基本形と、短いアダプターのメモを作成します。
• スナップショットが変わった場合：評価を再実行します。
• ファミリー間に差異がある場合：失敗しているレイヤーだけを特化させます。

ステップ 4：プロンプトを組み立てる

references/core-patterns.md を読みます。

• 安定したポリシーは system または developer に配置します。
• タスク固有の事実、取得したコンテキスト、変数はユーザー向けのセクションに配置します。
• 各動作ルールには、所有者を 1 つだけ割り当てます。
• コンテンツの種類を分ける場合に限り、見出しやタグを使います。
• ツールのポリシーはプロンプトのテキストに記述し、スキーマはプロバイダー標準のツールに保持します。
• 動作に影響しない限り、ペルソナは簡潔にします。
• 制約を保てる範囲で、最も短い表現を使います。
• 埋め草、繰り返しの注意、不要になった例、評価に影響しない根拠の説明は削除します。

ステップ 5：最適化する

改善には references/meta-optimization-loop.md を読みます。

1. 現在のプロンプトを同じ評価スライスでベースライン評価します。
2. 失敗を根本原因ごとに分類します。
3. 具体的な編集上の問題点を記述します。
4. 候補を 2〜4 個作成します。
   • 最小差分での修正
   • 構造を優先した書き換え
   • 例を優先する案、またはツールルールを変えた案
   • 必要に応じてプロバイダー用アダプター
5. 同じケースで候補を比較します。
6. 簡潔な最適化ログを残します。
7. 保留ケースで最良案を検証します。
8. 改善の停滞、振動、過学習、過剰なコスト、またはプロンプト以外のボトルネックが生じたら終了します。

ステップ 6：一式を返す

以下を返します。

1. Target
2. Success Criteria
3. External Context
4. Optimized Prompt
5. Adapter Notes
6. Eval Set
7. Optimization Log
8. Residual Risks

既存のプロンプトの場合は、主な動作上の変更を簡潔な差分形式のメモで含めます。

失敗パターン

• 評価対象を定義する前に編集する
• ポリシー、例、未加工のコンテキストを境界なしに混在させる
• レイヤー間でルールを重複させる
• 長期的に適用されるポリシーをユーザーペイロードに入れる
• 思考の連鎖を求める
• 矛盾する古い指示を残す
• 1つか2つの例に過剰適合させる
• 評価の改善につながらなくなった例を残す
• ツールの説明やスキーマが不十分なのに、プロンプトのテキストだけでツール使用時の失敗を修正する
• 曖昧さを減らさないマークアップを追加する
• 振る舞いのルールの代わりにペルソナを使う