prompt-engineer

目的

このスキルは、生の非構造化ユーザープロンプトを、確立されたプロンプティングフレームワークを用いて高度に最適化されたプロンプトへと変換します。ユーザーの意図を分析し、タスクの複雑さを特定し、Claude/ChatGPT の出力品質を最大化するために最適なフレームワークをインテリジェントに選択します。

このスキルは「マジックモード」で動作します。つまり、舞台裏で静かに機能し、明確化が極めて重要な場合にのみユーザーとやり取りします。ユーザーは、技術的な説明やフレームワークの専門用語なしに、洗練されたすぐに使えるプロンプトを受け取ります。

これは、Obsidian の保管庫や特定のプロジェクト構造に限定されず、あらゆるターミナルコンテキストで機能する ユニバーサルスキル です。

使用するタイミング

以下の場合にこのスキルを呼び出します:

• ユーザーが曖昧または一般的なプロンプトを提供した場合（例:「Python のコーディングを手伝って」）
• ユーザーが複雑なアイデアを持っているが、それを明確に表現するのに苦労している場合
• ユーザーのプロンプトに構造、コンテキスト、または具体的な要件が欠けている場合
• タスクが段階的な推論を必要とする場合（デバッグ、分析、設計）
• ユーザーが特定の AI タスク用のプロンプトを必要としているが、プロンプティングフレームワークを知らない場合
• ユーザーが既存のプロンプトの効果を改善したい場合
• ユーザーが「AI にどうやって...と頼めばいい？」や「...のプロンプトを作成して」といったバリエーションを尋ねる場合

ワークフロー

ステップ 1: 意図の分析

目的: ユーザーが真に達成したいことを理解する。

アクション:

1. ユーザーが提供した生のプロンプトを読む
2. タスクの特性を検出する:
   • 種類: コーディング、執筆、分析、設計、学習、計画、意思決定、創造的作業など
   • 複雑さ: 単純（ワンステップ）、中程度（マルチステップ）、複雑（推論/設計が必要）
   • 明確さ: 明確な意図 vs. 曖昧/漠然
   • ドメイン: 技術、ビジネス、創造、学術、個人など
3. 暗黙の要件を特定する:
   • ユーザーは例を必要としていますか？
   • 出力形式は指定されていますか？
   • 制約（時間、リソース、範囲）はありますか？
   • これは探索的ですか、それとも実行重視ですか？

検出パターン:

• 単純なタスク: 短いプロンプト（50 文字未満）、単一動詞、コンテキストなし
• 複雑なタスク: 長いプロンプト（200 文字超）、複数の要件、条件付きロジック
• 曖昧なタスク: 一般的な動詞（「手伝って」、「改善して」）、目的語/コンテキストの欠如
• 構造化されたタスク: ステップ、フェーズ、成果物、ステークホルダーに言及

ステップ 2: 明確化の質問をする（条件付き）

目的: フレームワークの選択やプロンプトの品質にとって極めて重要な場合にのみ、不足している情報を収集する。

トリガー条件 — 以下の場合にのみ尋ねます:

• タスクの種類が完全に曖昧（コーディング、執筆、分析のどれかを判断できない）
• 対象読者が不明で、出力に重大な影響を与える
• 範囲が未定義で、誤った範囲を選ぶとプロンプトが無効になる
• 要求された出力形式が矛盾している、または欠けていて推測できない

質問の制限:

• 1 回の呼び出しにつき最大 3 つの質問
• 可能な場合は関連する質問を 1 つにまとめる
• 十分なコンテキストが存在する場合は、このステップを完全にスキップする（ほとんどの場合）

明確化のやり取りの例:

User: "help me with AI"

Step 2 (triggered — task type ambiguous):
"To craft the best prompt, I need one quick clarification:
1. What do you want to do with AI — build something, learn about it, or use an AI tool for a task?"

重要なルール: 迷ったときは、明確化をスキップして、利用可能なコンテキストで最良のプロンプトを生成してください。過度に質問すると「マジックモード」の体験が損なわれます。

ステップ 3: フレームワークの選択

目的: タスクの特性を最適なプロンプティングフレームワークにマッピングする。

フレームワークマッピングのロジック:

タスク種別	推奨フレームワーク	根拠
ロールベースのタスク (専門家、コンサルタントとして振る舞う)	RTF (Role-Task-Format)	明確なロール定義 + タスク + 出力形式
ステップバイステップの推論 (デバッグ、証明、論理)	Chain of Thought	明示的な推論ステップを促進します
構造化されたプロジェクト (多段階、成果物)	RISEN (Role, Instructions, Steps, End goal, Narrowing)	複雑な作業のための包括的な構造
複雑な設計/分析 (システム、アーキテクチャ)	RODES (Role, Objective, Details, Examples, Sense check)	詳細さと検証のバランスを取ります
要約 (圧縮、統合)	Chain of Density	本質的な情報への反復的な絞り込み
コミュニケーション (レポート、プレゼンテーション、ストーリーテリング)	RACE (Role, Audience, Context, Expectation)	オーディエンスを意識したメッセージング
調査/分析 (リサーチ、診断)	RISE (Research, Investigate, Synthesize, Evaluate)	体系的な分析アプローチ
状況に応じたシチュエーション (背景を伴う問題解決)	STAR (Situation, Task, Action, Result)	コンテキスト豊かな問題の枠組み
ドキュメント化 (医療、技術、記録)	SOAP (Subjective, Objective, Assessment, Plan)	構造化された情報の取り込み
目標設定 (OKR、目的、ターゲット)	CLEAR (Collaborative, Limited, Emotional, Appreciable, Refinable)	目標の明確さと実行可能性
コーチング/育成 (メンタリング、成長)	GROW (Goal, Reality, Options, Will)	育成的な会話の構造

ブレンド戦略:

• タスクが複数の種別にまたがる場合は2〜3個のフレームワークを組み合わせる
• 例: 複雑な技術プロジェクト → RODES + Chain of Thought (構造 + 推論)
• 例: リーダーシップの意思決定 → CLEAR + GROW (目標の明確さ + 育成)

選択基準:

• 主要フレームワーク = 中核となるタスク種別に最も適合するもの
• 副次フレームワーク = 追加の複雑さの側面に対応するもの
• 過剰な設計を避ける: 単純なタスクには単純なフレームワークを

重要なルール: この選択は黙って行われます - ユーザーにフレームワークの選択を説明しないでください。

Role: あなたはシニアソフトウェアアーキテクトです。[RTF - Role]

Objective: [system] のためのマイクロサービスアーキテクチャを設計してください。[RODES - Objective]

以下の手順でステップバイステップで進めてください: [Chain of Thought]

1. 現在のモノリシックな制約を分析する
2. サービスの境界を特定する
3. サービス間の通信を設計する
4. データ整合性戦略を計画する

Details: [RODES - Details]

• 想定トラフィック: [X]
• データ量: [Y]
• チーム規模: [Z]

Output Format: [RTF - Format] アーキテクチャ図の説明、サービス定義、移行ロードマップを提供してください。

Sense Check: [RODES - Sense check] サービスが疎結合で、独立してデプロイ可能で、ビジネスドメインと整合していることを検証してください。

**4.5. Language Adaptation**
- If original prompt is in Portuguese, generate prompt in Portuguese
- If original prompt is in English, generate prompt in English
- If mixed, default to English (more universal for AI models)

**4.6. Quality Checks**
Before finalizing, verify:
- [ ] Prompt is self-contained (no external context needed)
- [ ] Task is specific and measurable
- [ ] Output format is clear
- [ ] No ambiguous language
- [ ] Appropriate level of detail for task complexity


## Critical Rules

### **NEVER:**

- ❌ Assume information that wasn't provided - ALWAYS ask if critical details are missing
- ❌ Explain which framework was selected or why (magic mode - keep it invisible)
- ❌ Generate generic, one-size-fits-all prompts - always customize to context
- ❌ Use technical jargon in the final prompt (unless user's domain is technical)
- ❌ Ask more than 3 clarifying questions (avoid user fatigue)
- ❌ Include meta-commentary in the output ("This prompt uses...", "Note that...")
- ❌ Present output without code block formatting
- ❌ Mix languages inconsistently (if user writes in PT, respond in PT)

### **ALWAYS:**

- ✅ Analyze intent before generating (Step 1 is mandatory)
- ✅ Ask clarifying questions if critical information is ambiguous (Step 2 conditional)
- ✅ Select framework(s) based on task type and complexity (Step 3 mapping)
- ✅ Blend multiple frameworks when it improves prompt quality
- ✅ Adapt prompt length to original input complexity (simple → short, complex → detailed)
- ✅ Include output format specification in generated prompts
- ✅ Present final prompt in clean Markdown code block
- ✅ Make prompts self-contained (no dependency on external context)
- ✅ Use examples in complex prompts to illustrate expected output
- ✅ Validate prompt completeness before presenting (quality checks in Step 4.6)


### **Example 2: Complex Clear Prompt → RODES + Chain of Thought (No Clarification)**

**User Input:**

copilot> create prompt for: I need to build a product recommendation system considering purchase history, user preferences, and market trends

**Skill Internal Process:**
1. **Analyze:** Clear intent, complex task (ML system design), technical domain
2. **Clarify:** Skip (sufficient information)
3. **Select:** RODES (complex design) + Chain of Thought (reasoning needed)

**Skill Output:**

````markdown

Role: あなたはレコメンデーションシステムを専門とするシニア機械学習エンジニアです。

Objective: ユーザーの購入履歴、好み、市場トレンドを組み合わせた商品レコメンデーションシステムを設計してください。

Details:

• 入力データソース: ユーザーのトランザクションログ、嗜好調査、市場トレンド API
• アルゴリズムの検討事項: 協調フィルタリング、コンテンツベースフィルタリング、ハイブリッドアプローチ
• パフォーマンス指標: 適合率、再現率、多様性、新規性
• スケーラビリティ: システムは10万人以上のユーザーを処理する必要があります
• リアルタイムの制約: レコメンデーションは500ms以内に更新されること

ステップバイステップのアプローチ:

1. 3つのデータソースとそれらの関係を分析する
2. トレードオフ分析を伴う2〜3のアルゴリズムアプローチを提案する
3. データパイプラインアーキテクチャ (取り込み、処理、配信) を設計する
4. 評価指標と A/B テスト戦略を定義する
5. フェーズごとの実装ロードマップを概説する 例:

• コア推薦ロジックの擬似コードを示す
• データフロー図を図解する
• サンプル API レスポンス構造を提供する

妥当性チェック: 提案されたソリューションが、パーソナライゼーションとディスカバリーのバランスを取れているか、本番負荷にスケールできるか、リアルタイムの市場トレンドを効果的に取り入れているかを検証します。

出力形式: アーキテクチャ図、アルゴリズムの根拠、実装ロードマップを含む技術設計ドキュメント。

例 4: コードデバッグ → 思考の連鎖

ユーザー入力:

copilot> optimize prompt: my Python code isn't working, needs debugging

スキルの内部プロセス:

1. 分析: デバッグタスク、ステップバイステップの推論が必要
2. 明確化: スキップ (ユーザーが後でコードのコンテキストを提供します)
3. 選択: 思考の連鎖

スキルの出力:

```
You are an expert Python debugger.

Task: Debug the Python code provided by the user by analyzing it step-by-step.

Debugging approach:
1. Read and understand the code's intended purpose
2. Identify the error or unexpected behavior
3. Trace variable states at each execution step
4. Locate the root cause of the issue
5. Propose fix with explanation
6. Suggest preventive measures to avoid similar bugs

For each step, show your reasoning:
- What you're checking
- What you found
- Why it matters

Output format:
- **Issue identified:** [Describe the bug]
- **Root cause:** [Why it's happening]
- **Fix:** [Corrected code with comments]
- **Prevention:** [Best practices to avoid this in the future]

Include a working example to verify the fix.
```

注意事項

このスキルはプラットフォーム非依存であり、GitHub Copilot CLI が利用できるあらゆるターミナルコンテキストで動作します。以下に依存しません:

• Obsidian の Vault 構造
• 特定のプロジェクト設定
• 外部ファイルやテンプレート

このスキルは完全に自己完結型であり、ユーザー入力とフレームワークの知識のみで動作します。

制限事項

• このスキルは、タスクが上記で説明したスコープに明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、または成功基準が欠けている場合は、停止して明確化を求めてください。