x-draft — リサーチレポートの X 投稿下書き

daily-research のレポート 1 本から、X (プレミアムの長文投稿) 用の日本語下書き 1 本を作る。 成功基準は摩擦: ユーザーが「投稿したい」と思ってから、コピペ可能な品質の下書きが 数分で手に入ること。投稿本数のノルマ・エンゲージメント目標は置かない。

境界 (なぜ下書きまでなのか)

• 投稿は必ず人間が行う。X への自動投稿・API 投稿・ブラウザ自動化は本 skill の 範囲外（公開・外部送信は人間に渡す — rules/common/boundary.md）
• 通知・承認リクエストも作らない。下書きはこの会話に出力して終わり
• スレッド形式は作らない。手動コピペと相性が悪い。長文 1 ポストに収める
• 自分の記事の告知と、Buffer への下書きの投入は skill: social-post が持つ

手順

1. レポートを解決する

対象は daily-research の解説レポート ({date}_{track}_{slug}.md)。置き場所は daily-research repo の config.toml (vault_path + output_dir) から解決する。 config が読めない環境では auto-memory の vault パスを使う。

• ユーザーが日付・track・ファイル名のどれかで指定していればそれを開く
• 指定が曖昧なら、最新日のレポート一覧 (ファイル名だけ) を見せて選んでもらう
• レポートは read-only。vault 側のファイルは編集しない

2. 事故ゲート (軽量・スキップ不可)

下書きを書く前に:

1. 一次ソース再確認: 下書きの主要主張を支えるソース URL (レポート末尾「ソース」節 から 1〜3 件) を WebFetch で再取得し、レポートの要約が一次ソースの内容と一致するか 確認する。歪みを見つけたら、その主張は下書きに使わず、ユーザーに歪みの内容を報告する
2. 陳腐化チェック: レポートの日付が今日から 3 日以上前なら、主要主張が置き換わって いないかを WebSearch で 1 回確認する (LLM 界隈は 1 週間スケールで陳腐化する)。 置き換わりを見つけたら下書きに反映するか、投稿自体を見送る選択肢を提示する
3. ゲートの結果は §4 で下書きと一緒に報告する

3. 下書きを書く

X 読者向けに書き直す。レポートの転記・要約切り貼りは禁止 — レポートは repo 文脈を 持つ読者向けの解説であり、X のタイムラインで初見の読者が読むものとは別物。

構成規律:

• 日本語・長文 1 ポスト (プレミアムの長文上限内。目安 500〜2,000 字)
• 1 行目がすべて: タイムラインでは 1 行目しか見えない。結論か意外性のある事実で 始める。前置き (「今朝のリサーチで面白い発見が」等) は書かない。1 行目に迷ったら skill: headline-craft で候補を探索する
• 本文: 前提知識ゼロの読者が 1 ポストで理解できる自己完結の解説。レポートの 記述規律 (冒頭結論・背景解説) を X の長さに再圧縮する
• as-of 日付: 主要な事実に「2026-08-07 時点」等を 1 箇所以上明記する。鮮度の 限定は誠実さであり、後日読まれたときの誤情報化を防ぐ
• 末尾に一次ソース URL 1〜3 件: ステップ 2 で再確認済みのものだけ
• ハッシュタグは付けない (研究発信のトーンに合わない)。付けたい場合はユーザーが足す

文体規律 (正本は各 skill — 複製しない):

• ユーザーの普段の X の口語に合わせる: 下書きは skill の既定文体ではなくユーザーの voice で書く。まず references/voice.md を読む — 確定済みの voice プロファイル (見本の場所・特徴・却下された register) がそこにある。無い環境では、ユーザーの 過去ポストやブログを 1〜2 本読んで register を写し取るか、ユーザーに 1 回聞く。 記事の文体と SNS の文体は別物として扱う
• AI slop と文の原則 → 執筆の背骨 ~/MyAI_Lab/zenn-content/.claude/rules/writing-principles.md と診断表 ~/MyAI_Lab/zenn-content/.claude/skills/writing-ecosystem/references/style-diagnostics.md。Voice は defer しない（意図的分岐。 正本側の Related に登録済み）
• 脱 AI-tell → skill: public-comment の改稿規律を公開ポストにも適用する

4. 出力する

• 下書きをコードブロックで提示する (コピペ 1 回で X の compose に貼れる形)
• 続けて: 使ったソース・鮮度判定・(あれば) レポートとの差異を、投稿前に一目で確かめられる短さで報告する
• ユーザーの改稿指示 (短く / 硬く / 英語版も 等) には対話で応じる。英語版を求められたら skill: prose-translation の voice 保持規律に従う

例

Input: 「今朝の akc のレポート、X に投稿したい」 Output: 2026-08-07_akc_*.md を読み、ソース 2 件を WebFetch 再確認、鮮度 OK (当日)。1 行目 = レポートの結論を意外性の角度で言い直した一文、本文 800 字前後、 末尾に一次ソース URL 2 件、as-of 日付入り。コードブロックで提示 + ゲート結果 2 行。

Input: 「8/2 の contemplative のやつポストにして」(今日が 8/7 の場合) Output: 5 日前 = 陳腐化チェック発動。WebSearch で主要主張の現状を確認し、 変化があれば「この部分は 8/5 に更新されています。反映しますか、見送りますか」と 提示してから下書きに進む。