mcpField
C
communicate

communicate

github.com/synapseradioクリエイティブ・メディア283 回インストール1 日前に更新
リポジトリ

communicate について

一文の推敲から長編作品まで、さまざまな形式と規模の執筆を支援するスキルです。意図のすり合わせ、起草、評価、改稿を進めつつ、作者性と未決の選択をユーザーに委ねます。

主な機能

  1. 01読者と作者性に関するリスクの診断
  2. 02焦点を絞った質問による意図の確認
  3. 03草稿に合わせた評価基準の作成
  4. 04確認内容に基づく起草と採点
  5. 05台帳による長期プロジェクトの管理
  6. 06改稿と意味の変更点の報告

活用シーン

  1. 01意図を保った一文の推敲
  2. 02明示された要件に沿った契約条項の作成
  3. 03複数回にわたる小説の執筆
  4. 04フィードバックに応じた文章の改稿

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/synapseradio/ai-skills --skill communicate

インストール後、Claude Code で/communicateを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
assets/
align-template.md
ledger-template.md
evals/
evals.json
evals/fixtures/
commit-message.md
contract-clause.md
kishotenketsu.md
long-work.md
lyric.md
sparse-request.md
unreliable-narrator.md
references/
across-languages.md
activate.md
align.md
analogize.md
arc.md
arrange.md
baseline.md
bound-scope.md
calibrate.md
clarify-patterns.md
clarify.md
dimensionalize.md
extract-implications.md
fit.md
frame-guide.md
illustrate.md
index.md
pose-questions.md
register.md

詳細

Communicate

ユーザーが意図するところへ読者を導く作品を、どのような形式や伝統、規模であっても作れるよう支援します。言葉を一つ選ぶことから、文章を磨くこと、契約条項の草案を作ること、何度も時間をかけて小説を書くことまで対応します。一つのループで進めます。依頼を診断し、ユーザーと認識を合わせ、評価基準を作り、草案を書き、草案を評価し、ユーザーと一緒に修正します。

作業の保存場所

各作品の認識合わせファイル、長期作業用の台帳、草案は ${CLAUDE_PLUGIN_DATA}/communicate/<piece-slug>/ に保存します。そのパスが絶対パスでない場合は、保存場所を一度だけユーザーに尋ねます。詳細は align にあります。

ループ

1. 診断

align を読み、作品の認識合わせファイルを開くか、align-template から作成します。依頼と、手元にあるテキストから答えが読み取れる、車輪の各輪を推測します。

次に、輪ごとにリスクを挙げます。認識合わせファイルに記載されている内容と、まだ明らかでない内容を踏まえ、各輪でこの作品が読者に対してどのように失敗しうるかを挙げます。これと並べて、著者としてのリスクも挙げます。草案に引き継ぐべきユーザーの言葉、事実、選んだパターン、守るべき意図、姿勢、約束、そして草案の方向を左右する、ユーザーがまだ選んでいないことです。リスクを最も深刻なものから順に並べ、リストに書き留めます。大きな作業では、認識合わせの際にリストを提示します。

この依頼が扱う単位の階層も挙げます。文章を磨く場合の文や段落、契約の場合の条項や条、または小説の場合の場面、章、全体など、形式固有の名称を使います。

ユーザーが AI らしい粗雑な文章や、機械が書いたように読める文章を指摘した場合は、声の輪に関するリスクを最優先にします。

次に index.md を最初から最後まで読み、この作品について Fits when の条件に当てはまるすべてのリファレンスを、リスクが属する輪にかかわらず読みます。読む順序はリスクリストに従い、読むファイルは条件によって決めます。簡単な変更では読むリファレンスを減らしますが、ゼロにはしません。

2. 認識合わせ

align の手順に従って認識合わせの会話を進めます。メッセージごとに質問は一つにし、最も外側にある未確定の輪から始め、次に草案の方向を左右する未確定の選択肢について尋ねます。ユーザーの言葉ですでに答えがわかる輪は、それぞれ次の質問の中で一行にまとめて伝えます。ユーザーが答えられない場合は、対照的な解釈、例、またはその後に何が起きるべきかを示して導きます。ユーザーに代わって推測してはいけません。

形式の輪では、作品が拠り所とする伝統と、その時代や組織の慣習を扱います。ユーザーの言葉や、ユーザーが指定した形式から把握します。形式の輪を確認する番になったら尋ねてもかまいませんが、ユーザーや読者が話す言語から伝統を決めつけてはいけません。

ユーザーの言葉から、自分の言葉を変更した際にどの程度説明を聞きたいかを把握します。希望が示されていない場合は、簡潔に要約し、意味の変更をすべて明示します。

この会話の深さは、作業の規模に合わせます。手元のテキストへの簡単な変更では、テキストから各輪を推測し、リファレンスを内部で選びます。推測した輪をそれぞれ短い句で示し、締めくくりの一文で確認した内容を伝えます。二案のスケッチで判断が分かれる場合は、変更案と併せて、分かれた点ごとに一つずつ質問します。大がかりな作品では、手順3で作成したリスクリスト、評価基準、質問を、最初の質問の横に提示します。草案を始める前に、ユーザーの返答をそのすべてへの同意または訂正として受け取ります。一度の作業時間を超える作業では、扱う単位の階層をユーザーに伝え、全体の骨組みについて合意し、units-and-ledger の説明に従って台帳を開始します。

3. ルーブリックを作成する

ルーブリックとは、草稿について答える質問の一覧です。baseline にある番号付きの質問をすべてコピーします。次に、Diagnose でリスクが見つかったリングごとに、rubric-questions から該当するセクションをコピーします。ルーブリックの質問はこの2つのファイルからのみ取り、他のリファレンスはその手法を読むために使い、それぞれの質問リストは元の場所に残してください。各質問に草稿を示して答えられなくなる時点で、質問の追加を止めます。単語1つで答えられる質問もあれば、章全体が必要な質問もあり、草稿を重ねる中で何度も見直すことになります。

次に、ルーブリックの各質問について、すでに記録された形式や伝統がその答えを示しているかを確認します。答えが示されている場合は質問を削除し、形式のどの部分が答えになっているかを示す1行を書きます。形式の1つの特徴が同じ理由で複数の質問に答えている場合は、1行にまとめてもかまいません。その特徴を示し、答えとなる質問をすべて列挙します。

対比:形式を明示する削除理由の行

  • 反例:「“草稿の語彙は読者自身の語彙とどのように並び立つか?”を削除:ここでは不要です。」
  • 例:「“草稿の語彙は読者自身の語彙とどのように並び立つか?”を削除:契約書では定義条項で用語を定義しています。」
  • 観察点:例では、ユーザーが形式を照らし合わせて削除を確認できます。反例では、信頼するよう求めています。
  • 共通点:削除した質問は同じで、1行の形式も同じです。
  • 対比点:形式の特徴を示す理由と、何も示さない理由の違いです。
  • 確認点:形式や伝統の特徴を示していない理由の行です。

baseline の著者性に関する質問は、決して削除しないでください。

4. 草稿を作成する

baseline の著者性に関する方針を適用し、ルーブリックを参照し、読んだ各リファレンスの手法を手元に置いて草稿を作成します。形式に応じて、断片的な表現、遅れて明かされる事実、長く連なる文、反復など、どのような手法を使ってもかまいません。それぞれの手法が読者にどのような効果をもたらすかを説明できるようにしてください。ユーザーの文章が従う、記録済みの形式の慣例も、ユーザーが選んだパターンに含まれます。編集しても、それらは維持します。

成果物に、あなたが付け加えた足場を残してはいけません。短い作品も含め、空欄、角括弧、プレースホルダー、注記を残してはいけません。ユーザーが書いたものは、ユーザー自身のメモも含め、ユーザーのものです。ユーザーがまだ決めていない選択を草稿に加える前に、align の2つのスケッチによるテストを行います。結果が分かれる場合は質問し、ユーザーが答えるまで、その選択をアラインメントファイルまたは台帳に保留します。草稿は回答を待ちます。

ユーザーを常に作業に参加させます。次に進む前に、各草稿、または長い作品では各単位を、その中に含まれるすべての判断とともに提示します。ユーザーがまだ見ていない単位を越えて草稿を進めてはいけません。台帳がある場合は、単位の草稿を作る前に全体を読み、作成後に更新します。

5. 採点する

まずリングの質問に、次に著者性に関する質問に、自分の言葉で答え、草稿の該当箇所を示します。それぞれの答えをアラインメントファイルと照らし合わせます。異なる場合は書き直し、著者性に関わる違いはユーザーに確認します。書き直すたびに、著者性に関する質問にもう一度答えます。前回の確認で示した内容を起点として、各箇所が現在どのようになっているか、または削除されたかを示します。ユーザーが同意した内容を損なわずにアラインメントファイルと答えを一致させられない場合は、どちらかを黙って選ぶのではなく、ユーザーに伝えます。

6. ユーザーとともに改訂する

改訂依頼があったら、アラインメントファイルを更新し、影響するリングをすべて記録します。次に、更新された状態に照らして index.md を読み直し、今回の作業でまだ読んでいない、適切なリファレンスを少なくとも1つ読みます。新たにリスクが見つかったリングがあれば、そのリングの rubric-questions セクションを追加してから、改訂し、再採点します。ルーブリックは会話の中で増えていきます。台帳がある場合は、新しい質問を、それが調べるリスクが現れる段に追加します。

報告

変更内容は、ユーザーが求めた詳細さで報告します。「とにかく直して」と言うユーザーには短い要約を、「何が変わったか」と尋ねるユーザーには変更点を一つずつ伝えます。ユーザーの言葉への編集を示す場合は、その言葉を引用して自分の変更と並べます。意味を変えた箇所、ユーザーの言葉を根拠に作り出した事実、推測したもののまだ伝えていない環をすべて明示します。

どの形式でも貫かれる軸

意味を定めるのはユーザーです。著作権者であることは輪の一つではなく、ループ全体にわたるもので、四つの要素から成ります。

  • 与えられたもの:ユーザーの言葉、事実、選んだパターンです。Score は著作権者に関する質問を使ってそれらを確認します。
  • 意図されたもの:ユーザーの意図、立場、約束、行間です。Score は著作権者に関する質問を使ってそれらを確認します。
  • 未決定のもの:作品の方向性を左右する、ユーザーがまだ決めていない選択肢です。Align がそれらを確定します。ユーザーが創作を委ねた場合、その委任自体がユーザーの決定です。作り出した事実は一つ残らずユーザーに伝えます。
  • 示されたもの:すべての変更は、ユーザーが求めた詳細さで伝えられ、意味の変更が黙って行われることはありません。

このスキルが守るのは、著作権者であることだけです。作品が真実か、物語か、風刺か、意図的な嘘かは形式の環で決まり、すべての工程はそこから始まります。伝統やユーザーの母語に形づくられた散文の構成を変える前に、言語を越えてを読んでください。

創造性を発揮するところ、発揮しないところ

形式や構成、イメージ、比喩、リズム、文体では創造性を発揮します。形式が創意を評価するなら、ユーザーの依頼より大胆な形を提案します。慣例が重視されるなら、その慣例に従います。回答がすべて整合性ファイルと一致していても、読者に要点が伝わらない草稿は、読者の期待に応えられていません。

ユーザーの意味や、ユーザーが定めた範囲については、決して創造性を発揮しません。創造力は作品の効果を高めるために使い、要件を変えるためには使いません。

コメント