キャッチコピーと文字起こしから X 長文投稿を作りたいとき、スタイルゲノム文体を適用した 1800〜2200 文字の 2 パターン投稿・タイトル・スレッド分割・ファイル出力まで通したいときに使う。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
最小の実成果物 (長文パターン A/B と タイトル を含む 1 ファイル) を main context で作成する。作成の具体的な段取りは後述の「実行手順」節にあり、これは pre-choice の作業として選択を待たずに進める。この段階で通すのは絵文字ゼロ・タイトル 50 文字以内・見出し構造・A/B本文同値（F4）・B本文に1行2文が無いこと（F5）・B見出しの 【】 表記とAの見出し2との一致（F6）・文字数という数えられる機械検証だけとし、check-no-emoji.js --file <成果物パス> / validate-title.js --title "<確定タイトル>" / validate-headings.js --file <成果物パス> --title "<確定タイトル>" --strict-h2-count / count-chars.js --text "<パターンA本文>" --min 1800 --max 2200 が終了コード 0 を返した時点で、現物のファイルパスと検証結果を提示して accept-as-is / light / standard / detailed を記録する。accept-as-is の場合はその場で handoff 完了とし、後続 section へ進まない。
このゲートの対象は、意味評価・リライト・追加パターン生成という、実成果物ができあがった後に走る改善の 3 種だけである。light / standard / detailed が記録されて semantic_evaluator_started へ遷移した場合にだけ、この 3 種を動かす。release と exhaustive は別の明示 event を必要とする。
後続の「実行手順」節はこのゲートの対象ではない。あれは pre-choice で提示する実成果物そのものを組み立てる段取りであり、利用者の判断を待たずに main context で通す。段取りの順番は 実行手順 → 機械検証 → 現物提示 → 選択記録 → 選択された改善 であり、この並びの先頭 2 つだけが pre-choice に属する。
| 原則 | 説明 |
|---|---|
| Script First | 決定論的処理はスクリプトで100%精度実行 |
| Progressive Disclosure | 必要な時に必要なリソースのみ読み込み |
| LLM for Creativity | 判断・創造・言語化はLLMに委ねる |
| 変数 | 意味 | 解決方法 |
|---|---|---|
${XLP_SKILL_DIR} | 本スキルのルート | ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/run-x-longpost-create |
${XLP_PROMPTS_DIR} | Read 用プロンプト群 | ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/prompts |
${XLP_VAULT_ROOT} | vault ルート | env のみ。未設定なら vault 内 path は解決不能 |
${XLP_OUTPUT_DIR} | 出力先ディレクトリ | env → ${XLP_VAULT_ROOT}/05_Project/X の2段のみ |
${XLP_NETA_FILE} | 00ネタファイル | env。未設定時は ${XLP_VAULT_ROOT} がある場合のみ output-config.json の path template を解決 |
実パスは plugin 本体に固定しない。出力先の解決契約は references/output-config.json の XLP_OUTPUT_DIR → XLP_VAULT_ROOT の2段だけである。両方とも未設定なら fail-closed とし、存在しない defaults や推測パスへフォールバックしない。
scripts/ は Node.js（v18 以上）で動作する。node が PATH に無い場合は実行を中止し、ユーザーへ通知する。
絵文字は一切使用しない。タイトル・見出し（#/##/###）・本文・短文投稿・長文投稿A/B両パターン・ハッシュタグ・キャッチコピー・Idea Compass、すべての成果物において絵文字は禁止。
## [絵文字] ヒアリングをスキル化する → 正: ## ヒアリングをスキル化する[絵文字] のように言葉で表すnode ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/check-no-emoji.js --file <path>（または --text "..."）で機械的に行う（絵文字あり=終了コード1）絵文字の定義（判定境界）: 何を絵文字とみなすかの境界（\p{Extended_Pictographic}・使用可の記号一覧・処理系差）は ref-x-longpost-canon「絵文字の定義（判定境界）」が唯一の正本である。scripts/lib/text-rules.js が共有意味実装を持ち、check-no-emoji.js / validate-title.js / validate-headings.js / build-visual-prompts.js がそれぞれの CLI 入力境界で検査する。
文字数の測定単位は2系統ある。count-chars.js は空白・改行を除いた文字数で数え、validate-title.js と validate-headings.js は空白を含む NFC コードポイント数で数える。本 SKILL.md では文字数の規定に必ず測定単位を併記する。本文量の規定（1800〜2200・400〜499）は前者、タイトルと見出しの長さの規定（50字・12〜28字・リード文300字）は後者で判定する。
見出し1は50文字以内（長文Aの # タイトル。コードポイント数・空白含む）。50文字はファイルシステムの制約ではなく編集規範である。タイムラインで最初に読まれるのは先頭30文字程度であり、そこに核を置いたうえで予告を足すと50文字に収まる。加えて、この文字列は長文Bの先頭行・# タイトル・ファイル名のタイトル部にも同一で使われるため、短く保つことが一覧性と命名の一貫性に直結する。編集規範であっても上限値は絶対（FAIL）として扱い、警告へ降格しない。超過時に末尾を切り捨てることは禁止で、references/title-guidelines.md の構文パターンA〜Hに沿ってリライトし直す（字数配分は入口26〜32字・予告8〜18字）。
見出し1の後に見出し2が必ず存在する。# タイトル の後に ## が1つも無い状態を許さない。見出し2の個数は 3〜8個（check ID H5）。H5 は validate-headings.js の既定では警告止まりのため、本スキルでは常に --strict-h2-count を付けて FAIL 扱いにする。欠落したら本文の文脈の区切りから見出し2を生成し直す。間には冒頭フックのリード文を置いてよい（見出しを挟まず8行・300文字以内。空白込みの NFC コードポイント数／validate-headings.js の測定）。
node ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-title.js --title "..." と node ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-headings.js --file <path> --strict-h2-count で機械的に行う（違反=終了コード1）。PASS するまで出力を確定しない長文投稿を作る場合、短文は8投稿では終わらせず「投稿9｜要約型」（400〜499文字。空白・改行を除く／count-chars.js の測定）を必ず出力する。長文投稿と短文投稿を同時に作成するワークフロー（文字起こし → 長文投稿 + 短文投稿）では、投稿1〜8に加えて投稿9が成果物の一部であり、8投稿だけで出力を確定してはならない。
count-chars.js の測定。範囲外はFAIL）。改行は文脈（文節・句読点）で入れる。見出しは ## 投稿9｜要約型、直下に **テーマ**: 長文投稿の要点を[実際の文字数]文字で要約（[要約対象の核]） を置くnode ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/count-chars.js --text "<投稿9本文>" --min 400 --max 499 で機械的に行う（範囲外=終了コード1）。PASSするまで出力を確定しない。正本: x-longpost-create-multi-posts.md §5.3.5 / MP-C07| 用途 | 開始方法 |
|---|---|
| 長文投稿作成 | 文字起こし + キャッチコピーを入力（メモはAIが自動生成） |
| 8投稿作成 | run-x-multipost-create を使う（文字起こしを入力し「8投稿作成して」と指示） |
| 長文投稿 + 8投稿 | 文字起こし + キャッチコピーを入力し「8投稿も作成して」と指示（→ 投稿9｜要約型400〜499文字（空白・改行を除く）が必ず付く） |
| 短文投稿最適化（1つ） | run-x-shortpost-optimize を使う |
| 日付計算のみ | node ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/calculate-next-date.js --neta-file "${XLP_NETA_FILE}" |
メモの構造化はAIが自動で行う。文字起こしを入力するだけでよい。
| 項目 | 必須 | 説明 |
|---|---|---|
| 文字起こし | ○ | 音声録音の文字起こしテキスト（フィラー・話し言葉をそのまま） |
| キャッチコピー | ○ | 投稿の核となる一言メッセージ |
→ AIが自動で「構造化メモ生成 → 長文投稿作成」を実行する → 「8投稿も作成して」と指示すると8投稿も同時作成可能
構造化済みメモを「メモ」として渡すと Phase 0 をスキップする。
| 項目 | 値 |
|---|---|
| ベースパス | ${XLP_VAULT_ROOT}（env のみ。必要な場合に明示） |
| 出力先 | ${XLP_OUTPUT_DIR} → ${XLP_VAULT_ROOT}/05_Project/X/ の2段のみ |
| ファイル名 | X長文投稿-prompt作成 - YYYY-MM-DD_[タイトル].md |
| 日付決定 | 00ネタファイル（${XLP_NETA_FILE}）の最新日付 + 1日 |
| テンプレート | output-config.json の paths.obsidianTemplate（無い場合は同梱の ../../assets/output-template.md） |
| スタイルゲノム | output-config.json の paths.styleGenomeSource（無い場合は references/style-genome.md が正本） |
出力先は自動コミット対象になりうるため、検証未了のファイルを直接置かない。一時パスで validate-headings.js を PASS させてから配置する。
長文投稿は Phase 0（文字起こし構造化）→ 日付計算 → Phase 1（入力解析）→ Phase 1.5（タイトル確定。以後この文字列が唯一のタイトル）→ Phase 2（文章生成・文字数検証）→ Phase 3（出力整形・ファイル出力）→ Phase 3.5（アイデアコンパス）→ Phase 4（サムネイル・optional 図解生成）の順に進む。長文投稿と 8 投稿を同時に作る場合は Phase 0 の直後に 2 系統へ分岐し、Phase 3.4（投稿9｜要約型）で合流する。
Phase 4 は本スキルの範囲外であり、run-x-visual-generate が担う。パターン A が確定した後でしか画像を作れないため、接続点は Phase 3.5 の後に固定する。
各 Phase がどの prompts/*.md をどの順で Read するか、3 系統のフル図、フロー間の対応表は references/workflow-diagrams.md が唯一の正本である。本 SKILL.md は図の実体を持たない。
8投稿フロー単独の仕様は run-x-multipost-create、短文1投稿の最適化は run-x-shortpost-optimize を参照する。
本 SKILL.md はリソース表の実体を持たない。正本は 2 つに分かれる。
| 正本 | 内容 |
|---|---|
| references/resource-map.md | prompts / scripts / 共有 references / assets の所在と読込条件（散文・plugin 全体） |
| references/resource-map.yaml | 本スキルの references を「いつ開くか」で引く機械可読索引 |
スクリプトは ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/、prompts・共有 references・assets は plugin ルート直下、本スキル専用の references は ${XLP_SKILL_DIR}/references/ にある。規定が食い違って見えたときの決着は ref-x-longpost-canon が正本索引として担う。
L1 表層 / L2 語彙 / L3 統語 / L4 談話 / L5 修辞 / L6 認知 / L7 価値観 / L8 対人 の 8 レベルすべてを文章生成時に適用する。各レベルの適用内容は references/style-genome.md が唯一の正本であり、本 SKILL.md は要約表を持たない（要約を持つと正本と二重管理になる）。
【重要】同一ファイルに2パターンを出力。文章内容は完全に同一、改行位置のみ異なる。
| パターン | 特徴 | 用途 |
|---|---|---|
| A: 文脈改行型 | 段落・意味の区切りで改行、見出し付き | PC閲覧向け（優先使用） |
| B: 短文改行型 | 見出しは 【見出し文言】 の単独1行で囲む（先頭タイトル行と本文行は囲まない）。本文は文脈（文節・句読点）で改行し、1行へ2文を詰めない。文字数で機械的に切らず、Aと同じ本文を改行だけ変える | スマホ閲覧向け |
count-chars.js の測定）・タイトル付きruntime_root_policy: host-skill-path を適用する。CLAUDE_PLUGIN_ROOT をplugin rootとして使用する。SKILL.md のabsolute pathから、plugin manifestを持つ祖先を上方探索して論理 PLUGIN_ROOT を解決する。cwd からplugin rootを推測せず、literal placeholderをshellへ渡さない。各shell invocation内で解決済みabsolute pathを PLUGIN_ROOT に設定する。prompts/ 配下はこのowner Skill契約を継承する。${XLP_PROMPTS_DIR}/x-longpost-structure-transcript.md → 文字起こしをフィラー除去・書き言葉変換・構造化メモへ変換run-x-multipost-create を使うnode "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/calculate-next-date.js" --neta-file "${XLP_NETA_FILE}"
x-longpost-parse-input.md → 構成要素抽出（メモ = 手動メモ or structure-transcript の出力）x-longpost-resolve-contradictions.md → 矛盾解決x-longpost-create-title.md → 3案生成・最適選定node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-title.js" --title "[タイトル案]" を3案すべてに実行。PASSしない案は次へ渡さない# タイトル セクション・ファイル名で一字一句そのまま使うx-longpost-apply-style-genome.md → スタイル適用（見出しは出力しない）x-longpost-optimize-length.md → 2パターン生成・見出し2作成（タイトルは作らない。Step 4 の確定タイトルをそのまま見出し1に置く）node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/count-chars.js" --text "[生成された投稿文]" --min 1800 --max 2200
# 見出し1の50文字・見出し2の存在（3〜8個）を検証（PASSするまで出力へ進まない）
# --text には「# タイトル」行を含むパターンA全文を渡す（--title は必須）
node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-headings.js" --text "[# タイトル 行を含むパターンA全文]" --title "[Step 4 の確定タイトル]" --strict-h2-count
出力手順の唯一の実体は x-longpost-output-file.md §4.5.1 に置く。generate-filename.js が返す filename（正規 basename）を scratch 内でもそのまま使い、expand-template.js 展開後の見出し・タイトル一致・F4/F5・絵文字ゼロを検証する。全検証後にのみ同名の fullPath へ正規配置し、その後に00ネタファイルを更新する。いずれかが失敗した候補は scratch に留め、既存の fullPath を上書きしない。
x-longpost-create-multi-posts.md §5.3.5 → 長文Aの要点を400〜499文字（空白・改行を除く）で要約（新規主張なし）node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/count-chars.js" --text "[投稿9本文]" --min 400 --max 499 がPASSするまで出力を確定しない。長文投稿を作らない8投稿単独ワークフローでは実行しないx-longpost-generate-idea-compass.md → 投稿テーマと00ネタファイルから4方向×5ノートを選定# Idea Compass セクションに挿入成果物テンプレートの 図解 / Xサムネイル（5:2） / noteサムネイル（1280×670px） の 3 欄は、本スキルでは空のまま残す。長文成果物を提示して accept-as-is / light / standard / detailed の選択を完了し、本セッションを handoff_complete にした後、ユーザーが画像生成を明示したときだけ run-x-visual-generate を別セッションとして起動する。引き継ぐのは検証済み投稿ファイルの絶対パス 1 つだけである。引き継ぎ先の標準成果物は X 5:2 と note 実 PNG 1280x670 の2枚で、図解は明示指定時のみ optional である。
validate-headings.js と check-no-emoji.js）が PASS し、パターン A が確定していることを引き継ぎの前提とする。確定前に引き継がない（本文を直すと図解が本文とずれるため）| すべきこと | 避けるべきこと |
|---|---|
| メモの内容を忠実に反映 | 固定フォーマットの使用 |
| スタイルゲノム8レベルを適用 | AIっぽい堅い表現 |
| スクリプトで決定論的処理 | 同じ表現の繰り返し |
| 1800〜2200文字（空白・改行を除く）に収める | 情報が行ったり来たりする構成 |
| 内容に即した具体的な見出し | 毎回同じパターンの見出し |
| 自然な流れの文章 | わざとらしい導入表現 |
| 主張の「軸」を1つに絞る | 言いたいことが2つ以上ある曖昧な構成 |
| 冒頭に意外性のあるフックを作る | ありきたりな冒頭（「〜は大切です」等） |
| 入口（タイトル・冒頭・フック）はホリゾンタル、中身はバーティカル | 専門語・属性の重ね掛けで入口を狭める（TAMを潰す） |
| 専門語は普遍的欲求（時間・お金・楽・不安解消・評価・変化）へ欲求翻訳して入口に置く | 書き手の専門性起点でタイトル・冒頭を作る |
| ネタ性質判定の結果と根拠を出力に明示する | 全ネタを一律の入口設計で処理する |
| 具体的に書く（行動レベルまで） | 抽象的なAI表現（「良い影響がある」等） |
| 締めに印象的なフレーズを残す | 当たり前すぎる締め（「成長につながります」等） |
| AI臭の記号を排除する | emダッシュ(—)、／並列、（）逃げ、「」多用 |
| 語尾・リズムに変化をつける | 〜です連続、接続詞過多、温度一定 |
| スタンスを取って言い切る | 保険・中立装い・弱い否定で逃げる |
| 動詞中心の具体表現にする | 万能語(重要/効果的/最適)で押し切る |
| 使い古された比喩を避ける | 地図/羅針盤/土台/柱/DNA/車の両輪等 |
| 主観・感情・一次情報を入れる | 客観的整理だけで終わる |
正本: references/title-guidelines.md §3.3（タイトル用は §3.3.1、本文用は §3.3.2）。本 SKILL.md は実体を持たず、正本への参照のみを持つ。タイトル案は validate-title.js に通すことで機械的に検出される。
実行後は必ず記録:
node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/log_usage.js" --result success --phase "Phase 4"
node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/log_usage.js" --result failure --phase "Phase 3" --error "ValidationError"
記録先は XLP_LOG_FILE → ${XLP_OUTPUT_DIR}/x-longpost-usage-log.md の順で解決する。plugin ディレクトリの中には書かない（配布物を実行時に書き換えないため）。どちらの env も未設定の場合は記録をスキップして終了コード 0 を返す（推測パスへ書き出さない）。
| 出典 | 適用 | 目的 |
|---|---|---|
| スタイルゲノム基礎分析結果 | 8レベル文体特徴 | 一貫性ある個人文体 |
| On Writing Well (Zinsser) | 簡潔な文章作成 | 冗長削除・読みやすさ |
| Made to Stick (Heath) | 共感・感情駆動型構成 | 効果的な展開 |
| 中村昌弘 AI文章編集4原則 | AI文章の人間編集 | 主張明確化・フック・具体性・フレーズ |
| note公式タイトルガイド | タイトル設計 | 読まれやすいタイトル作成 |
| @genkaidokusho分析 | 8パターンフォーマット | 短文投稿最適化 |
| Continuous Delivery | Script First | 決定論的処理の自動化 |
| もとやま AIっぽい文章表現大全 (@ysk_motoyama) | AI臭6分類＋崩し3技法 | AI臭の体系的排除と人間らしさの注入 |
| 三連休 バーティカルすぎるnote論 (@san_renkyu) | ホリゾンタル入口×バーティカル中身・欲求翻訳・TAMチェック | 入口は広く解決策は深く |
変更履歴は CHANGELOG.md、正本の所在一覧は ref-x-longpost-canon を参照する。
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。