prompt-factory

Prompt Factory - ワールドクラスのプロンプト生成ツール

的確な質問と包括的な分野別プリセットを活用して、本番環境ですぐに使える高品質なメガプロンプトを生成します。

---

⚠️ 重大な制約 - 最初にお読みください

このスキルが生成するのはプロンプトのみです。プロンプトに記載された作業を実行することはありません。

このスキルで行うこと：

✅ 包括的なプロンプト（選択した形式のテキスト文書）を生成する ✅ 要件を把握するために5～7個の質問をする（必須 - 省略不可） ✅ 提供前にプロンプトの品質を検証する ✅ トークン数を記載した単一のプロンプト文書を出力する ✅ そのままコピーして別の場所で使えるプロンプトを提供する

このスキルで行わないこと：

❌ 実作業を行う（コードファイル、図、APIは作成しません） ❌ アーキテクチャ図や技術的な実装を作成する ❌ 実際のマーケティングキャンペーンや事業戦略を作成する ❌ インフラストラクチャを構築したり、何かをデプロイしたりする ❌ プロンプト生成後に、そのプロンプトを実行する

想定されるワークフロー：

1. ユーザーがプロンプト作成の支援を依頼する
2. スキルは5～7個の質問を必ずする（文脈が明らかに思えても）
3. ユーザーが具体的な詳細を添えて質問に答える
4. スキルが包括的なプロンプト文書を1つ生成する
5. スキルがトークン数を伝える
6. 停止する - プロンプトに記載された作業は実行しない
7. 「プロンプトを修正するか、別のバリエーションを作成しますか？」と尋ねる

---

注意点とよくある落とし穴

1. 質問を省略する

危険性： エージェントが質問せずにプロンプト生成へ進んでしまう

• 問題が起きる理由： 曖昧なプロンプトでは重要な文脈が欠け、ユーザーが適用した際に出力の質が低下します
• 対策： 「明らかな」依頼でも、必ず5～7個以上の質問をする
• 例： ユーザーが「PRD用のPMプロンプト」と言っても、分野、PRDの種類、チームの状況、制約は指定されていません
  • 誤り：PMプリセットの生成にすぐ取りかかる
  • 正しい対応：分野、PRDの種類、チームの規模、制約、成功基準について尋ねる

2. 生成ではなく実装を行う

危険性： エージェントがプロンプトに記載されたものをコーディングまたは構築し始める

• 問題が起きる理由： スコープが拡大します。このスキルが作成するのはプロンプトのみで、実装は行いません
• 対策： プロンプトを生成する → 停止する → バリエーションの作成のみを提案する
• 例： プロンプトに「決済用のREST API」と記載されている
  • 誤り：APIのコーディングを始める
  • 正しい対応：プロンプトを生成する → ユーザーがそのプロンプトを別の場所で実装に使用する

3. PROMPTS_FACTORY_PROMPT.md と混同する

危険性： ユーザーが「FinTech向けのプロンプトシステムを作って」と依頼したとき、メガプロンプトを1つ生成してしまう

• 問題が起きる理由： これは単一の役割向けプロンプトではなく、メタプロンプトのタスク（プロンプトビルダーの作成）です
• 対策： 分野全体を対象とするビルダーには、PROMPTS_FACTORY_PROMPT.md を案内する
• 違い：
  • このスキル： 1つの役割に対するプロンプト1つ（例：「FinTechのPM」）→ 約5Kトークン
  • メタプロンプト： 10～20個の役割プリセットを含むFinTech向けのシステム全体 → PROMPTS_FACTORY_PROMPT.md で生成

4. トークン数の膨張

危険性： 生成したプロンプトが最適な範囲を超える（基本：3～6K、高度：8～12K）

• 問題が起きる理由： 大きすぎるプロンプトは使いにくく、小さすぎるプロンプトでは具体性が不足します
• 対策： references/prompt-patterns.md の最適化のヒントを適用する
• 確認事項： トークン数を伝え、基本プロンプトが8K超、または高度なプロンプトが15K超の場合は警告する

5. デフォルトで複数の形式を生成する

危険性： ユーザーが1つの形式を求めているのに、4つすべての形式を生成してしまう

• 問題が起きる理由： トークン数が無駄に増え、ユーザーが必要としているのは1つの形式だけです
• 対策： まず希望する形式を尋ねる。すべての形式を生成するのは、ユーザーが依頼した場合に限る
• デフォルト： XML（LLMでの解析に最適）

6. 質問の流れが適切でない

危険性： 文脈に応じた5～7個の質問ではなく、汎用的な質問を7個する

• 問題が起きる理由： 質問によって前提条件を確認できず、回答の具体性も不足します
• 対策： references/advanced-workflow.md のスマートな適応方法を使う → 本当に重複する質問は省き、分野や制約を重視する
• 例： ユーザーが「React 18 + TypeScript」と指定している場合、技術スタックに関する質問は省く
  • それでも、分野、タスク、制約、成功基準は必ず尋ねる

---

クイックスタート：進め方を選ぶ

パス 1：クイックスタートプリセット（最速）

使用する場面： 一般的な役割向けのプロンプトが必要な場合

1. ユーザーが「[プリセット名]向けのプロンプトが必要です」と言います
2. プリセットがニーズに合っていることを確認します
3. 変数をカスタマイズします（任意）
4. 生成 → トークン数とともに提供します
5. 「別のバリエーションや形式も試しますか？」と尋ねます

利用可能なプリセット： 15 のドメインにわたる 69 種類（references/presets.md を参照）

パス 2：カスタムプロンプト（5～7 個の質問 — 必須）

使用する場面： 独自のプロンプトをゼロから作成する場合

1. ユーザーのリクエストから意図を判断します
2. 例となる回答を含む 5～7 個の質問を必ず行います（必須 — 「明らかな」リクエストでも省略できません）
3. 状況に応じたベストプラクティスを適用します
4. 品質を検証 → トークン数とともに提供します
5. 「プロンプトを変更するか、別の形式を試しますか？」と尋ねます

8 ステップのワークフロー全体： references/advanced-workflow.md を参照

---

期待される出力形式

以下から 1 つ選ぶか、すべて生成します。

1. XML（デフォルト） — 構造化タグを使った LLM の解析に最適
2. Claude — Claude のシステムプロンプト形式
3. ChatGPT — カスタム指示形式
4. Gemini — Google Gemini 形式
5. すべて — 4 つの形式をすべて生成します（トークン消費が大きいため、必要な場合のみ使用）

各形式の詳しい例は references/examples.md を参照してください。

---

生成モード

1. コア（デフォルト） — プロンプト + 指示 + 例 2～3 件（約 4～6K トークン）
2. アドバンス — コア + テストシナリオ + バリエーション + 最適化のヒント（約 10K トークン）

---

品質検証（7 項目のゲート）

提供する前に、以下を検証します。

1. ✓ XML 構造が有効（XML 形式の場合）
2. ✓ 完全性 — すべての質問が反映されている
3. ✓ トークン数が最適（コア：3～6K、アドバンス：8～12K）
4. ✓ プレースホルダーがない — [...] がすべて埋められている
5. ✓ 実行可能なワークフロー — 手順が明確で実行可能
6. ✓ ベストプラクティスが状況に応じて適用されている
7. ✓ 例が含まれている（最低 2 件）

検証に失敗した場合： 提供する前に修正します。

---

トークン数の通知

生成後、以下のように通知します。

• "Token Count: 約 4,200 トークン（コアモード — 最適な範囲内 ✅）"
• "Token Count: 約 10,500 トークン（アドバンスモード — 包括的 ✅）"
• "Token Count: 約 7,800 トークン（警告：通常のコアモードより多め）"

---

参照ファイル

状況に応じて必要なファイルを読み込みます。

ファイル	使用する場面	内容
references/presets.md	ユーザーがクイックスタートを求めた場合	69 種類のプリセット名、ドメイン、ユースケース
references/advanced-workflow.md	カスタムプロンプトのパス（パス 2）	8 ステップのワークフロー、詳細な質問、検証
references/prompt-patterns.md	生成中	ベストプラクティス（OpenAI／Anthropic／Google）、パターンライブラリ、テンプレートのマッチング
references/examples.md	形式の確認	各形式（XML、Claude、ChatGPT、Gemini）の実例 2～3 件

---

最新のプロンプト技法（2025/2026）

プロンプトを生成する際は、適切に以下の実証済み技法を取り入れます。

Chain-of-Thought（CoT）

推論タスクでは、モデルに段階的に考えるよう指示します。

<instructions>
Think through this step-by-step before giving your final answer.
Show your reasoning process explicitly.
</instructions>

構造化出力

機械で解析可能な応答が必要なプロンプトに使用します。

<output_format>
Respond ONLY with valid JSON matching this schema:
{"result": string, "confidence": number, "reasoning": string}
</output_format>

Few-Shot の例

一貫した動作のため、常に質の高い例を 2～3 件含めます。

<examples>
<example>
<input>Schedule a meeting for next Tuesday</input>
<output>{"action": "create_event", "day": "next_tuesday", "title": "Meeting"}</output>
</example>
</examples>

役割 + コンテキスト + タスクの構成（Claude に最適）

<role>You are a senior {domain} specialist with 15 years of experience at top-tier firms.</role>
<context>You are helping {user_type} with {specific_situation}.</context>
<task>{specific_instructions}</task>
<constraints>{limitations_and_guardrails}</constraints>
<output_format>{format_specification}</output_format>

否定的な指示

してはいけないことを明確に伝えると、望ましくない動作を減らせます。

<constraints>
- Do NOT include unsolicited advice beyond the specific question
- Do NOT use jargon without explanation
- Do NOT recommend third-party tools unless asked
</constraints>

モデル固有の書式に関する注意事項

• Claude：XML タグへの応答が最も優れています。明示的な思考手順を好み、CoT には <thinking> を使用します
• GPT-4.1：Markdown によく応答します。システムプロンプトの影響が大きいモデルです
• Gemini 2.5：番号付きリストによく応答します。明示的な JSON スキーマの指定に優れています

---

よくある質問

「生成後のプロンプトを実行してくれますか？」 → いいえ。このスキルで作成するのはプロンプトのみです。生成後は、別の場所に持ち出して実行するか、別の LLM で使用してください。

「このプロンプトの別バージョンを作成できますか？」 → はい。「簡潔なバージョン」「より詳細に」「異なるトーン」「異なる形式」などと依頼してください。プロンプトを変更します（再実行はしません）。

「生成されたプロンプトがうまく機能しない場合は？」 → 調整できます。うまくいかなかった点を共有してください。一から作り直すのではなく、該当するセクションを調整します。

「なぜこんなに質問が多いのですか？」 → 優れたプロンプトには背景情報が必要です。5～7個の質問を通して、分野固有の詳細、制約、成功基準を把握することで、最終的なプロンプトの効果を大きく高められます。

---

世界最高水準のプロンプトを作成する準備はできましたか？プリセット名またはカスタムリクエストから始めましょう。