X Draft

---
name: x-draft
description: "daily-research のリサーチレポートから X (Twitter) 投稿用の日本語長文下書きをオンデマンド生成する対話 skill。Use when the user says 「X に投稿したい」「X 用の下書き作って」「これポストしたい」「ツイートにして」, invokes /x-draft, or mentions turning a daily-research report into a social media post — even if they just say 「今朝の akc のやつ X に流したい」 like shorthand. pull 型: 通知もノルマもなく、ユーザーがレポートを読んで投稿したいと思ったときだけ呼ぶ。軽量事故ゲート (一次ソース再確認 + 3 日陳腐化チェック) と脱 AI-tell 改稿を通した、コピペ 1 回で投稿できる長文 1 ポストを出力する。NOT for: 記事・エッセイ執筆（→ writing-ecosystem）、公開スレッドへの返信（→ public-comment）、タイトル・一行コピーだけの生成（→ headline-craft）、X への自動投稿（本 skill は下書きまで — 投稿は人間が行う）。"
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 に更新されています。反映しますか、見送りますか」と
提示してから下書きに進む。