llm-application-dev-prompt-optimize
高度なエンジニアリング手法による LLM プロンプト最適化
基本的な指示を本番環境対応のプロンプトに変換し、精度を 40% 向上、コストを 50-80% 削減します。このスキルは、連鎖的思考推論、構成的 AI パターン、Claude、GPT、Gemini 向けのモデル固有最適化に関する専門的なガイダンスを提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「llm-application-dev-prompt-optimize」を使用しています。 このプロンプトを最適化：「返金に関する顧客の質問に答える」
期待される結果:
ロール定義、診断フレームワーク、解決策提供構造、検証ステップ、制約、JSON 出力形式を備えた最適化済みプロンプト。品質保証のための連鎖的思考推論セクションと自己レビューチェックリストを含む。
「llm-application-dev-prompt-optimize」を使用しています。 データ分析用プロンプトを改善：「売上データを分析する」
期待される結果:
5 つのフェーズを備えた包括的分析フレームワーク：データ検証、統計的有意性検定付きトレンド分析、多次元セグメント分析、信頼度スコアリング付きインサイトテンプレート、YAML 形式の優先順位付き推奨事項。
セキュリティ監査
安全Static analysis detected 62 potential security issues in code examples within documentation files. All findings are false positives - the detected patterns (Ruby backticks, MD5 references, reconnaissance commands) appear exclusively within markdown code blocks that demonstrate prompt engineering techniques. The skill contains no executable code, performs no file operations, network requests, or command execution. It is a documentation-only skill providing guidance on prompt optimization best practices.
品質スコア
作れるもの
カスタマーサポートプロンプトの最適化
基本的なカスタマーサポートプロンプトを、診断推論フレームワーク、エスカレーションパス、品質制約を備えた構造化された共感的応答システムに変換し、一貫性のあるプロフェッショナルなサポート対応を実現します。
データ分析プロンプトの強化
単純なデータ分析リクエストを、フェーズベースの検証、統計的有意性検定、セグメント分析、構造化された YAML 形式のエグゼクティブレポートを備えた包括的な分析フレームワークにアップグレードします。
コード生成の安全性改善
セキュリティファーストの設計思考、入力検証要件、SOLID 原則、自己レビューチェックリストをコード生成プロンプトに追加し、インジェクション脆弱性を防止して本番環境対応のコードを確保します。
これらのプロンプトを試す
この問題を段階的に分析してください：
1. 核心的な問題を特定する
2. 小さな構成要素に分解する
3. 各構成要素を注意深く推論する
4. 調査結果を統合する
5. 信頼度とともに最終回答を提供する
入力：{your_input}例 1:
入力：{simple_case}
出力：{correct_output}
例 2:
入力：{edge_case}
出力：{correct_output}
例 3:
入力：{error_case}
誤り：{incorrect_output}
正解：{correct_output}
これを次のものに適用してください：{actual_input}{task_instructions}
次の原則に照らして回答をレビューしてください：
1. 正確性：すべての主張を検証し、不確実性をフラグ付け
2. 安全性：有害性、バイアス、倫理的問題を確認
3. 品質：明確性、一貫性、完全性を確保
初期回答：[生成]
自己レビュー：[原則に照らして評価]
最終回答：[レビューに基づいて洗練]<context>
{background_information}
</context>
<task>
{clear_objective_with_constraints}
</task>
<thinking>
1. 要件の理解...
2. 構成要素の特定...
3. アプローチの計画...
</thinking>
<output_format>
{xml_structured_response_specification}
</output_format>ベストプラクティス
- プロンプトでは常に明確なロール、コンテキスト、タスク、出力形式を定義する
- 複雑な多段階問題では精度向上のため連鎖的思考推論を使用する
- 数ショット学習では典型的、エッジケース、エラーケースをカバーする 3-5 個の多様な例を含める
- 安全性重視のアプリケーションでは憲法原則付き自己批判ループを実装する
回避
- フレームワーク、出力形式、成功基準を指定せずに「これを分析して」といった曖昧な指示は避ける
- エッジケースをカバーしない単一の例は使用しない - これは脆いプロンプト動作につながる
- 敵対的入力、範囲外クエリ、エッジケースに対するテストなしにプロンプトを本番投入しない
- モデル非依存のプロンプトは避ける - 特定の LLM 向けに構造を最適化する（Claude は XML タグを好む、GPT は ## ヘッダーを好む）