prompt-generator

プロンプトジェネレーター

ユーザーの大まかな考え、まとまりのないメモ、またはまだ形になっていないアイデアを、すっきりと整理された LLM プロンプトに仕上げます。これはフォーマッターおよび構成ツールであり、ブレインストーミングツールではありません。ユーザーはすでに希望する内容を把握しており、それを適切に表現して整理する支援を必要としています。

使用する場面

• ユーザーが、すっきりとした LLM プロンプトにまとめたい大まかなメモ、箇条書き、または思いつくままに書き出した内容を持っている
• 期待どおりに機能していない既存のプロンプトを改善、書き換え、または最適化する
• まとまりのない要件から、システムプロンプト、単発タスク用プロンプト、再利用可能なテンプレート、評価プロンプト、コードレビュープロンプト、または委任プロンプトを構成する
• 繰り返し使うための変数プレースホルダーを含むプロンプトテンプレートを作成する
• ユーザーが「〜のプロンプトを書いて」「これをプロンプトにして」「〜のシステムプロンプト」のようなことを言う

使用しない場面

• 機能のブレインストーミングやクリエイティブなアイデア出し。このスキルはアイデアではなく、プロンプトを整理します
• 再利用可能なスキルファイルやエージェント指示の一式を作成する場合（skill-creatorを使用してください）
• スケジュール、定期実行、イベントトリガーを設定する場合。ホストの自動化機能を使用してください。
• アプリケーションコード内にインラインのプロンプト文字列を書く場合。それは通常のコーディングです
• ユーザーが LLM API を呼び出すコードを求めている場合（SDK 統合には llm-app-development を使用してください）
• インジェクションのリスクについてプロンプトのセキュリティレビューを行う場合（security-auditを使用してください）
• プロンプト関連コードの品質をレビューする場合（code-reviewまたはcode-simplificationを使用してください）

---

AI のセルフチェック

生成または変更したプロンプトファイルを返す前に、次の点を確認してください。

• 保存ファイルのフロントマターが揃っている：永続化するプロンプトファイルには、name、description、target_model、prompt_type、date_createdが含まれています。インラインの下書き、レビュー、未保存の出力にはフロントマターは不要です
• 入力に忠実である：プロンプトにはユーザーの発言が反映されており、ユーザーが言うべきだったとあなたが考える内容ではありません
• 複雑さに合った構成である：単純なタスクには通常の文章を使い、XML タグ付きの複数セクションからなるプロンプトにはしません
• 変数に一貫性がある：プロンプト本文内のすべての{{PLACEHOLDER}}が Variables テーブルに記載され、その逆も同様です
• 無関係な指示がない：ユーザーの意図を保ち、指定された用途に必要な最小限の出力構成だけを追加します。無関係なエラー処理、免責事項、制約は追加しません
• 信頼できないテキストが区切られている：プロンプトでモデルに指示する前に、ソーステキスト、ユーザーの例、ログ、ウェブページ、ドキュメントが明確に囲まれているか、ラベル付けされています
• 冗長な定型句がない：プロンプトテキストに「もちろんです」「喜んでお手伝いします」「良い質問です」などの埋め草が含まれていません
• 出力形式が指定されている：プロンプトが構造化出力を求める場合、形式が明確です（JSON スキーマ、XML タグ、区切り文字など）
• 評価基準が明確である：評価プロンプトでは、合格・不合格の基準、必要な根拠、よくある失敗パターンが定義されています
• 委任の取り決めが明確である：委任プロンプトでは、担当範囲、対象、ファイル、許可される編集、期待する最終回答の形式が定義されています
• モデルに適した構文である：プロバイダー固有の機能（assistant の先行入力、\n\nHuman:形式など）は、ユーザーがそのプロバイダーを指定した場合に限って使用します。XML の区切りと Markdown の見出しは、どのモデルでも問題ありません
• エージェント全般の衛生要件を適用してください。references/agent-hygiene.mdを参照してください

---

パフォーマンス

• タスクに必要な範囲でプロンプトを短く保ち、重複する役割の説明や制約を取り除きます。
• 長いブロックを重複させる代わりに、繰り返し使う動的な内容には変数を使用します。
• 構造が重要な場合は、長い説明文より明示的な出力スキーマを優先します。

---

ベストプラクティス

• 複雑なプロンプトには、出力を評価できるよう成功基準を含めます。
• 想定される用途に合ったプロンプトの種類を選びます。references/prompt-families.mdを参照してください。
• 評価プロンプトには、観察可能な根拠を含む評価基準表を使用します。references/evaluator-prompts.mdを参照してください。

ワークフロー

Step 1: ブレインダンプを読む

ユーザーは、プロンプトに何をさせたいかについて、ラフなメモ、箇条書き、または思いつくままの説明を提示します。次の点を読み取ってください。

• 主なタスク：プロンプトで指示されたモデルは、実際に何をすべきですか？
• 対象モデル：どの LLM ですか？指定がない場合は、特定のモデルに依存しないものとします。
• プロンプトの種類：システムプロンプトですか、それともタスクプロンプトですか？
• 制約：言及されているルール、形式要件、または行動上の制限はありますか？
• 変数：{{PLACEHOLDERS}} に置き換えるべき動的なコンテンツはありますか？

ユーザーが言及していない内容を追加しないでください。目的は、独自の考えで「改善」することではなく、ユーザーの意図を忠実に構成することです。

Step 2: 行き詰まった場合にのみ確認する

本当に曖昧な場合（システムプロンプトかタスクプロンプトか判断できない場合や、手法の選択に対象モデルが関わる場合）に質問してください。質問はまとめて行い、1 回までとします。合理的に推測できる場合は、そのまま推測してください。1 回質問した後も曖昧さが残る場合は、最も妥当な既定値を選び、ユーザーがレビュー時に修正できるよう、その仮定を明記してください。

ほとんどの場合、このステップは省略します。

Step 3: 構成して提示する

1. 複雑さに応じた構成で、ラフなメモを整理されたプロンプトにします。
   • シンプル（タスクが 1 つで、変数なし）：通常の文章で 3～10 行。XML やセクションは使用しません。
   • 中程度（複数の手順または制約あり）：番号付きの手順と、明確なセクションを使用します。
   • 複雑（エージェント型、複数ドキュメント、行動ルールあり）：明確なセクション区切り、変数プレースホルダー、明示的な出力形式を使用します。
   • 再利用可能なテンプレート：変数の表と、固定の {{VARIABLE_NAME}} プレースホルダーを含めます。
   • 評価用プロンプト：評価基準、合否のしきい値、不合格の例、必須の根拠を定義します。
   • 委任用プロンプト：タスク、担当範囲、対象ファイル、対象外ファイル、許可された編集、出力仕様を定義します。
2. AI Self-Check に照らしてドラフトを確認します。不合格の項目があれば修正し、すべて合格するまで再確認します。
3. インラインのドラフトやレビューを求められた場合は、ファイルを書き込まず、会話内でプロンプトを提示します。
4. ユーザーがローカルファイルの作成、保存、または編集を依頼した場合は、既存の許可の範囲内でその書き込みを完了します。それ以外の場合は、ユーザーがドラフトの保存を依頼した後にのみ保存します。
5. 修正する場合は、別のファイルを作成せず、既存のファイルをその場で編集します。

Step 4: 保存する

1. ユーザーがファイル名を指定した場合は、変更せずそのまま使用します。指定がない場合は、出力先ディレクトリを次の優先順位で決定します。 ユーザー指定のディレクトリ > git check-ignore で確認できた場合に限り docs/local/prompts/ > ユーザーに確認する。追跡対象の docs/ にはドラフトを保存しないでください。
2. ファイル名が指定されていない場合に限り、推測したトピックのスラッグ（例：code-review）を使って <YYYY-MM-DD>-<slug>.md という名前を付けます。同名のファイルがある場合は、-2、-3 などを付けます。
3. 指定されたファイル名、または確定した <output-dir>/<YYYY-MM-DD>-<slug>.md に書き込みます。

---

出力ファイル形式

---
name: Descriptive Prompt Name
description: One-line summary
target_model: model-agnostic
prompt_type: system | task
date_created: YYYY-MM-DD
---

## Purpose

What this prompt does and when to use it.

## Variables

| Variable | Description | Required |
|----------|-------------|----------|
| `{{VAR}}` | What it is | Yes/No |

## Prompt

The actual prompt content here.

該当するセクションのみを含めてください。変数のないシンプルなプロンプトでは、Variables の表を省略します。

フロントマターは、保存するファイルにのみ適用されます。インラインのドラフトやレビュー結果には、説明対象となる保存済みの成果物がないため、フロントマターを付けません。

任意のフロントマターの追加項目：tags: [...]、related: [<YYYY-MM-DD>-other.md]。本当に役立つ場合にのみ追加してください。

対象モデルの値：claude、gpt、gemini、llama、mistral、model-agnostic

構成ガイドライン

プロンプトの種類に応じて振り分けます。 単純なタスクのプロンプトはインラインのままにします。再利用可能なプロンプトには変数が必要です。評価用プロンプトには評価基準と失敗例が必要です。委任用プロンプトには担当範囲と返却形式が必要です。コードレビュー用プロンプトでは、指摘事項を最初に示し、ファイルと行番号を参照する必要があります。

内容に合わせて複雑さを調整します。 3行のタスクにXMLタグや番号付き手順は必要ありません。一方、複数のドキュメントを扱うエージェント型システムプロンプトには必要です。ユーザーの大まかなメモから、必要な複雑さを判断できます。

長いコンテンツは先頭に置きます。 実行時にプロンプトへ大きなドキュメントやデータを渡す場合は、データ用のスロットを先頭に、タスクの指示を末尾に配置します。複数のドキュメントを扱うタスクで、パフォーマンスが最大30％向上します。

何をするかだけでなく、なぜそうするのかを説明します。 ユーザーのメモにルール（「マークダウンを使わない」など）が含まれている場合は、その理由を添えた制約（「出力はTTSエンジンに渡すため、通常の文章で記述する」など）に変えます。モデルは理由から一般化します。

エージェント型プロンプトには境界が必要です。 コーディングエージェントや自動化向けのプロンプトでは、自由に実行できる操作（読み取り、検索）と、確認が必要な操作（削除、公開、プッシュ）を分けます。

ハルシネーション防止は、段落ではなく一文で十分です。 「提示されたコンテキストから検証できる主張のみ行ってください。不確かな場合は、そう伝えてください。」これだけです。

モデル固有のフォーマット

対象モデルが分かっている場合は、そのモデルの強みに合わせてフォーマットを調整します。

対象	推奨される構成	備考
Claude	セクションにXMLタグ、コンテンツにマークダウン	選択したモデル／APIでプレフィルがサポートされているか確認してください。区切り文字は出力スキーマを強制しません
GPT	マークダウンの見出し、構造化出力にはJSONスキーマ	ネイティブのJSONモードが利用できる場合は、文章によるフォーマット指示よりもそちらを使ってください
Gemini	マークダウンのセクション、明示的な出力例	テキスト用と添付ファイル／画像用の指示を分けてください
モデル非依存	マークダウンの見出し＋明示的な区切り	プレフィル、モデル固有のタグ、フォーマットモードのフラグは避けてください

強い口調での大声の指示（「重大！」、「必ず」、「絶対に」など）は、たいてい効果を高めるよりも損ないます。落ち着いた明確な指示を使ってください。

モデルをアップグレードする場合は、既存のプロンプトと短縮版を、同じタスク、固定した成功基準、同じ評価者で比較します。根拠の提示要件、信頼できない入力の境界、ユーザーのスコープは維持してください。観測された失敗に対してのみモデル固有のルールを追加します。新しいモデルだからといって、足場となる指示を増やす理由にはなりません。

ユーザーが範囲を限定したエージェント作業を求める場合は、完了条件と停止条件を明示します。依頼された変更と関連するチェックを終えたら、そこで停止します。確認が必要な状況と、承認が必要な操作を明記してください。回答の品質だけでなく、不必要な中断、繰り返しの確認、無関係な編集も測定します。努力レベルの設定は、努力を制御すると装う文章ではなく、ホスト／APIの設定で行ってください。Sonnet 5.5のガイダンスでは、明確に仕様が定まったエージェント作業はmedium、より難しい作業はhighから始めます。古い努力レベルをそのまま引き継ぐのではなく、設定を再評価してください。
Sonnetのプロンプトガイドを参照してください。
努力レベルをlowにしたHaiku 5.5は、検索を省略したり、長いエージェントプロンプトで早期に停止したり、検証をより頻繁に省いたりします。検索タスクでは現在の日付を渡し、完了条件とチェック基準を明示してください。xhigh／maxが必要な場合は、Sonnet 5.5と比較してください（Haikuのプロンプトガイド）。
GPT-6ファミリーのガイダンスでは、Astraでの観察結果が説明されています。推奨事項を採用する前に、選択したモデルでテストしてください。

構造化出力のガイダンス

プロンプトを人間ではなくエージェントが利用する場合は、出力形式を明示してください。

• JSON モード：ツールがネイティブの JSON モードまたはスキーマで制約された出力をサポートしている場合は、それを使用してください。そうでない場合は、有効な JSON を返すようモデルに指示してください。ツールがアシスタントのプレフィルに対応している場合に限り、{ で始めてください。
• XML 構造：出力を <result>、<analysis>、<decision> などのタグで囲みます。
• 区切り文字ベース：シンプルなキーと値の形式には、KEY: value 形式を使用します。

可能な場合は、プロンプトに具体的な出力例を含めてください。モデルは形式の説明よりも例からうまく一般化できます。

4 ブロックパターン

中程度から複雑なプロンプトは、次の 4 つの明確なブロックで構成します。

1. INSTRUCTIONS - 実行する内容（役割、タスク、制約）
2. CONTEXT - 背景情報、参照データ
3. TASK - この呼び出しでの具体的な依頼
4. OUTPUT FORMAT - 期待する応答の正確な構造

XML タグ、Markdown 見出し、その他の明確な区切りを使い、ブロックを視覚的に分けてください。長いコンテキスト文書は、短いタスク指示より前に配置してください（上記の「長い内容を先に」参照）。

---

既存のプロンプトの改善

ユーザーが既存のプロンプトを渡して改善を依頼した場合（雑なメモではない場合）：

1. 内容を確認します
2. 不足点を診断します。次のよくあるプロンプトの弱点を確認してください。
   • スコープの欠如：モデルがすべきこと、すべきでないことの境界が明確でない
   • 出力形式の指定がない：仕様に従うのではなく、モデルが構造を推測する
   • 役割が曖昧：「親切なアシスタント」では、モデルに役立つ情報を与えられない
   • 制約の欠如：アンチパターン、「してはいけないこと」の一覧、品質基準がない
   • 過剰な指定：2～3 個の明確な制約で十分なのに、ルールが多すぎる
3. レビューのみの依頼では、編集せず、理由を添えて具体的な変更案を示します。
4. ローカルファイルの改善を許可された場合は、ファイルを直接編集し、変更点を要約します。

改善例：

変更前：コードをレビューする親切なアシスタントです。

変更後：あなたはシニアコードレビュアーです。各ファイルについて、バグ、エッジケース、セキュリティ上の問題、パフォーマンスの問題を確認してください。優先度（P0/P1/P2/P3/info）、ファイル:行番号、1 行の説明を含むリストで指摘事項を報告してください。スタイル上の細かな指摘は省いてください。問題がなければ「問題は見つかりませんでした」と伝えてください。 - 追加内容：スコープ、出力形式、優先度の尺度、ノイズを抑える制約。

ゼロからの作成例

ユーザーの入力（アイデアのメモ）：

より良いメールを書くのを支援する AI が欲しいです。文法を直し、文章を簡潔にし、希望するトーンに合わせてほしいです。フォーマルな場合も、カジュアルな場合もあります。

構造化された出力：

You are an email editor. You receive a draft email and a target tone, then return an improved
version.

Your edits:
- Fix grammar and spelling errors
- Make the text more concise - cut filler words and redundant phrases
- Match the requested tone (formal, casual, or neutral)

Preserve the sender's intent and meaning. Do not add information they didn't include.
Do not change the greeting or sign-off style unless it clashes with the requested tone.

Input format:
  TONE: {{TONE}}
  DRAFT:
  {{EMAIL_DRAFT}}

Return only the improved email. No commentary, no explanations, no "Here's your improved email:".

注：シンプルなタスクなので、通常の文章を使用します。XML のセクション、番号付き手順、冗長な前置きは不要です。

---

出力契約

契約の全文は references/output-contract.md を参照してください。

• スキル名： PROMPT-GENERATOR
• 成果物の分類： prompts
• モード： 条件付き。既存のリポジトリの内容を分析、レビュー、監査、または改善するために呼び出された場合（例：既存のプロンプトの品質レビュー）は、references/output-contract.md の報告サイズと根拠に関するルールを適用し、成果物を docs/local/prompts/prompt-generator/<YYYY-MM-DD>-<slug>.md に書き込みます。質問への回答、概念の説明、新しい成果物の作成、コンテンツの生成を求められた場合（主なモードであり、ユーザー向けのプロンプトを作成する場合）は、契約に従わず自由に応答します。
• 重大度の尺度： P0 | P1 | P2 | P3 | info（共有契約を参照。監査／レビューのモードでのみ使用）。

関連スキル

• skill-creator - AI ツールやコーディングエージェント向けの再利用可能なスキルファイル（SKILL.md）を作成します。スキルは構造化されたプロンプトですが、単独のプロンプトとは異なる規則（フロントマター、ワークフローのセクション、ルール）に従います。「スキルを作成して」と言われた場合は、skill-creator を使用してください。
• スケジュールやイベントトリガーには、ホストの自動化機能を使用してください。このスキルではプロンプト本文の作成を支援できますが、定期実行ジョブの設定は行いません。
• アプリケーションコード - ユーザーがアプリケーションコード内のプロンプト文字列（たとえば TypeScript の const systemPrompt = ...）を必要としている場合、それはコーディングであり、このスキルの対象ではありません。
• code-simplification - ユーザーがコードに埋め込まれたプロンプトの「クリーンアップ」や「簡素化」を求めている場合、それはプロンプトの構造化ではなく、コード品質の問題です。

---

ルール

1. 忠実な構造化。 ユーザーの事実と意図を維持してください。出力構造が指定されていない場合は、明示された後続の用途に必要な最小限の構造だけを推測してください。その選択によって意味が変わる可能性がある場合や、用途から判断できない場合は、質問するか、未確定のままにしてください。改良時には、信頼性の高い評価を妨げる出力仕様の欠落があれば指摘してください。
2. 既存の承認を尊重する。 ローカルのプロンプトファイルの作成、保存、編集を求める依頼は、その書き込みを許可しています。インラインの草案やレビューは会話内で行ってください。破壊的な操作や外部への操作については承認を得たうえで、ユーザーの明示的な指示をこのスキルのデフォルト設定より優先してください。
3. ユーザーの語調を尊重する。 元のメモに特定の語調や個性がある場合は、構造化した内容でもそれを維持してください。