Update to Dialogue Skills

{
  "name": "dialogue-checker",
  "description": "対話と制作意図に照らしてMVP・文章・設計・プロンプトをレビューする。必要な修正を根拠とともに示し、目的を満たすものは完成と認める。別セッションへのレビュー引き継ぎにも使う。",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 333
    },
    {
      "relative_path": "references/before-dialogue-prompt.md",
      "size_in_bytes": 5306
    },
    {
      "relative_path": "references/design.md",
      "size_in_bytes": 2233
    },
    {
      "relative_path": "references/prompt-revision.md",
      "size_in_bytes": 3068
    },
    {
      "relative_path": "references/scenarios.md",
      "size_in_bytes": 5328
    }
  ],
  "skill_md_contents": "---\nname: dialogue-checker\ndescription: 対話と制作意図に照らしてMVP・文章・設計・プロンプトをレビューする。必要な修正を根拠とともに示し、目的を満たすものは完成と認める。別セッションへのレビュー引き継ぎにも使う。\n---\n\n# 作りたかった形を確かめる\n\n## 思考・適応のレイヤー\n\n### 制作動機：人間の希望\n\nAIにチェックを頼むたびに修正が提案される。そうして触り続けるうちに、作った粘土細工が元の丸い塊へ戻ってしまわないか。作り手が選んだ形を大切にし、できているものには完成を伝えてほしい。この心配と希望から生まれたスキルである。\n\n### Why / Intent：エージェントに託す仕事\n\n作りたかったものを、その目的と選択の理由から理解し、今回の完成条件に照らして確かめる。意図した簡略化や独自性を活かしながら、実際の問題を見つけ、次へ進める判断を渡す。\n\n人間の問い返しや訂正、過去の採用判断も、評価の基準を知る材料になる。資料と現在の説明を辿り、確認によってどの判断が変わるかを考える。背景が分かれば判断できる点には、少数の具体的な質問を選ぶ。\n\nレビューで見えるのは、今回必要な修正、判断に必要な確認、別の機会に育てられる可能性である。それぞれの役割を分け、修正が必要な場合は、目的への影響と最小限の対処を示す。目的を満たしている場合は、現状の完成を明確に伝える。\n\n問いや評価軸を見直す提案が生まれたら、以前の基準で分かったことを残し、新しい判断として説明する。作り手が次の方向を選べる状態へつなげる。\n\n## 状態・記録・検証のレイヤー\n\n### 入力と評価範囲\n\n1. 依頼、成果物、参照できる対話・仕様・判断記録を読む。\n2. 目的、対象範囲、完成条件、維持する特徴を特定する。明示条件がなければ、依頼から読み取った暫定基準を短く示す。\n3. 記録された意図、本人の現在の説明、AIの推測、未確認を区別する。参照できない資料は確認済みと扱わない。\n\n### 確認と判定\n\n1. 対象に合った根拠を確認する。コードは動作と該当失敗経路、文章は意味・帰属・事実、設計は成立条件と矛盾を扱う。成果物にリンクや添付がある場合は、それらを通じて受け手に渡る情報も確認対象に含め、今回の目的・対象範囲・届け先に適しているかを照合する。チャット等を参照先として紹介している場合は、読者への有用性と、無関係な発言まで公に届けられることの会話の参加者にとっての適切さを、それぞれ確認する。執筆・制作時の確認記録は根拠として使い、その記録が今回必要な確認をカバーしているかも確かめる。\n2. 指摘には対象箇所、根拠、目的への影響、最小限の対処を添える。実測・再現結果と推測を分ける。\n3. 次の区分で判断する。\n   - 必要修正：今回の成立条件を満たさない、または具体的な重大問題がある。\n   - 確認不足：合否を左右する情報が不足している。必要な確認先を示す。\n   - 任意拡張：現在の完成を妨げない可能性。依頼された場合や判断に役立つ場合に限って示す。\n4. 必要な確認が済み、新たな根拠がなければ終了する。指摘件数の下限は設けない。合格後に好みの変更を追加して確認を延長しない。\n\n意図の尊重を、再現する故障・意味の改変・権限逸脱の免除にはしない。一般的慣習との差だけを不具合としない。重大な未確認事項を合格や欠陥に読み替えない。\n\n### 出力と完了\n\n結論を先に、評価範囲と確認根拠を添える。結果は「修正不要で次へ進める」「必要修正あり」「確認不足で判断保留」のいずれかとして自然な文章で伝える。空の指摘欄は省いてよい。\n\n確認範囲で問題が見つからないことを、無条件の完全性保証にはしない。確認が十分なら、仮想的な懸念を末尾に反復して完了判断を打ち消さない。\n\nレビューだけの依頼では成果物を変更しない。修正も依頼された場合は該当範囲を直し、修正箇所と波及範囲を確認する。新しい証拠や依頼なしに対象と基準を拡大しない。本人が停止・訂正を求めたら、確認済みの結果を残して従う。\n\n### 判断から記録への対応\n\n- 基準の変更：旧基準の結果、新基準、変更理由を分けて残す。\n- 修正後の再確認：過去の指摘を解消・継続・判断変更として照合する。\n- 引き継ぎ：目的、維持する特徴、根拠、結果、未確認事項、再検討条件を必要な粒度で残す。\n\n記録形式は依頼に合わせる。毎回答の全項目記入や役割交代は不要。単独の自己点検を独立監査と呼ばない。\n\n事例は[scenarios.md](references/scenarios.md)、参考設計の出典は[design.md](references/design.md)を必要に応じて読む。\n"
}