skills/dialogue-prompt/references/before-self-revision.md

---
name: dialogue-prompt
description: 対話から人間の意図を整理し、Why / IntentとHow / Schemaを分けた実行用プロンプトを作成・改訂する。意図を保った指示づくり、目的と手順を分ける設計、対話をもとにしたプロンプト改善を求められたときに使う。単純な文章推敲や、完成プロンプトの実行には使わない。
---

# 対話から育てるプロンプト

人間が実現したいことを対話からつかみ、意図を保った実行用プロンプトへ具体化する。目的を理解して判断できる余地と、守るべき条件の明確さを両立させる。

## 人間の意図をつかむ

既存の対話、依頼、提示されたプロンプトを読み、目的、理由、望む結果、制約を整理する。対話の途中から呼び出された場合も、それまでの材料を使う。参照できない会話は読めたことにせず、必要な箇所だけ尋ねる。

人間が述べた意図を、一つのまとまった見解として展開する。その各文にAIの留保を差し込んだり、AIの一般論で置き換えたりしない。語句や構成を整える際も、価値判断と確信の強さを保つ。AIが提案した目的・根拠・条件は別に示す。

実行先、入力、望む出力、権限など、指示の内容を左右する不明点を少数に絞って確認する。十分な材料があればそのまま進め、軽微な仮定は明示する。許可の範囲は推測で補わない。

## 意図を実行条件にする

設計資料では、条件の出自を「人間の明示」「既存の運用条件」「AIの提案」「未確定」に分ける。提案を人間が採用した場合はその経緯を残す。AIが補った条件を、本人の当初の要求として書かない。

意図ごとに、必要な行動、出力、完了条件、確認方法を考える。条件は達成に必要な範囲へ絞り、単純な作業を例外規則で膨らませない。手順を固定するのは、順序が正確さや権限に影響する場合など、理由がある箇所にする。

## 実行用プロンプトを組み立てる

二つの役割を分け、実際の仕事に合った見出しと長さで書く。

### Why / Intent

何を実現したいか、なぜ大切か、判断で何を重視するかを、短い連続した文章で伝える。人間の意図にAIの提案を統合する場合は、設計資料で採用状態を追えるようにする。対話の全履歴や評価過程を、毎回読む目的説明へ詰め込まない。

### How / Schema

入力、作業範囲、必要な手順、出力形式、完了条件を具体化する。形式が重要な場合にだけスキーマや見本を設ける。自由な記述が適する仕事にJSONなどを強制しない。

WhyはHowの条件内で判断する手掛かりになる。目的の達成を理由に、明示された制約や権限を上書きしない。両者が矛盾する場合は矛盾を示し、確認を要する判断と進められる作業を分ける。

外部への書き込みを含む仕事では、許可範囲、送信結果が不明な場合の確認先、再試行を止める条件を明確にする。読み取りや整形だけの仕事に、公開のための承認手順を追加しない。

実行用プロンプトは、渡された側が設計資料なしでも必要な条件を理解できる形にする。外部ファイルを参照する場合は、実行先から参照できる場所と読むタイミングを示す。

## 比較できる形で渡す

通常は次の内容を渡す。短い依頼なら一つの文書にまとめてよい。

- 意図と検討：人間の目的、AIの提案、仮定や未確定事項。
- 実行用プロンプト：コピーして使える完成稿。
- 対応と確認：重要な条件の出自、対応する意図、確認方法。

改訂では原文を保存し、文体・配置の変更と、条件の追加・削除を区別する。比較案の作成を、現行プロンプトの置き換えや外部での実行の許可と扱わない。

設計資料に人名は必須ではない。人物紹介を求められた場合だけ掲載名を確認し、別の事例の氏名を引き継がない。

## 確認して仕上げる

意図が条件へ移る途中で変わっていないか、目的が手順と矛盾しないか、出力と完了条件が対応しているかを点検する。正常に完了した後の反復確認を既定にしない。

実行比較を求められた場合は、同じ入力・条件・評価基準を用いる。文体の効果を比べるなら運用条件も揃える。作業に応じて成果の正確さ、範囲の遵守、不要な操作、失敗時の扱いを評価する。未実施の評価を実測結果として書かない。

必要なら [設計資料の小さな例](references/example.md)を読む。見本の条件は実際の依頼に合わせて選び、固有の運用ルールを転用しない。