git:20261008.b63e5f1 to git:20261018.9c2cf31

---

name: x-draft

description: "Draft one long Japanese X (Twitter) post from a daily-research report. Use when wanting to post a report to X (X に投稿したい)."

user-invocable: true

origin: shimo4228

---

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

daily-research のレポート 1 本から、X (プレミアムの長文投稿) 用の日本語下書き 1 本を作る。

**成功基準は摩擦**: ユーザーが「投稿したい」と思ってから、コピペ可能な品質の下書きが

数分で手に入ること。投稿本数のノルマ・エンゲージメント目標は置かない。

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

- **投稿は必ず人間が行う**。X への自動投稿・API 投稿・ブラウザ自動化は本 skill の

範囲外（公開・外部送信は人間に渡す — `rules/common/boundary.md`）

- 通知・承認リクエストも作らない。下書きはこの会話に出力して終わり

- スレッド形式は作らない。手動コピペと相性が悪い。長文 1 ポストに収める

## 手順

### 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 に更新されています。反映しますか、見送りますか」と

提示してから下書きに進む。