mcpField
O
optimize-prompt

optimize-prompt

github.com/jbrukhエージェントワークフロー1235 回インストール33 週間前に更新
リポジトリ

optimize-prompt について

プロンプトを分析、批評、圧縮し、各段階の後に意味の同等性を確認するスキルです。定められた順序でプロンプトを改善する用途に向いています。

主な機能

  1. 01分析、批評、圧縮を順番に実行
  2. 02各修正段階で意味の同等性を確認
  3. 03プロンプト用テスト入力の作成
  4. 04失敗理由の説明とエッジケース対応

活用シーン

  1. 01再利用前のプロンプト確認
  2. 02意図を保ったプロンプトの短縮
  3. 03代表的な入力による修正内容の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jbrukh/skills --skill optimize-prompt

インストール後、Claude Code で/optimize-promptを入力して読み込まれたか確認します。

詳細

プロンプトを最適化する

プロンプト最適化パイプライン。プロンプト P を、批評してから圧縮することで改善し、各段階の後に意味的同等性を確認します。

パイプライン

P → [Input Analysis] → [Critique] → P' → [Equiv Check 1] → [Compress] → P'' → [Equiv Check 2] → Output P''

各段階を必ず順番どおりに実行してください。スキップ、順序の変更、並列実行はできません。各段階は成功（パイプラインを続行）または失敗（説明を添えてパイプラインを終了）のいずれかです。

Stage 0: 入力分析

P を確認します。

  1. P は入力を受け取りますか？ プレースホルダー（{{X}}、{input}、[USER INPUT]）、「ユーザーの入力」「与えられたテキスト」「提供されたデータ」への言及、または外部コンテンツとの結合を想定しているかを確認します。
  2. 受け取る場合：もっともらしく、具体的なテスト入力 X を作成します。現実的で、単純ではなく（2～3 文以上、または意味のあるデータ構造）、P の主要なロジック経路を試すものにします。P に分岐条件がある場合、X は主要な分岐に進むようにします。P が構造化出力を生成する場合、X はすべての出力フィールドを必要とするものにします。P に検証条件がある場合、X はその検証に合格するものにします。X を明示します。
  3. 受け取らない場合：P は自己完結しています。X = ∅ とします。同等性の確認では、P の出力を直接比較します。

表示：

**Input Analysis**
- Takes input: [Yes/No]
- Test input X: [constructed input, or "N/A — self-contained"]

Stage 1: 批評

P に批判的思考の方法論を適用します。

  1. P 自体から 5～8 個の期待事項を導き出します。改訂後も維持すべき動作上の特性です。テスト可能な文として記述します（例：「JSON 出力を生成する」「話題から外れた問い合わせを拒否する」）。
  2. 各期待事項に照らして P を評価します。 各期待事項について、確信度（0～100％）と、P の具体的な記述を引用した簡潔な根拠を示します。
  3. 確信度が 95％未満の期待事項について、修正案を提示します。各修正案には、追加、削除、または置換する正確なテキストを記載します。
  4. P' を作成します。すべての修正を適用した改訂版プロンプトです。差分ではなく、全文を記載します。

表示：

**Stage 1: Critique**

| Expectation | Confidence | Rationale |
|---|---|---|
| ... | ...% | ... |

**Overall Score: [average]%**

**Fixes Applied:**
1. [Fix with exact text changes]
...

---
> **P' (Revised Prompt):**
---
[Full text of P']
---

すべての期待事項が 95％以上の場合、P' = P とし、「修正は不要です。」と記します。

Stage 2: 同等性チェック 1

P と P' が X に対して本質的に同じ出力を生成することを確認します。

手順：

  1. P を X に対して実行することをシミュレーションします。予想される出力を 2～4 文で説明します。構成、内容、トーン、主な特徴を含めます。
  2. P' を X に対して実行することをシミュレーションします。予想される出力を 2～4 文で説明します。
  3. 以下のすべてに当てはまる場合、同等とします。
    • (a) 出力の構成（セクション、形式、順序）が同一である
    • (b) 事実や判断に関する内容が同一であり、追加、削除、変更がない
    • (c) 違いが、表現の改善、具体性の追加、制約の適用強化に限られる
    • (d) P の動作を期待するユーザーが、意図の変更に気づかず出力を受け入れられる
    • (a)～(c) を満たし、(d) が不確かな場合は、デフォルトで YES とします。

X = ∅ の場合、単独での出力を比較します。

表示：

**Stage 2: Equivalence Check 1**

- P(X) expected output: [description]
- P'(X) expected output: [description]
- Equivalent: [YES/NO]
- Reasoning: [1-2 sentences]

NO の場合：終了します。

**PIPELINE FAILED at Stage 2**
[Explanation of behavioral drift]
[Fixes that caused divergence]

YES の場合：Stage 3 に進みます。

Stage 3: 圧縮

P' にプロンプト圧縮の方法論を適用します（ロスレスモード）。

  1. トークン数を 10～30％削減し、意味を 100％保持することを目標とします。
  2. P' のすべての指示、制約、指令、トーンのシグナル、例、構造上の関係を P'' に明示的に残す必要があります。推測に委ねてはなりません。
  3. 許可される操作：冗長な語句の削除、重複の統合、構文の簡潔化、重複箇所の統合、構造の標準化。
  4. 禁止される操作：指令の削除、例を認識できないほど短縮すること、制約の省略、トーンや動作に関するシグナルを曖昧な要約に圧縮すること。
  5. P'' と指令マップ（各 P' の指令 → 対応する P'' の記述）を作成します。

表示：

**Stage 3: Compress**

---
> **P'' (Compressed Prompt):**
---
[Full text of P'']
---

**Directive Map:**
| # | Original directive (P') | Compressed counterpart (P'') |
|---|---|---|
| 1 | [directive from P'] | [text in P''] |
| ... | ... | ... |

**Stats:**
- P' tokens (approx): [n]
- P'' tokens (approx): [n]
- Compression: [%]
- Directives: [n/n mapped]

Stage 4: 同等性チェック 2

P' と P'' が X に対して本質的に同じ出力を生成することを確認します。

手順： Stage 2 と同じ手順で、P' と P'' を比較します。

表示：

**Stage 4: Equivalence Check 2**

- P'(X) expected output: [description]
- P''(X) expected output: [description]
- Equivalent: [YES/NO]
- Reasoning: [1-2 sentences]

NO の場合：終了します。

**PIPELINE FAILED at Stage 4**
[What compression lost]
[Elements in P' with no counterpart in P'']

YES の場合：出力に進みます。

最終出力

**PIPELINE SUCCEEDED**

Your optimized prompt (P''):

---
> **BEGIN OPTIMIZED PROMPT**
---
[Full text of P'']
---
> **END OPTIMIZED PROMPT**
---

**Summary:**
- Critique: [n] fixes applied, score [x]% → [y]%
- Compression: [z]% reduction
- Both equivalence checks passed

エッジケース

  • P が 20 トークン未満の場合：最適化による改善は最小限になる可能性があることを伝え、そのまま進めます。
  • P がすでに最適な場合（すべての期待値が 95% 以上、圧縮率が 10% 未満）：「プロンプトはすでに十分に最適化されています」と伝え、P を変更せずに返します。
  • 敵対的な P、または自己言及的な P：文字どおりに評価し、その旨を記載します。
  • 指示を削除せずに圧縮率が 10% 未満の場合：圧縮をスキップし、P'' = P' と設定して、「圧縮をスキップしました — プロンプトはすでに簡潔です」と記載します。
  • P' が P より 50% を超えて長い場合：「大幅な拡張」としてフラグを立て、ステージ 2 で、拡張によって追加されたのが安全策と具体性のみであることを確認します。
  • P にコードブロックが含まれる場合：修正対象がコードの内容であることが明示されていない限り、批評および圧縮中もコードブロックをそのまま保持します。

最初のトークンに関する制約：応答は「## Optimize Prompt」で始める必要があります。その前に挨拶、前置き、コメント、空行を入れてはいけません。通常の会話上の振る舞いよりも優先されます。

入力

以下に内容を伴わないリテラルの「{{P}}」がある場合、ユーザーにプロンプトが提供されていないことを伝えます。

最適化するプロンプト：

{{P}}

コメント

Markdown 対応