Coldread

---
name: coldread
description: 外部向け文章(issue・PR 本文・コメント等)を、coldreader(文脈ゼロの読み手)に初見検査させてから出す。gh への投稿が投稿ゲート(このプラグイン同梱のフックが coldreader を自動で走らせる)に止められたときと、メール・チャットなど投稿以外の文章を手で検査したいときに使う。
---

# 冷読チェック

外部へ出す文章を、書き手の文脈を持たない読み手(coldreader)に読ませ、詰まった事実を集めて直す。
書き手は全文脈を持つため「読者が持っていない前提」を自己評価では検出できない。
評価器と被験者を分離することがこの手順の目的である。

「冷読」はこのプラグインの自作語で、読み手の役は **coldreader** の名で呼ぶ。英語の
cold reading は演劇の初見読み上げ・占い師の話術を指す別の語(文書の初見検査の慣用は
fresh eyes / first-time reader)。外部向け文書では毎回説明を書くより coldreader の名で指し、
初出にだけ短い注(文脈ゼロの読み手)を添えること。

## ゲートに止められたとき(gh への投稿)

gh への投稿は、同梱のフックが coldreader を自動で走らせる。deny メッセージに coldreader の
「詰まり」がそのまま載っているので:

1. **直す前に、読み手が何を見ているかを確かめる。** 既に在る PR/issue のスレッドへの返信なら、
   coldreader はフックが取った画面(題・番号・状態・本文・変更ファイル・file と行・元の指摘・
   これまでの返信・参照する番号の題)を見た上で読んでいる。画面に有るもの——PR 番号・リポジトリ名・
   相手の名前・相手が付けた印(`[block]` 等)・相手が何を書いたか——は**本文で説明しない**(説明すると
   「冗長: 」として返る)。直すときは足すより削る。相手の語は**指してよいが、相手の語で書かない**——
   相手の言い回しを地の文に写した箇所は、画面に同じ語が有っても「なぞり: 」として止まる(画面が既知に
   するのは何を指しているかであって、語彙ではない)。直し方は説明を足すことではなく、自分の言葉に置き換える。
   詰まりは画面と本文を合わせても解けないものだけなので、その語の初出 1 か所に中身を添える。本文を足して膨らませない——
   coldreader の指摘は読み手ごとに揺れ、足した文がまた新しい指摘を生む(PR 1583 で 1 本の
   返信が 39 回止まり、1,021 字 → 2,555 字に膨れた実測。PR 1429 では 6 回で 5,455 字 → 10,179 字)。
   新規作成は、読み手が持つ物が少ないので、**指摘の類型を言語化して**
   (例:「読者が持っていない前提に寄りかかっている」)その類型で本文全体を掃討する。ただし新しい PR・issue
   (`gh pr create`・`gh issue create`)の読み手は、GitHub が本文の周りに出す物——題・リポジトリ・(PR なら)
   取り込む先と元のブランチ・変更ファイルの一覧・本文が指す #番号 の題——を見た上で読んでいるので、それらは本文で
   説明し直さない。release・gist は文脈ゼロ。
2. 直した本文で同じコマンドを再実行する——新しい coldreader が直した本文を検査する。
3. 「詰まり: 」はその箇所で意味が取れず読み進められなかったものだけで、語の意味((語))・何を指すか((指す先))・
   文のつながり((筋))・求めていることか急ぐか((求めること・急ぐか))のどれかが取れないもの。読み手が引いた字が本文に無い詰まりは、止めずに疑問として返る。根拠・出所・判断の材料・実例が欲しいものは「疑問: 」に出る
   (読み手にもそう指示してある。この検査が見るのは通じやすさだけで、出してよいか・中身が正しいかは見ない)。「疑問: 」は投稿を止めない申し送りで、反映するかは判断してよい。「冗長: 」も止めない
   (削ってよい箇所)。止めるのは「詰まり: 」と「なぞり: 」の 2 つ。「補完: 」は coldreader が推測で埋めた箇所で、これも止めない——ただし
   **意図と違う補完は詰まりより重い**。読み手は自信を持って誤読しているので詰まりとして
   出てこないし、通ってしまえば誤読のまま読まれる。時制・主体・範囲の補完は特に確かめること。
4. 2 回目からの読み手は、前の回の指摘と直した差分を渡されて、指摘が解けたかと、直しが持ち込んだ物だけで止める。
   **だから 2 回目からは、挙がった所だけを直す**(掃討で直していない所まで書き換えると、書き換えた所がみな次の回に読まれる)。
   直していない所の新しい気づきは疑問か補完として返り、止めない。読み手が解けないと言い切らなかった詰まり・なぞりも、疑問として返る。3 回目からは、前の回から残った詰まり・なぞりだけで
   止め、直しが新しく生んだ物も疑問として返る。止める数は本文を直すたびに 1 つ以上減り、0 で通る(直さずに打ち直しても減らない)。往復の上限は無い。
   同じ投稿が 3 回続けて止まると、ゲートが「同じ投稿が N 回続けて止まった」を deny 理由の先頭に出す。挙がった所だけを
   直して打ち直す。持ち主に通させる口は無い(持ち主 2026-10-17)。`COLDREAD_SKIP=1` は付けても効かない。
5. 本文は、ヒアドキュメント・本文旗(`--body` 等)・本文ファイル(`--body-file <絶対パス>` 等)のどれで渡してもよい。
   ゲートはファイルを自分で読む。止まるのは、中身を静的に決められない形(パイプの標準入力・解けない変数・
   `"$(cat …)"`・同じコマンドの中で本文ファイルを書き換えるコマンド)だけ。

## 手元の文書(自動。書いた後に読まれる)

拡張子が md・mdx・adoc・asciidoc・rst・txt の文書を書くと(Write・Edit のほか、Bash の `cat >`・`tee`・`sed -i`・python や MCP のツールで書いても)、同梱のフックが文書の名前だけを、書いた役(親の会話かサブエージェント)ごとに記録し、
書いた役が終わるときに、その役が書いた文書を 1 本 1 回だけ coldreader(既定は haiku・effort high)に読ませる。
前から在る文書は、書き換えた所を含むセクションと冒頭だけを読ませる(新しい文書は全体。2000 字を超えるセクションは、その見出しと書き換えた段落・箇条だけ)。
直すのも指摘の所でよい。Bash で拾うのは、中身をコマンドの字面に書いた文書(ヒアドキュメント・echo・printf・sed -i)と、
git の作業ツリーの中で書き換わった文書で、ほかのコマンドの出力をリダイレクトした写しと cp・mv の行き先は拾わない。
投稿と違って書き込みは止めない。書いた役に返すのは詰まりが在るときだけで、推測で埋めた箇所と疑問はそのとき一緒に返る(推測と疑問だけなら返らない)。返り方は、書いた役で変わる:

- **サブエージェントとして書いたとき**: その役の終わりに、指摘の全文が返る。
  1. 指摘の類型を言語化してから、同型を文書全体で掃討する(上と同じ)。
  2. 直した文書は、また終わるときに読まれる。直さずに残すと決めた指摘はそのままでよい——同じ中身は読み直さない。
- **親の会話で書いたとき**: 本数・件数と、指摘の全文を書き出したファイルの場所だけが返る。対話の会話では、ターンを終えた後に
  読み終えたところで会話が呼び起こされて届く(読む間はターンの終わりで待たせない)。`claude -p` の会話では、ターンの終わりに待って届く。
  1. 全文を親の会話に読み込まず、新しいサブエージェントにそのファイルと直す文書を渡して直させる(その書き直しも、役の終わりにまた読まれる)。
  2. 「推測で埋めた箇所」のうち書き手の意図と違うものだけは、親がファイルのそのセクションを見て、正しい意図を伝える
     (意図を知っているのは書いた親だけ)。
  3. 知らせが「/clear で終わった前の会話(id)が書いた文書」と言うときは、この会話は意図を持っていない。詰まりだけを直させ、
     推測で埋めた箇所は、文書のほかの所・commit の記録・頼みのファイルで意図が確かめられるものだけを直させ、確かめられないものは残す。

読まないもの: 300 字未満の文書、1 行目に `coldread:skip`(前の coldwrite の `coldwrite:skip` も効く)を置いた文書、
`.gitattributes` で `linguist-generated` の印を付けた文書(生成物)か `-coldread` を付けた文書(原文と照合する写しなど、ほかの検査が受け持つ所)、書く前と同じ中身、前に読んだのと同じ中身。手元の文書のゲートだけを切るなら、環境変数 `COLDREAD_DOCS_OFF=1` を入れて Claude Code を起動する。

main に入れる前に、ブランチが書いた文書をまとめて読ませるときは、下の手で検査する手順 2 の `read <そのファイル>` を
`branch-check` に替えて走らせる(ブランチが変えた文書だけを読み、詰まりが在れば終了コード 1。README の「メインブランチに入れる前に読む」)。

## 手で検査するとき(メール・チャットなど、ファイルに書かない文章)

1. 検査対象の本文を一時ファイルに保存する。
2. `bash "${CLAUDE_PLUGIN_ROOT}/hooks/run-python.sh" "${CLAUDE_PLUGIN_ROOT}/hooks/coldread-gate.py" read <そのファイル>` を走らせる。ゲートと同じ依頼文で、
   新しい coldreader が読む(依頼文は `read` を `prompt` に替えると出る。観点の正本はゲートの 1 か所で、ここに写さない)。
   詰まりが在れば終了コード 1。重い文章は `COLDREAD_DOC_MODEL=sonnet` を前に付けて読ませてよい。
3. 指摘の類型を言語化してから同型を掃討する(上と同じ)。
4. 直したら同じコマンドで読み直す——毎回新しい coldreader が読む。新しい指摘が出なくなったら収束(最大 3 巡)。

## 書き方の規則(直すときの基準)

- **ポインタは初出で「中身→ポインタ」の順に置く。** パス・セクション番号・識別子・略語は、
  読者が参照解決できて初めて意味を持つ。「署名アルゴリズムの名前(`alg`)」のように書く
- **冒頭 3 行で「何の話か・自分に関係があるか・急ぐか」に答える。** 権威づけは答えにならない
- **危険の話は「今壊れているのか・壊れる余地だけか」を冒頭で言う。** 安全である事実を
  後ろに置くと、そこまで読者を緊張させたまま読ませることになり、理解が落ちる
- **読者の寿命で前提の厚さを変える。** issue は 3 ヶ月後に文脈ゼロで読まれるので前提を厚く。
  PR の返信はレビュアーの語彙のままでよく、スレッドに見えているものは説明しない
  (ゲートの coldreader もそう読む)
- coldreader に点数は付けさせない。集めるのは詰まった事実だけ(点数は coldreader ごとに揺れて
  収束判定に使えない)。ただし**指摘の件数は数えてよい**——「新しい詰まりが 0 件」が
  収束の計器で、評点と件数は別物である

## 使い分け

リポジトリの文書(入口からの導線を含む検査)は firstread-loop を使う。本 skill と同梱の
ゲートは、issue・PR コメント等、単体で読まれる短い文章向けの軽い姉妹版である。