Headline Craft — 入口を探索し、約束を検める

タイトルとサムネイルは本文との契約書の最初の一行である。初見の人は入口から「何が得られるか」を 受け取り、本文はそれを回収する。このスキルは一発で良い言い回しを書く作業ではなく、 探索 → 分岐 → 比較 → 初見読み → 約束の監査 → 媒体への変換という探索問題として扱う。

根拠（as-of 2026-11-01）:

• 勝つ一言の公式は無い。Upworthy の大規模 A/B では言語特徴から勝者を当てる精度が 54% 程度で、 効くのは文脈と読者。だから型を当てはめるより、異なる仮説を出し分けて候補間の差を大きくする
• 具体性とクリックは山なり。全部言うと開く理由が消え、隠しすぎると何の話か分からない
• 回収されない約束は理解と発信元への信頼を下げる。YouTube はタイトル・サムネの A/B 勝者を CTR ではなく 総視聴時間で決める
• LLM は 1 案ごとの平均品質を上げるが、候補集合を均質にする。独立した生成・異なる読者状態・制約で多様性が戻る
• 知りすぎた作り手は「相手の立場で」と念じても初見の読みを再現できない。効くのは情報を実際に遮断した 読み手の具体的な受け取りを見ること

0. 何を作るか決める

対象の媒体と入口の部品を最初に確定する。部品ごとに役割が違うので、1 本の題を横流ししない。

platform の文字数・記法は project 側の定義（あれば）に従い、無ければ公式の上限を確かめて使う。 project に著者の題の規約（Title Conventions 等）があれば読み、手順 3 の制約の 1 つとして渡す。

1. 素材台帳を作る（まだ題を書かない）

本文・ドラフト・README・abstract・release note を読み、本文が実際に示していることを短い素材に分ける。 各素材に本文での出どころ（節名か引用）を付ける — 手順 6 の監査でそのまま使う。

• 読者がまだ知らない事実・結果（数字はそのまま）
• 失敗、意外だったこと、期待と実際の食い違い
• 比較対象、制約、前提条件
• 具体的な成果物（ツール名・コマンド・ファイル・データ）
• 読者が抱えていそうな問題と、本文がそれにどこまで答えるか
• 著者自身の言い回し（本文・メモ・会話から引用。LLM の要約より著者の語を優先する）
• 本文では示していないこと（言いたくなるが証拠の無い主張）を別欄に書く

最後に「読者が持ち帰る 1 つのこと」を 1 文で書く。これが契約の中身になる。

2. 読者状態を 3〜4 個作る

抽象的な persona ではなく、知識と状況の違う具体的な読者を作る。各読者に 4 項目を書く。

• どこで出会うか（検索結果 / フィード / GitHub 検索 / Zenodo 検索 / SNS の共有）
• 知っていること
• 知らないこと（作り手が当然と思っている語・前提・新規性を、ここに明示的に入れる）
• 欲しい成果

例（illustrative）: 「Claude Code は毎日使うが skill を書いたことがない開発者。X のフィードで出会う。 hooks は知っている。SKILL.md の frontmatter と発火の仕組みは知らない。毎回同じ指示を打つのをやめたい」

3. 独立したラウンドで発散する

1 回の生成で 30 案出すと、言い回しだけ違う同じ案が並ぶ。探索路ごとに独立したコンテキストで作る。

• general-purpose subagent を 4〜6 本、並列に起動する。各 subagent に渡すのは素材台帳・読者状態 1 つ・ 探索路 1〜2 本・媒体の部品だけ。他のラウンドの候補は渡さない
• 各ラウンドは 6〜10 案を返し、各案に「この読者がクリックする理由」を 1 行添える
• 探索路（ラウンドに割り振る。全部を毎回使う必要はない）:
  • 結果を先に出す
  • 困りごとを先に出す
  • 比較・対立から入る
  • 失敗から入る
  • 具体物（ツール名・数字・ファイル）を先に出す
  • 読者の疑問を 1 つだけ残す
  • 本文中で最も意外な 1 文から出す
• 1 ラウンドは振り切る: 明らかに強すぎる・奇妙・具体的すぎる・抽象的すぎる案だけを出させる。 採用するためではなく、最初に出る平均的な言葉の近傍から抜けるため。手順 4 以降で使える要素だけ戻す
• 現行の題があれば比較の基準として 1 本に加える
• tagline・SNS の 1 行目のように部品が小さいときは、ラウンドを 2〜3 本に減らしてよい。独立性は保つ

サムネイルの文字はタイトルと分担する。同じ語を繰り返さず、タイトルが言わない 1 要素（数字・物・ Before/After の片側）を数語で持たせる。タイトル案とサムネ文字案は組で扱う。

4. 仮説ごとにまとめ、代表を残す

全候補を「なぜクリックさせようとしているか」（仮説）でまとめる。同じ理由でクリックさせる案は 1 群にし、群ごとに代表 1〜2 本を残す。比較は言葉で行い、点数を付けない — 点数を付けると代理指標を 満たす方向に寄るため。各代表について 2 点を書く。

• 何を明かしているか
• 何だけを意図的に残しているか

このとき情報量を見る。「全部分かったので開く必要がない」と「何の話か分からない」の間にあるか。 外れている案は、明かす要素を 1 つ足すか 1 つ引いて戻す。適切な量は媒体と読者で変わるので、数値の閾値は使わない。

5. 初見読み — 本文を知らない読み手に読ませる

読み手は本文・素材台帳・著者の設定から切り離した別プロセスにする。通常の subagent は著者の CLAUDE.md・rules・memory を読み込み、repo の草稿も開けるので、初見にならない。 skill: persona-read-loop の scripts/read.sh を使う（tools なし・設定なし・空ディレクトリで起動する）。 初回は read.sh --probe で隔離を確かめ、0 以外で終わったら止めて出力を著者に渡す。 <work> は scratchpad の作業ディレクトリ。

R=~/.claude/skills/persona-read-loop/scripts/read.sh
"$R" --probe
for id in <ID1> <ID2>; do
  "$R" "<work>/reader-$id.txt" "<work>/coldread-prompt.md" "<work>/candidates.md" > "<work>/cold-$id.json" &
done; wait

• reader-<id>.txt: 手順 2 の読者状態 1 つ（出会う場所・知っていること・知らないこと・欲しい成果）を 「You are <その人>. Answer honestly as that person.」の形で書いた system prompt
• candidates.md: 代表案だけ（サムネ文字があれば組で）。本文も素材台帳も入れない
• coldread-prompt.md: 各案について次を JSON で答えさせる
• 何の話だと思うか
• 読む前に何が得られると期待するか（1 文）
• 分からない語・前提
• 誤解しそうな点
• 開きたいか、まだ分からずに残っていることは何か

この答えが作り手の想定とずれた箇所が、知識の呪いで見えていなかった箇所である。 ただし読み手モデルの学習時点より新しい機能名・用語を知らないのは cutoff の結果で、本物の読者の誤解とは限らない。 その語は対象読者が知っているかで判断する。ずれは手順 6 で直す。

6. 約束の監査

各代表について、初見読みの「期待」1 文と、素材台帳の出どころを対応させる。

• 回収されない期待は、題を弱めて回収できる言い方に直す。題の形は保つ
• 数字・比較・断定・成功／失敗・再現性・万能性を含む語は、素材台帳の値と一字ずつ照らす
• 本文を少し補えば回収できる約束は「本文側の不足」として著者に返す（題を弱めるか本文を足すかは著者が決める）
• 読み手が誤解した点は、誤解を生んだ語を本文の固有名詞・動詞に置き換える

7. 言い回しの癖を除く

候補集合を横に並べて、集合の中で繰り返されているものを探す。固定の禁止語リストではなく、この回の候補群の 重なりを見る（日本語の LLM 語彙の偏りは確立したリストが無いため）。

• 3 案以上に出てくる語、同じ構文（「〜の本質」「〜で変わった」等が群をまたいで並ぶ）
• 情報を足さない強調語（革新的・徹底解説・完全ガイド・知らないと損 等）
• 本文に出てこない抽象語

見つけたら素材台帳にある本文固有の名詞・動詞に置き換える。置き換え先が台帳に無ければ、その語は削る。

8. 媒体へ変換して提示する

同じ成果物から、手順 0 で決めた部品ごとに別々に仕上げる。

• 記事: 「なぜ読みたいか」を前に。検索流入が主なら、問題・ツール名・エラー文を題に残す
• GitHub: repo 名は「これは何か」、description は誰の何のためか、social preview は記事の見出し画像と同じ役
• Zenodo: 主要語と実質的な結果を入れた記述的な題。短さより検索・引用での識別性
• サムネイル / 見出し画像: 文字案に加え、構図メモ（焦点にする 1 つの対象、置く要素の数、文字の位置）を付ける。 顔・感情表現の効果は観察研究どまりなので、本文の内容に合うときだけ使う

提示は仮説の群ごとに並べ、各代表に次を添える。順位・点数・推奨は付けない — 選ぶのは著者である。

• 仮説（この案が誰に、なぜ開かせようとしているか）
• 明かしていること／残していること
• 初見読みの期待と、それを満たす本文の箇所
• 監査で直した点、または著者に返す「本文側の不足」

A/B テストできる媒体（YouTube の Test & Compare、Substack のタイトル A/B）では、仮説の違う 2〜3 案を テスト候補として示す。勝敗は CTR ではなく、読了・視聴時間など開いた後の行動で見るよう添える。

境界

• 公開記事の題を project 側の点検 agent や規約が持つ場合は、提示した全代表をそこへ渡す
• README の tagline を測るのは skill: readme-writer の references/tagline-eval.md。このスキルは候補を供給する
• 画像そのものの制作はこのスキルの外。構図メモまでを渡す