skills/dialogue-checker/references/before-dialogue-prompt.md

---
name: dialogue-checker
description: 対話や制作意図を基準に、MVP・文章・設計・プロンプトなどをレビューする。修正の必要性を判断し、意図した特徴や簡略化を保ち、基準を満たせば修正不要として完了する。別セッションへのレビュー引き継ぎ、改修の繰り返しによる意図の喪失を防ぎたいときにも使う。
---

# 意図を引き継ぐチェック

作りたかったものが実現しているかを確かめる。レビューの成果は、必要な修正を根拠とともに特定すること、または現在の目的に十分な完成を認めることにある。指摘の数や修正量を成果にしない。

## 判断の基準をつかむ

依頼、成果物、利用できる対話・仕様・過去の判断を読み、今回の目的、対象範囲、完成条件、残したい特徴を把握する。MVPや試作は、その段階の約束で評価する。

人間が明示した意図、記録された採用理由、現在の説明、AIの推測、未確認を区別する。理由が資料にない設計を、ただちに誤りと判断しない。資料を先に調べ、合否や重大な修正判断を変える不明点だけ質問する。動機をすべて説明してもらうことは開始条件にしない。

明示された完成条件がない場合は、依頼から読み取れる基準を短く示す。美観や将来性について独自に高い基準を追加しない。停止・訂正の希望があれば、その時点の確認結果を残して従う。

## 判断を変える確認を選ぶ

対象に合った確認を行う。コードなら該当動作や失敗経路、文章なら意味・帰属・事実、設計なら成立条件や矛盾を調べる。テストや資料を実際に確認した範囲と、推測を分ける。

意図した簡略化や独自性が、目的と両立しているかを見る。一般的な慣習と異なるだけで修正対象にしない。好みの変更と不具合を分け、修正で失われる特徴や新たな負担にも目を向ける。

意図の尊重は欠陥の免除ではない。再現する故障、原文の意味の変化、権限逸脱など実際の問題があれば、影響する範囲を示す。目的に書かれていなくても、対象に具体的な重大被害が認められる場合は報告する。仮想的な危険を網羅して合否を覆さない。

同じ材料で確認を増やす前に、それによってどの判断が変わるかを考える。依頼範囲の確認が済み、新しい根拠もなければ終了する。調べられない重要事項は、欠陥や合格へ変換せず確認不足として扱う。

## 指摘を必要性で分ける

必要な指摘には、対象箇所、根拠、今回の目的への影響、最小限の対処を添える。再現手順や出典がある場合は示す。結論を支えるだけの情報量にし、件数の下限は設けない。

- **修正が必要**：今回の成立条件を満たさない、または具体的な重大問題がある。
- **判断に必要な確認**：合否を左右する情報が不足している。確認先や質問を具体化する。
- **任意の拡張**：現在の完成を妨げない別の可能性。求められた場合や判断に役立つ場合に限り、必要修正と分けて示す。

指摘がない欄は省いてよい。任意の提案を、レビューした証拠として毎回追加しない。評価基準を変える必要がある場合は、旧基準での結果と新しい提案を分け、人間の採用判断へ渡す。

## 完了を判断する

結論を先に、対象と確認範囲を添えて伝える。次のいずれかを自然な文章で示す。

- 今回の目的と確認範囲で、修正が必要な問題は見つからなかった。現状で次へ進める。
- 修正が必要な問題がある。根拠と必要な修正を示す。
- 重要な確認が不足し、現時点では合否を判断できない。必要な確認を示す。

「完璧」「絶対安全」の保証を必要としない。確認が十分なら、未検証の可能性を最後に定型的に並べて完了判断を打ち消さない。大きな未確認事項は結論そのものへ反映する。

レビュー依頼だけでは成果物を変更しない。修正も依頼されていれば、必要な範囲を直し、影響する箇所を確認する。再レビューは修正箇所と波及範囲を中心にし、新しい根拠や依頼なしに基準や対象を拡大しない。

## 次の担当へ意図を渡す

引き継ぎが必要なら、目的・評価基準、維持する特徴、確認した根拠、結果、未確認事項、再検討する条件を短く残す。過去の指摘は解消・継続・判断変更を追えるようにする。機械的な全項目記入や毎回答の記録は求めない。

単独でも使えるスキルであり、複数の観点を使うことを独立監査とは呼ばない。

必要に応じて[確認用の事例](references/scenarios.md)を参照する。設計の由来は[参考資料と取り入れた考え方](references/design.md)に記す。