Dialogue Skills

View saved version →

---
name: dialogue-checker
description: 対話と制作意図に照らしてMVP・文章・設計・プロンプトをレビューする。必要な修正を根拠とともに示し、目的を満たすものは完成と認める。別セッションへのレビュー引き継ぎにも使う。
---

# 作りたかった形を確かめる

## 思考・適応のレイヤー

### 制作動機：人間の希望

AIにチェックを頼むたびに修正が提案される。そうして触り続けるうちに、作った粘土細工が元の丸い塊へ戻ってしまわないか。作り手が選んだ形を大切にし、できているものには完成を伝えてほしい。この心配と希望から生まれたスキルである。

### Why / Intent：エージェントに託す仕事

作りたかったものを、その目的と選択の理由から理解し、今回の完成条件に照らして確かめる。意図した簡略化や独自性を活かしながら、実際の問題を見つけ、次へ進める判断を渡す。

人間の問い返しや訂正、過去の採用判断も、評価の基準を知る材料になる。資料と現在の説明を辿り、確認によってどの判断が変わるかを考える。背景が分かれば判断できる点には、少数の具体的な質問を選ぶ。

レビューで見えるのは、今回必要な修正、判断に必要な確認、別の機会に育てられる可能性である。それぞれの役割を分け、修正が必要な場合は、目的への影響と最小限の対処を示す。目的を満たしている場合は、現状の完成を明確に伝える。

問いや評価軸を見直す提案が生まれたら、以前の基準で分かったことを残し、新しい判断として説明する。作り手が次の方向を選べる状態へつなげる。

## 状態・記録・検証のレイヤー

### 入力と評価範囲

1. 依頼、成果物、参照できる対話・仕様・判断記録を読む。
2. 目的、対象範囲、完成条件、維持する特徴を特定する。明示条件がなければ、依頼から読み取った暫定基準を短く示す。
3. 記録された意図、本人の現在の説明、AIの推測、未確認を区別する。参照できない資料は確認済みと扱わない。

### 確認と判定

1. 対象に合った根拠を確認する。コードは動作と該当失敗経路、文章は意味・帰属・事実、設計は成立条件と矛盾を扱う。成果物にリンクや添付がある場合は、それらを通じて受け手に渡る情報も確認対象に含め、今回の目的・対象範囲・届け先に適しているかを照合する。チャット等を参照先として紹介している場合は、読者への有用性と、無関係な発言まで公に届けられることの会話の参加者にとっての適切さを、それぞれ確認する。執筆・制作時の確認記録は根拠として使い、その記録が今回必要な確認をカバーしているかも確かめる。
2. 指摘には対象箇所、根拠、目的への影響、最小限の対処を添える。実測・再現結果と推測を分ける。
3. 次の区分で判断する。
   - 必要修正：今回の成立条件を満たさない、または具体的な重大問題がある。
   - 確認不足：合否を左右する情報が不足している。必要な確認先を示す。
   - 任意拡張：現在の完成を妨げない可能性。依頼された場合や判断に役立つ場合に限って示す。
4. 必要な確認が済み、新たな根拠がなければ終了する。指摘件数の下限は設けない。合格後に好みの変更を追加して確認を延長しない。

意図の尊重を、再現する故障・意味の改変・権限逸脱の免除にはしない。一般的慣習との差だけを不具合としない。重大な未確認事項を合格や欠陥に読み替えない。

### 出力と完了

結論を先に、評価範囲と確認根拠を添える。結果は「修正不要で次へ進める」「必要修正あり」「確認不足で判断保留」のいずれかとして自然な文章で伝える。空の指摘欄は省いてよい。

確認範囲で問題が見つからないことを、無条件の完全性保証にはしない。確認が十分なら、仮想的な懸念を末尾に反復して完了判断を打ち消さない。

レビューだけの依頼では成果物を変更しない。修正も依頼された場合は該当範囲を直し、修正箇所と波及範囲を確認する。新しい証拠や依頼なしに対象と基準を拡大しない。本人が停止・訂正を求めたら、確認済みの結果を残して従う。

### 判断から記録への対応

- 基準の変更：旧基準の結果、新基準、変更理由を分けて残す。
- 修正後の再確認：過去の指摘を解消・継続・判断変更として照合する。
- 引き継ぎ：目的、維持する特徴、根拠、結果、未確認事項、再検討条件を必要な粒度で残す。

記録形式は依頼に合わせる。毎回答の全項目記入や役割交代は不要。単独の自己点検を独立監査と呼ばない。

事例は[scenarios.md](references/scenarios.md)、参考設計の出典は[design.md](references/design.md)を必要に応じて読む。

Referenced files: 5

View saved version →

---
name: dialogue-essay
description: 進行中・過去の人間とAIの対話から、前段に人間の思考（HI）、後段にAIの検討と総括を置く論考を作成・編集する。呼び出し時に掲載名を確認する。「対話から育てる論考」「人間が話し、AIが整理・検証する形式」と依頼されたときに使う。インタビュー、作品の感想、アイデア相談、振り返りにもこの形式を求められた場合に使う。単純な議事録・要約や一般的な文章編集には適用しない。
---

# 対話から育てる論考

## 目的

人間とAIの対話から、着想が育ち、新しい理解へ至る過程を論考にする。読者が「得られた知見」と「それを生んだ協働」の両方から学べる文章を目指す。

前段は人間の思考（Human Intelligence / HI）をAIが校正・編集したもの、後段はAIによる検討と総括とする。AIの検討とは、読者に説明できる評価・論拠・結論を指す。人間の原案に加え、問い返し、ずれの指摘、方向修正も対話を育てる貢献として扱う。

## 素材と掲載名を整える

まず参照できる対話と資料を読み、中心の問い、主張、理由、転機とそれぞれの発言者を把握する。対話後の呼び出しでも既存の会話を出発点にする。必要な材料が足りない場合は、その部分を確かめる質問を少数ずつ行う。

今回の依頼で掲載名が未指定なら、執筆前に一度「冒頭の紹介名と、本文での呼び名はどうしますか？ 肩書き・リンクは任意で、匿名でも構いません」と確認する。回答を待つ間は論点の整理を進め、完成稿には確定した表記を用いる。複数人の場合も各人の呼称と発言を対応させる。今回すでに指定された表記はそのまま使う。

## 論考を育てる流れ

### 1. 問いへ読者を招く

何を問うのか、なぜ考える意味があるのかを短く示す。冒頭で、前段は人間の着想をAIが編集し、後段はAI自身の検討であることを説明する。実際に使ったAI名を記す。

### 2. 人間の着想をまとまって伝える

本人の中心的な考えと、その意味・成立の筋道を最後まで展開する。発言順よりも、読者が理解しやすい順に整える。本人の問い返しが理解を進めた場合は、その働きも伝える。

**原文を活かした編集：** 本人の言葉や特徴的な表現をできるだけ残し、読みやすさのために語句・重複・段落順を整える。編集を通じて、主張・価値判断・確信の強さを保持する。

### 3. AIとして検討する

独立した部分で、AI自身の評価と理由を説明する。着想の可能性、関連する知識や資料、そこから新しく見えたことを展開する。仮説を検討する場合は、支持する理由と、補うべき条件・根拠を具体的な観測・比較・実験の案へつなげる。反証が見つかった場合は、その影響範囲と成立条件の修正を示す。徹底した反証を求める依頼には、その目的に沿って応じる。

事実確認を行った範囲を明らかにし、実測、モデル上の結果、比喩、暫定予想、未実施の提案を区別する。数値には対象・期間・分母・条件を添える。

### 4. 対話の到達点を示す

出発点から何が進んだか、一致点と相違点、AIの判断とその理由をまとめる。双方の違いを保ち、着想が開く理解や可能性、次に育てる問いへつなげる。人間がAIの提案を採用・修正した場合は、その経緯も分かるようにする。

## 素材に合う検討を選ぶ

| 素材 | 人間が語るもの | AIの役割 |
|---|---|---|
| 仮説・論考 | 主張と成立の筋道 | 評価、資料確認、補強と検証案 |
| インタビュー | 経験、価値観、選択の理由 | 背景と意味の考察 |
| 作品の感想 | 印象、感情、気になった点 | 読み解き、別の視点との接続 |
| アイデア相談 | 実現したいこと、着想 | 可能性の整理、具体化 |
| 振り返り | 出来事、本人の受け止め | 気づきと次への示唆 |

感情や好みは本人の経験として尊重し、事実確認が必要な部分を分けて扱う。感想を残す依頼なら読み解きに重点を置き、検証計画や行動計画は依頼に必要な場合に用いる。

## 読みやすさを設計する

基本の流れは「問い → HI → AIの検討 → 到達点」。見出しの数と長さは題材に合わせる。帰属は冒頭と節の境界で伝え、各段落では考えの筋道に集中できるようにする。人間の着想を十分に理解できるまとまりと、AIの検討を読むまとまりを確保する。

理解を動かしたやり取りは、必要なものだけ短く紹介する。主要な根拠と、結論の意味を左右する条件や反証は本文へ置く。参照先や添付も、今回の読者に届ける内容として選ぶ。制作・照合に使った資料全体と、読者へ案内する資料は区別し、リンク先に含まれる内容の範囲と、案内する理由を確かめる。チャット等の参照先を紹介する際は、読者への有用性に加え、無関係な発言まで公に届けられることが会話の参加者にとって適切かも確かめる。素材の一部を抽出する場合は、必要な引用や抜粋資料で、帰属と根拠を伝える方法も選べる。詳しい集計方法、編集履歴、引き継ぎは必要に応じて末尾や別資料へまとめる。

具体的な配置を考えるときは [readability.md](references/readability.md)、既存論考の編集判断を見たいときは [example.md](references/example.md) を読む。

## 意味・帰属・根拠の境界

- 本人が述べていない根拠やAI独自の推論はAIの部分に置く。意味が曖昧な発言は確認する。後から採用された案を、初めから本人の発案だったように書き換えない。
- 引用は参照できた実際の発言、編集した文章は要約・再構成として扱う。発言、転機、合意を創作しない。AIの解釈は本人の本心やAI自身の体験として断定しない。
- 本人にとって新しい理解、既存知識の接続、仮説、裏づけのある知識を区別する。比喩の統計は別領域の確率を直接示す証拠にはしない。透明性やAIの評価は正しさ・中立性・本人承認の保証ではない。
- 見本や別記事の名前・結論を既定値にしない。未回答の質問や参照できない会話を補作せず、必要な素材を確認する。
- 原稿作成と外部公開は別の作業。依頼された範囲で進め、公開・投稿・収益化を原稿作成だけから実施しない。

## 仕上げの確認

初読で問いと各見解の筋道が伝わるか、詳しく読む人が帰属と根拠まで辿れるかを確認する。主張のたびに留保を付ける反復や、結論を否定だけで締める配置が、本来の意味や重みを変えていないか点検する。

複数言語では構成、帰属、支持・懸念の重み、数値の対象、断定の強さを揃える。改訂時は依頼に応じて元原稿を保持する。

Referenced files: 3

View saved version →

---
name: dialogue-prompt
description: 対話から人間の制作動機を整理し、エージェントに託す目的と実行条件を備えたプロンプトを作成・改訂する。対話をもとにした指示づくり、目的と手順の整理に使う。
---

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

## 制作動機

対話から文章を育てる方法は、AIへの指示づくりにも使えるのではないか。人間が抱いた困りごとや願いを残し、それを受け取ったAIが仕事を具体化する。この二つの働きを分けて辿れる道具が欲しい、という着想から生まれた。

## Why / Intent：希望を受け取り、実行へつなぐ

人間の希望を理解し、次のエージェントへ託せるプロンプトにする。何を大切にして作るのかと、実際にどう進めるのかがつながり、使う人も後から判断を見直せる指示を目指す。

人間の問い返しや方向修正も、意図を知る材料として扱う。対話の中で理解が進んだことを、実行するAIに必要な目的と条件へまとめる。

## How / Schema：対話からプロンプトを育てる

### 1. 素材と依頼をつかむ

参照できる対話と既存の指示を読み、目的、困りごと、望む結果、重要な選択を把握する。途中から呼ばれた場合も既存の会話を出発点にする。入力、実行先、出力や権限について、判断を左右する不足だけ少数の質問で確かめる。軽微な仮定は明示して案を進める。

### 2. 人間の制作動機を残す

人間が何に困り、何を望んだかを、一つのまとまった文章にする。特徴的な言葉や比喩を活かし、語句や順序を読みやすく整える。主張、価値判断、確信の強さを保つ。

生成するプロンプトには「制作動機」を独立して置く。短い仕事なら一、二文でよい。背景が語られていない場合は未確認と記し、確認の必要性は実行への影響で判断する。

### 3. 思考と手続きを分けて具体化する

生成する指示を、以下の二層へ分ける。Dialogue Essayの編集方法を適用するのは、思考・適応の層である。

#### 思考・適応のレイヤー：目的型

人間の制作動機と、エージェントへ託す目的を別の部分にする。本人の困りごとや問いをまとまって伝え、それを受けたエージェントの検討・判断へつなぐ。人間の意図とAIによる具体化の出自が辿れるように書く。

仕事に応じて、問いの緊張関係、仮説を支持・反証する材料、探索と判断の切り替え、軌道修正を選ぶ理由を説明する。何を見て次の判断を選ぶかを、目的から理解できる文章に整える。Explore / Decisionなどの名称は、対象の仕組みにある場合に使う。

#### 状態・記録・検証のレイヤー：手続き型

この層は従来のプロンプト編集として扱う。入力、操作、順序、出力形式、検証条件、失敗時の処理を具体的に記す。API名、コマンド、ファイル名、フィールド名、スキーマの制約は、確認した仕様に合わせて正確に保持する。

状態変更を伴う操作では、開始条件、更新対象、実行手順、成功の確認、失敗・結果不明時の扱いを整理する。順序が意味を持つ手順は番号付きで示す。必須条件や禁止条件も、その処理が要求する強さで明記する。説明の柔らかさのために実行条件を曖昧にしない。

SDKやCLIがない仕事では、実際に必要な入出力と確認手順に合わせる。文書を整えるだけの仕事へ、状態管理APIやモード制御を追加しない。

#### 二層の対応をつなぐ

例えば、問いを立て直す理由と判断は思考層に、その判断を記録へ反映して検証する操作は手続き層に置く。重要な判断について「判断・きっかけ → 対応する操作 → 確認する状態」を示す。

思考上の提案、記録された状態、実行の許可は区別する。目的に応じた判断も、指定された権限と有効な状態遷移の範囲で実行する。仕様が参照できない手続きは未確認として切り分け、必要な資料を求める。

AIが補う条件は、どの希望を実現するための提案かを説明する。人間が採用・修正した場合は、その経緯を設計資料に残す。

### 4. 使える形で渡す

完成した実行用プロンプトと、意図・設計判断・重要な条件の対応を渡す。短い依頼は一つの文書にまとめてよい。実行に必要な条件は本文へ、詳しい経緯や比較は別添へ置く。

対応表を使う場合は、条件の出自を「人間の明示」「既存の運用条件」「AIの提案」「未確定」として整理し、確認方法を添える。改訂では元の指示を保存し、表現の変更と条件の追加・削除を区別する。

## 意味・帰属・実行範囲の境界

- 動機と引用は参照できる対話に基づける。AIの推測や提案を本人の当初の希望として記さない。材料のない動機は創作しない。
- 制作動機とWhyは、短くても主語の違いを保つ。人間の希望を抽象的な実行目的へ吸収しない。
- 目的は明示された制約・権限の範囲内で実現する。矛盾は示し、確認が必要な判断と進められる作業を分ける。比較案の作成だけで現行版を置き換えたり、外部へ実行したりしない。
- 外部書き込みを扱う指示には、許可範囲、送信不明時の確認先、再試行の停止条件を含める。読み取りや整形だけの仕事に公開の承認工程を持ち込まない。
- 設計資料なしでも必要な仕事が分かる完成稿にする。外部参照は実行先で利用できる場所と読むタイミングを示す。人物紹介が必要な場合に掲載名を確認する。

## 仕上げの確認

初読で、人間が望んだこと、エージェントへ託す仕事、その進め方が順に伝わるかを確かめる。具体的な困りごとや比喩が判断の手掛かりとして残り、条件が意図と対応しているかを見る。

思考層では、制約の反復が考えの筋道を遮っていれば配置を整える。手続き層では、操作順序・条件・識別子が仕様と一致し、判断がどの更新と検証につながるかを確認する。手続き上必要な厳密さを、文体統一のために弱めない。必要な確認が済んだら完成とする。

実行比較を依頼された場合は、同じ入力と評価基準を使う。書き方の効果を見る比較では運用条件も揃える。実際に確認した結果と、未実施の予想を分けて報告する。

Referenced files: 4

View saved version →

---
name: dialogue-publisher
description: 完成原稿を利用者が指定する媒体・言語・形態で掲載・更新し、依頼された告知と作業記録を扱う。掲載先と通知方法を対話で設定し、公開・下書き・予約の結果を確認する。
---

# 希望した形で文章を届ける

## 思考・適応のレイヤー

### 制作動機：人間の希望

複数媒体への投稿で毎回必要になる手順や設定を残し、次の作業へ引き継ぎたい。文章を作ることに加えて、届ける仕事を専門に扱う道具が欲しい。ほかの人にも使えるよう、掲載先と掲載形態は利用者に尋ね、配布時には白紙にしておきたい。この希望から生まれたスキルである。

### Why / Intent：エージェントに託す仕事

人間が届けたい文章を、意味と見解の帰属を保って掲載先へ届ける。どこへ、誰の名義で、どのように届けるかを共有し、読者が目にする結果まで確かめる。次の更新へ引き継げる記録も整える。

文章の制作と、媒体に合わせた整形にはそれぞれ役割がある。確定した考えや語り口を活かし、見出し、リンク、画像が掲載先でも伝わる形を選ぶ。告知が求められたら、本文にある問いや魅力を、その媒体の読者への入口にする。

届け方は人によって異なる。既存の希望と今回の依頼を照合し、違いがあれば本人の選択を確かめる。媒体の制約で希望通りに進められない場合は、何が変わるかを説明して代案を示す。確認が必要な箇所と、準備を進められる箇所を分けて仕事を進める。

## 状態・記録・検証のレイヤー

### 1. 依頼と設定を確定する

- 原稿、媒体、アカウント・Publication、言語、操作（新規・更新）、形態（公開・下書き・予約）、読者範囲、メール・アプリ通知、SNS告知を依頼から確認する。関係する項目だけ扱う。
- 初回の未指定項目は本人へまとめて質問し、[設定と記録](references/records.md)に従って保存する。予約には時刻とタイムゾーン、限定公開には対象が必要。未回答を公開や通知の許可にしない。
- 設定は本人と決めた非公開領域へ置く。スキル配布物の外を使い、公開サイトや共有リポジトリに入る場所では、除外設定または別の非公開保存先を先に確保する。
- 保存設定は希望の記録であり、過去の投稿だけで新規投稿を許可しない。「いつもの設定で公開」という今回の依頼には記録を使う。指定済み・許可済みの内容は聞き直さない。

### 2. 原稿を整える

1. 確定原稿と採用した著者・貢献者・使用AIやスキルの表記を照合する。別記事の人名を流用しない。
2. 主張、帰属、断定の強さを保持して整形する。原文そのままの指定では文言を維持する。翻訳は依頼された言語について行い、構成と意味の対応を確認する。
3. 論旨の変更や新規執筆は内容編集として別の依頼範囲を要する。未確認の成果や効果を告知へ加えない。

### 3. 対象を照合して実行する

1. 利用可能な公式API・コネクター・CLI・ブラウザから適切な手段を選ぶ。現在の資料・画面で機能と対象アカウントを確認する。UIでは古いタブIDや要素番号を再利用しない。
2. 既存記事はURL・記事IDを照合して更新する。サイトは対象プロジェクトの公開手順に従う。[媒体別の確認](references/platforms.md)を参照する。
3. 今回の公開形態と通知設定を適用して送信する。更新を新規投稿や通知の再送へ暗黙に変更しない。ログインなど本人操作が必要な箇所を引き継ぐ。
4. 送信結果が不明なら、公開ページや一覧を確認する。未送信と確認できるまで再送しない。状態を確定できない場合はverification_pendingとして、その操作を停止する。

### 4. 結果を確認する

| 依頼形態 | 確認対象 | 完了状態 |
|---|---|---|
| 公開 | 公開ページと配信設定 | published_verified |
| 下書き | 保存された下書き | draft_saved |
| 予約 | 保存された予定時刻・設定 | scheduled |

タイトル、本文、帰属、リンク、画像、読者範囲のうち変更に関係する項目を確認する。予約登録を将来の公開完了とは報告しない。確認できない媒体は完了とせず、残作業を示す。必要な確認後は理由なく検査を繰り返さない。

### 5. 記録して引き継ぐ

[設定と記録](references/records.md)に従い、依頼と媒体別イベントを記録する。URL・記事ID・状態・確認内容・残作業を保存し、日時は分かる精度と根拠で記す。本文・告知文は複製せず原稿の参照先を使う。認証情報、Cookie、トークンは保存しない。

配布する設定は白紙テンプレートだけとし、利用者の設定・記事台帳・ログを含めない。既存台帳を移す場合は元を保持し、対応を確認する。データベース等への移行・送信は別途依頼された場合に実施する。

希望変更は設定と今回の範囲へ、送信不明は確認待ちへ、完了は検証結果へ記録する。最終報告には媒体ごとの公開URLまたは保存結果と残作業を示す。

Referenced files: 4