メニュー
agent 向けの skill、slash command、AGENTS.md/CLAUDE.md 節、タスクプロンプト、コード生成プロンプトを実証的に改善する。新規作成または大幅改訂した指示の明瞭性、trigger と本文の整合、実行時の不明瞭点、裁量補完、成功率を検証したいときに使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
コードベース全体、特定分野、ブランチ差分の改善候補を監査し、根拠付きで優先順位を付け、改善バックログとして残すときに使う。ユーザーが「$improve」「/improve」「コードベースを監査して」「改善候補を優先順位付きで出して」「改善バックログを作って」「このブランチで増えた問題を調べて」「改善バックログを再照合して」「リポジトリの次の方向性を考えて」と依頼した場合に使う。既知のバグ修正、直接の実装、通常のコードレビュー、設計済み作業の計画書作成、実装結果の受け入れ検証には使わない。
設計済みの作業を別エージェントへ渡すため、実装計画書や handoff プロンプトの作成を求められたときに使う。未確定要件の壁打ちや自分で実装する依頼では使わない。
他エージェントへのレビュー依頼、実装結果の受け入れ検証、レビュー結果の妥当性確認を求められたときに使う。PRレビューコメント対応や通常のセルフレビューでは使わない。
別のtmux paneで動いているAIエージェント（Claude Code / Codex / opencode等）へ指示やレビュー依頼を送信する、応答の完了を待って回収する、他paneのエージェントの出力や作業ログを読む、レビュー往復ループを回すときに使う。「%Nのpaneに送って」「隣のpaneのCodexにレビューを依頼して」「あのpaneが終わったら続きをやって」「右のpaneの作業を読んでまとめて」のような依頼で発動する。送る文面の作成自体（レビュー依頼文・handoffプロンプト）では使わず、agent-review-request / agent-handoff-plan に任せる。tmuxを介さないsubagent起動や並列化にも使わない。
Claude Code の /compact 前に、セッション状態の checkpoint を手動で保存するときに使う。「/compact-state」「compact 前に状態を保存して」「checkpoint を保存して」と依頼されたときに発動する。圧縮後の復旧作業、通常の進捗報告、plan 作成では使わない。
調査・監査・技術選定比較・性能検証・実装結果について、ユーザーが「結果をHTMLで読みやすく整理して」「HTMLの説明資料・レポートとして残して」のように、後から読み返せる静的HTML成果物を求めたときに使う。説明を補助する表、限定的な図解・定量グラフ・折りたたみ・定型指摘フィルタにも対応する。内容の調査・整理を伴わないHTML断片への変換、UI案や配色の比較モック、スライド、単体の探索的グラフ、任意JavaScriptを要する対話ツールには使わない。
| name | empirical-prompt-tuning |
| description | agent 向けの skill、slash command、AGENTS.md/CLAUDE.md 節、タスクプロンプト、コード生成プロンプトを実証的に改善する。新規作成または大幅改訂した指示の明瞭性、trigger と本文の整合、実行時の不明瞭点、裁量補完、成功率を検証したいときに使う。 |
| metadata | {"short-description":"agent 向け指示を実証評価して改善する"} |
agent 向け指示は、書いた本人が明瞭だと思っていても、別の実行者が読むと詰まることがある。この skill は、指示を静的に点検し、必要に応じて新規 agent に実行させ、実行者の自己申告と固定チェックリストの両面から改善点を出すための手順である。
元の考え方は Claude Code 向けの empirical prompt tuning だが、この版では Codex の制約に合わせる。特に、Codex では subagent の利用はユーザーが明示した場合だけに限る。
最初に、今回どのモードで進めるかを判定する。
迷った場合は構造審査モードを選ぶ。自己再読だけを empirical 評価として扱ってはいけない。
この skill は次のようなテキスト指示に使う。
SKILL.mdAGENTS.md / CLAUDE.md / 運用ルールの一節使わない場面:
dispatch は不要。対象文書を読み、次を確認する。
description が謳う trigger、用途、成果物乖離がある場合、Iteration 1 に進む前に description か body を合わせる。ここを飛ばすと、実行者が description から勝手に意図を補い、skill 本体が弱いのに成功したように見える。
対象プロンプトを固定し、評価に使う材料を先に決める。後から都合よく動かさない。
[critical] 項目: 各シナリオに最低 1 件。これが落ちたら成功扱いにしない。チェックリストは、実行結果から客観的に判定できる粒度で書く。曖昧な「よい感じ」「適切に」は避ける。
この手順は、モード選択で empirical 評価モードと判定した場合だけ行う。
Codex では spawn_agent を使う。並列実行する場合でも、各 agent のタスクは独立したシナリオに分ける。
評価 agent へ渡すプロンプトは次の形にする。
あなたは <対象プロンプト名> を白紙で読む実行者です。
## 対象プロンプト
<対象プロンプト本文、または読むべき絶対パス>
## シナリオ
<現実に起こりうる状況を 1 段落で説明>
## 要件チェックリスト
1. [critical] <最低ラインに含む項目>
2. <通常項目>
3. <通常項目>
## タスク
1. 対象プロンプトに従ってシナリオを実行してください。
2. 原則としてファイルは編集しないでください。編集が必要だと判断した場合は、その必要性をレポートに書いてください。
3. 最後に次のレポート構造で返答してください。
## レポート構造
- 成果物: <生成物または実行結果サマリ>
- 要件達成: 各項目について ○ / × / 部分的（理由付き）
- 不明瞭点: 対象プロンプトで詰まった箇所、解釈に迷った文言
- 裁量補完: 指示で決まっておらず自分の判断で埋めた箇所
- 再試行: 同じ判断をやり直した回数と理由
- 探索量: 読んだ主要ファイル、使った主要ツール、迷った分岐の概算
戻ってきた結果を次の軸で評価する。
| 軸 | 判定方法 | 重み |
|---|---|---|
| 成功/失敗 | [critical] がすべて ○ なら成功。それ以外は失敗 | 高 |
| 精度 | ○ = 1、部分的 = 0.5、× = 0 として達成率を算出 | 高 |
| 不明瞭点 | 実行者が詰まった文言や不足情報 | 高 |
| 裁量補完 | 実行者が独自判断で埋めた仕様 | 高 |
| 再試行 | 同じ判断をやり直した回数 | 中 |
| 探索量 | 読んだファイル、使ったツール、分岐の概算 | 低 |
| 所要時間 | 親側で観測できる範囲の概算 | 低 |
Claude Code 版の tool_uses / duration_ms は Codex では安定して取得できないことがある。取れないメトリクスを無理に主指標にせず、質的フィードバックと固定チェックリストを主にする。
empirical 評価モードでは、次を目安に停止する。
重要度が高い skill では、連続 3 iteration まで見る。
ユーザーへは次の形で簡潔に報告する。
## Iteration N
### 変更点
- <前回からの最小差分>
### 実行結果
| シナリオ | 成功 | 精度 | retries | 探索量 |
|---|---|---:|---:|---|
| A | ○ | 100% | 0 | 低 |
| B | × | 60% | 2 | 高 |
### 新規の不明瞭点
- <シナリオ B>: [critical] 項目 N が ×。<理由>
### 裁量補完
- <シナリオ A>: <実行者が補った判断>
### 次の修正
- <次に入れる 1 テーマの修正>
構造審査モードでは、実行結果表は出さず、次だけ返す。
[critical] を後から付け替える。description の trigger を強くしすぎて、body が対応していない用途まで発火させる。spawn_agent を使うかどうかは、モード選択の条件を満たす場合のみとする。