mcpField
P
prompt-engineer

prompt-engineer

github.com/404kidwizエージェントワークフロー96 回インストール
リポジトリ

prompt-engineer について

prompt-engineer は、LLM アプリケーションのプロンプト設計、改善、評価を支援するスキルです。Chain-of-Thought、ReAct、Few-shot 学習に加え、本番環境でのプロンプト管理を扱います。

主な機能

  1. 01プロンプト設計とテンプレート
  2. 02Chain-of-Thought と ReAct の手法
  3. 03Few-shot 例の作成
  4. 04プロンプト品質の評価
  5. 05本番環境のプロンプト管理

活用シーン

  1. 01LLM アプリケーション用プロンプトの作成
  2. 02失敗パターンに基づくプロンプト改善
  3. 03エッジケースを使ったプロンプトテスト
  4. 04プロンプト性能の継続的な追跡

インストール

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

$npx skills add https://github.com/404kidwiz/claude-supercode-skills --skill prompt-engineer

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

詳細

プロンプトエンジニア

目的

大規模言語モデル向けのプロンプトの設計、最適化、評価に関する専門知識を提供します。Chain-of-Thought、ReAct、少数ショット学習などのプロンプト技法に加え、本番環境でのプロンプト管理と評価を専門とします。

使用する場面

  • LLM アプリケーション向けのプロンプトを設計するとき
  • プロンプトの性能を最適化するとき
  • Chain-of-Thought 推論を実装するとき
  • 少数ショットの例を作成するとき
  • プロンプトテンプレートを構築するとき
  • プロンプトの有効性を評価するとき
  • 本番環境でプロンプトを管理するとき
  • プロンプトを通じて幻覚を減らすとき

クイックスタート

このスキルを呼び出す場面：

  • LLM アプリケーション向けのプロンプトを作成するとき
  • 既存のプロンプトを最適化するとき
  • 高度なプロンプト技法を実装するとき
  • プロンプト管理システムを構築するとき
  • プロンプトの品質を評価するとき

次の場合は呼び出さないでください：

  • LLM システムアーキテクチャ → /llm-architect を使用
  • RAG の実装 → /ai-engineer を使用
  • NLP モデルのトレーニング → /nlp-engineer を使用
  • エージェントのパフォーマンス監視 → /performance-monitor を使用

判断フレームワーク

Prompting Technique?
├── Reasoning Tasks
│   ├── Step-by-step → Chain-of-Thought
│   └── Tool use → ReAct
├── Classification/Extraction
│   ├── Clear categories → Zero-shot + examples
│   └── Complex → Few-shot with edge cases
├── Generation
│   └── Structured output → JSON mode + schema
└── Consistency
    └── System prompt + temperature tuning

主なワークフロー

1. プロンプト設計
  1. タスクを明確に定義する
  2. プロンプト技法を選択する
  3. コンテキストを含むシステムプロンプトを作成する
  4. 少数ショットの場合は例を追加する
  5. 出力形式を指定する
  6. 多様な入力でテストする
2. Chain-of-Thought の実装
  1. 推論要件を特定する
  2. 「順を追って考えてみましょう」または同等の表現を追加する
  3. 推論の例を提示する
  4. 期待する推論手順を構成する
  5. 推論の品質をテストする
  6. 手順のガイダンスを繰り返し改善する
3. プロンプトの最適化
  1. ベースライン指標を設定する
  2. 失敗のパターンを特定する
  3. 指示を調整して明確にする
  4. 例を追加または変更する
  5. 出力制約を調整する
  6. 改善を測定する

ベストプラクティス

  • 指示を具体的かつ明確にする
  • 構造化された出力形式（JSON、XML）を使用する
  • 複雑なタスクには例を含める
  • エッジケースや敵対的な入力でテストする
  • プロンプトをバージョン管理する
  • プロンプトのパフォーマンスを測定し、追跡する

アンチパターン

アンチパターン問題適切なアプローチ
曖昧な指示出力に一貫性がない具体的かつ明確にする
例がない複雑なタスクで性能が低い少数ショットの例を追加する
構造化されていない出力解析が難しい形式を明確に指定する
テストがないどのような失敗が起こるか不明多様な入力でテストする
コード内のプロンプト反復的な改善が難しいプロンプト管理を分離する

コメント

Markdown 対応