curiositech/windags-skills

自動ステートフルプロンプト改善スキル

判断ポイント

プロンプト評価:
├── 単純な質問/コマンド（何、いつ、どのように）
│   └── 最適化をスキップ → 直接回答
├── 複雑なタスク（マルチステップ、推論、技術的）
│   ├── トークンバジェット < 1000
│   │   └── APE: 3〜5回の反復
│   ├── トークンバジェット 1000〜5000
│   │   └── OPRO: 5〜10回の反復
│   └── トークンバジェット > 5000
│       └── DSPyコンパイル: 10〜20回の反復
└── 再利用可能なテンプレート/システムプロンプト
    └── 履歴検索による完全最適化

最適化手法の選択:
├── 指示の書き換えが必要
│   └── APE（Automatic Prompt Engineer）を使用
├── 制約付きパラメータチューニング
│   └── OPRO（Optimization by PROmpting）を使用
├── 複数モジュールを持つ複雑なパイプライン
│   └── DSPyコンパイルパターンを使用
└── 未知/探索的領域
    └── ハイブリッド APE→OPRO→DSPyカスケード

反復制御:
├── 改善率が3ラウンド連続で1%未満 → 停止
├── 品質スコアが0.95を超える → 停止
├── 最大反復回数に達した → 停止
├── ユーザー満足が確認された → 停止
└── 続行 → 次の反復

フィードバック統合:
├── タスク成功（ユーザー確認/メトリクス良好）
│   └── 肯定的なフィードバックを記録 + 取得用に埋め込み
├── タスク失敗/品質不良
│   └── 否定的なフィードバックを記録 + 失敗モードを分析
└── 結果が不明確
    └── 記録前にユーザーに明示的なフィードバックを依頼

失敗モード

過剰最適化スパイラル

• 症状: プロンプトが500トークン以上になり、多くのネストされた制約が含まれる
• 診断: 「十分良い」で停止する代わりに、限界的な改善を追い求めている
• 修正: 80/20ルールを適用 - 反復ごとの改善率が5%を下回ったら停止

テンプレートへの固執

• 症状: タスクの明確さではなく、フォーマット/構造に反復を費やしている
• 診断: パフォーマンスとプレゼンテーションを混同している
• 修正: テンプレートの適合性ではなく、実際のタスク成功を測定する

履歴への過適合

• 症状: 最適化されたプロンプトが過去の例では機能するが、新しい入力では失敗する
• 診断: 検索から得られた狭いデータセットでトレーニングしている
• 修正: 最適化に多様な例を含め、ホールドアウトケースでテストする

能力の誤判断

• 症状: モデルがネイティブに処理できるタスクに過剰な足場を追加している
• 診断: テストせずにモデルの限界を仮定している
• 修正: 大量のプロンプトを実行する前にベースライン機能をテストする

測定の盲点

• 症状: 明確な成功メトリクスなしに複数回の反復を行っている
• 診断: 「より良い」が何を意味するかわからずに最適化している
• 修正: 最初のステップで測定可能な成功基準を定義する

実例

例1: コード最適化リクエスト

元のプロンプト: 「このコードを良くして」

def process_data(data):
    results = []
    for item in data:
        if item > 0:
            results.append(item * 2)
    return results

判断ポイントのナビゲーション:

1. 評価: 複雑なタスク（コード分析が必要）→ 最適化をトリガー
2. 手法の選択: コードレビュー + 改善 → 5回の反復でAPE
3. 取得されたコンテキスト: 履歴からの類似コード最適化プロンプト
4. 最適化されたプロンプト: 「このPython関数をパフォーマンス、可読性、Python的なパターンについて分析してください。具体的な改善点を特定してください：アルゴリズムの複雑さ、メモリ使用量、エッジケース、スタイル。説明付きのリファクタリングされたコードを提供してください。」

初心者が見逃すもの: 漠然とした「より良く」は基準を指定していない エキスパートが気づくもの: 明示的な次元（パフォーマンス、スタイル、エッジケース）が必要

結果: リスト内包表記の機会、エッジケース処理、型ヒントの明確な分析

例2: 推論タスクテンプレート

元のプロンプト: 「この決定について考えるのを手伝って」

判断ポイントのナビゲーション:

1. 評価: 再利用可能なテンプレート + 推論タスク → 完全最適化
2. 履歴検索: 決定フレームワークのプロンプトが見つかりました（類似度0.87）
3. 手法の選択: DSPyコンパイル（構造化推論パイプライン）
4. 反復戦略: 10ラウンド、決定の質を測定

最適化されたテンプレート:

決定分析フレームワーク:
1. 状況: 制約条件とともに決定を明確に記述する
2. 関係者: 影響を受ける当事者とその利害を列挙する
3. 選択肢: 3〜5つの異なる代替案を生成する
4. 基準: 成功メトリクスと重み付けを定義する
5. トレードオフ: 各選択肢を基準に対して分析する
6. 推奨: 信頼レベルとともに最適な選択肢を選択する

適用された品質ゲート: テンプレートの完全性、再利用性スコア、ユーザー満足度

例3: あいまいな技術リクエスト

元のプロンプト: 「監視を設定して」

判断ポイントのナビゲーション:

1. 評価: 指定不足 + 技術的 → 最適化をトリガー
2. 明確化戦略: 制約引き出しによるOPRO
3. ドメインコンテキスト: 監視設定パターンを取得

最適化されたプロンプト: 「監視設定を設計する際は、以下を指定してください：(1) インフラストラクチャの範囲（サーバー、コンテナ、アプリケーション）、(2) 主要メトリクス（パフォーマンス、可用性、ビジネス）、(3) アラートしきい値とエスカレーション、(4) テクノロジースタックの制約、(5) 予算/複雑さの制限。優先順位付きの実装ロードマップを提供してください。」

前後のトレードオフ:

• 前: 終わりのない往復の明確化
• 後: 単一のやり取りで構造化された要件収集
• コスト: 初期プロンプトが長くなる
• 利点: 1ラウンドで完全な仕様を取得

品質ゲート

最適化実行前のチェックリスト:

• タスク複雑性スコア > 3（マルチステップ/推論が必要）
• 明確な成功基準が定義されているか、導出可能
• トークンバジェットを見積もり、手法を選択済み
• 取得用にドメインコンテキストを特定済み
• 複雑さに基づいて反復制限を設定済み

最適化後の検証:

• 最適化されたプロンプトが具体的かつ実行可能
• 成功メトリクスが測定可能
• 制約の一貫性が検証済み（矛盾なし）
• トークン効率: 改善が長さの追加を正当化する
• 履歴コンテキストが適切に統合されている
• 大きな変更についてユーザーの確認を取得済み

品質スコアリングルーブリック（0〜100）:

• 明確さ: 初心者ユーザーが要件を理解できるか？(25点)
• 具体性: 抽象的な指示ではなく具体的な指示か？(25点)
• 完全性: エッジケースと制約をカバーしているか？(25点)
• 効率性: 肥大化せずに目標を達成しているか？(25点)

対象外境界

このスキルを以下の目的で使用しないでください:

• 単純な事実に関する質問 → 知識で直接回答
• 推論を伴わないファイル操作 → ファイル管理スキルを使用
• 直接コマンドの実行 → すぐに実行
• 会話応答 → 自然に応答
• 既に最適化されたプロンプト → 履歴を確認し、再最適化を避ける
• ユーザーが明示的に「最適化しないで」と言った場合 → ユーザーの好みを尊重

代わりに委任する場合:

• 数学的問題の場合 → 計算に特化したスキルを使用
• クリエイティブライティングの場合 → クリエイティブライティングスキルを使用（テンプレート作成以外）
• データ分析の場合 → データ分析スキルを使用（複雑な推論が必要な場合を除く）
• デバッグの場合 → デバッグスキルを使用（体系的な改善が必要な場合を除く）

判断を要するグレーゾーン:

• 中程度の複雑さのタスク（スコア2〜4） → 最初にベースラインパフォーマンスをテスト
• ドメイン専門知識のリクエスト → 再利用可能なテンプレートの可能性がある場合のみ最適化
• フォローアップの質問 → スコープが大幅に拡大する場合のみ最適化