本文へ移動
cccskills
無料GitHub で公開

ref-x-longpost-canon

X 長文投稿のルールがどのファイルにあるか迷ったとき、同じ規定が複数箇所に見えてどれが正か判断する必要があるときに読む。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md13.9 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

ref-x-longpost-canon

Purpose & Output Contract

本ファイルは、規定の所在と意味を説明する読み取り専用の索引である。値の合否をここの散文で決めない。機械可読 spec/script が判定し、本ファイルはその判定先と人間向けの意味を一方向に案内する。visual の kind・寸法・比率・横断 text rule は skills/run-x-visual-generate/references/visual-spec.json、その他の数値判定は表に記載した検証 script が authority である。

元スキル(v3.14.0)では同じ規定が複数ファイルに実体で重複していた。plugin 化にあたり「正本1箇所+他は参照のみ」へ整理した結果を記録する。

規定の値が食い違って見えたときは、本索引が指す machine-readable authority を実行する。散文は意味説明であり、機械判定を上書きしない。


Runtime root contract

  • runtime_root_policy: host-skill-path を適用する。
  • Claude Codeでは CLAUDE_PLUGIN_ROOT をplugin rootとして使用する。
  • Codexではホストが提示したこの SKILL.md のabsolute pathから、plugin manifestを持つ祖先を上方探索して論理 PLUGIN_ROOT を解決する。
  • cwd からplugin rootを推測せず、literal placeholderをshellへ渡さない。本skillは Read のみを持ち自らshellを起動しないため、下表のパスを開く側が解決済みabsolute pathへ展開してから読む。

正本一覧

本表のパスはすべて plugin ルート ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}} からの相対である(読み手のファイル位置に依存しない)。

規定正本参照のみ(実体を持たない)
禁止表現リスト(タイトル)references/title-guidelines.md §3.3.1prompts/x-longpost-create-title.md §9
禁止表現リスト(本文)references/title-guidelines.md §3.3.2prompts/x-longpost-apply-style-genome.md §4.5、prompts/x-longpost-optimize-length.md §4.3.1、各 SKILL.md
タイトル構文パターンA〜H・字数配分・心理トリガーreferences/title-guidelines.mdprompts/x-longpost-create-title.md
見出し構造の絶対ルール R1/R2/R3・4箇所一致・A/B本文同値・Bの改行と 【】 見出し・check ID H1〜H10 / F1〜F6skills/run-x-longpost-create/references/heading-structure-rules.mdprompts/x-longpost-optimize-length.md、prompts/x-longpost-output-file.md、skills/run-x-longpost-create/SKILL.md
スタイルゲノム 8レベル(L1〜L8)の詳細references/style-genome.mdskills/run-x-longpost-create/SKILL.md(索引表のみ)、prompts/x-longpost-apply-style-genome.md、prompts/x-longpost-short-post-optimizer.md §5 Phase 4、prompts/x-longpost-create-multi-posts.md §5.3
AI臭6分類 + 崩し3技法references/anti-ai-writing-guide.mdprompts/x-longpost-apply-style-genome.md、prompts/x-longpost-optimize-length.md、prompts/x-longpost-short-post-optimizer.md、prompts/x-longpost-create-multi-posts.md §5.4、skills/run-x-longpost-create/references/optimize-length-details.md §2
AI文章編集4原則(中村昌弘)skills/run-x-longpost-create/references/optimize-length-details.md §1prompts/x-longpost-apply-style-genome.md(①②主担当)、prompts/x-longpost-optimize-length.md(③④主担当)
文脈改行のルール・かぎ括弧複数の改行ルールskills/run-x-longpost-create/references/optimize-length-details.md §3・§4prompts/x-longpost-optimize-length.md
短文投稿8フォーマット・冒頭フックバリエーション・改行ルール詳細references/short-post-formats.mdprompts/x-longpost-short-post-optimizer.md §6.2、prompts/x-longpost-create-multi-posts.md §5.2
表現バリエーション(接続詞・文末・締め・問いかけ・強調副詞)references/expression-variations.md各 agent の生成フェーズ
ホリゾンタル入口×バーティカル中身・欲求翻訳6カテゴリ・TAMチェック・ネタ性質判定references/horizontal-vertical-guide.mdprompts/x-longpost-create-title.md、prompts/x-longpost-short-post-optimizer.md SP-C08
見出しタイトルの作り方(避けるべき汎用タイトル・目指すべき具体タイトル)skills/run-x-longpost-create/references/heading-title-guide.mdskills/run-x-longpost-create/SKILL.md「見出し作成のガイドライン」
ワークフロー図のフル版・フロー間対応表skills/run-x-longpost-create/references/workflow-diagrams.mdskills/run-x-longpost-create/SKILL.md(要約図)
リソース一覧(prompts / references / assets / scripts)skills/run-x-longpost-create/references/resource-map.mdskills/run-x-longpost-create/SKILL.md(要約表)
Script と LLM の処理分担マトリクスskills/run-x-longpost-create/references/script-llm-patterns.md各 SKILL.md
入出力パスの env-only 解決順skills/run-x-longpost-create/references/output-config.json../../scripts/generate-filename.js、各 SKILL.md「出力設定」
visual kind・生成/納品寸法・比率・palette・背景規則・横断 text ruleskills/run-x-visual-generate/references/visual-spec.jsonbuild-visual-prompts.js、validate-visual-assets.js、lint-thumbnail-prompt.js、thumbnail-specs.md
サムネイルの画風・配色・情報商材的意匠の禁止skills/run-x-visual-generate/references/thumbnail-style-canon.mdx-longpost-design-thumbnail-prompt.md、thumbnail-specs.md、lint-thumbnail-prompt.js
画風の見本画像(線の太さ・塗りの密度・簡略度)assets/reference-images/manifest.json文章の canon が決めるのは色・個数・余白まで。絵でしか渡せない量はここが正本で、codex exec -i として生成へ渡る
投稿9|要約型(400〜499文字)の必須条件prompts/x-longpost-create-multi-posts.md §5.3.5 / MP-C07skills/run-x-longpost-create/SKILL.md「絶対遵守ルール」、skills/run-x-multipost-create/SKILL.md
短文投稿最適化の4フェーズ・2つの呼び出しモードprompts/x-longpost-short-post-optimizer.mdskills/run-x-shortpost-optimize/SKILL.md、skills/run-x-longpost-create/SKILL.md Phase 3
絵文字全面禁止scripts/lib/text-rules.js(共有意味実装)check-no-emoji.js / validate-title.js / validate-headings.js / build-visual-prompts.js が各 CLI 入力境界で検査

references の実体は2箇所に分かれる。複数の skill が読む共有 references(style-genome.md / short-post-formats.md / expression-variations.md / anti-ai-writing-guide.md / horizontal-vertical-guide.md / title-guidelines.md)は plugin ルートの references/ にあり、run-x-longpost-create だけが読む固有 references は skills/run-x-longpost-create/references/ にある。scripts / assets の実体は plugin ルート直下の scripts/ と assets/ にある(lint-skill-tree 第 10 条が skills/*/scripts/ を .py / .sh に限るため、Node スクリプトは skill 配下に置けない)。他スキルは同一 plugin 内の相対参照で読む。


絵文字の定義(判定境界)

「絵文字」とは Unicode プロパティ \p{Extended_Pictographic} に該当する文字を指す。この意味実装の正本は ../../scripts/lib/text-rules.js である。check-no-emoji.js はファイル/テキスト全体の検査 CLI、validate-title.js と validate-headings.js は各タイトル・見出し境界、build-visual-prompts.js は構造データの全 string leaf 境界で、同じ共有実装を呼ぶ。

判定例
絵文字(禁止)顔文字類、および U+2705 / U+274C / U+26A0 などの記号系絵文字
絵文字ではない(使用可)✓ ✗ ☆ → ▼ ① ※

U+2705 と ✓(U+2713)は見た目が近いが、Extended_Pictographic に該当するのは前者だけである。成果物全体で迷ったら check-no-emoji.js に通す。

共有意味実装を替えてはならない。 \p{Extended_Pictographic} の範囲は処理系とバージョンで変わる。そのため散文の例示から安全性を推測せず、現在の text-rules.js を呼ぶ check-no-emoji.js の実行結果を正本とする。CLI ごとに別の正規表現を再実装せず、全体走査は check-no-emoji.js、個別値はそれぞれの検証 CLI を使う。


数値契約の機械判定先

下表は人間が要件の意味を素早く読むための索引である。合否は「検証コマンド」列の script と visual-spec.json が判定する。

対象正本の値検証コマンド
長文投稿 A/B の文字数1800〜2200文字(中心値2000)count-chars.js --min 1800 --max 2200
投稿9|要約型の文字数400〜499文字count-chars.js --min 400 --max 499
短文投稿(8投稿)の文字数180〜220文字(約200文字)count-chars.js --min 180 --max 220
見出し1(タイトル)の長さ50文字以内(コードポイント数・空白含む)validate-title.js --title "..."
タイトルの字数配分入口26〜32字 + 予告8〜18字—
見出し2の個数3〜8個(check ID H5)validate-headings.js --file <path> --strict-h2-count(既定では H5 は警告止まりのため、本 plugin は常に --strict-h2-count を付ける)
見出し1と見出し2の間のリード文8行・300文字以内validate-headings.js
1行の目安幅(文脈改行)30〜40字程度(文字数ぴったりでは切らない)—
絵文字0個(例外なし)check-no-emoji.js --file <path>
長文 A/B の本文同値Markdown 見出し・先頭タイトル・空白・改行を表示差として除いた本文が同一validate-headings.js --file <path>(F4)
長文 B の改行非空本文行に2文以上を詰めない(【…】 見出し行は対象外)validate-headings.js --file <path>(F5)
長文 B の見出し【見出し文言】 の単独1行で、Aの見出し2と文言・順序が一致(先頭タイトル行と本文行は囲まない)validate-headings.js --file <path>(F6)

移植時に解消した重複・矛盾

元スキル v3.14.0 からの移植で、値が食い違っていた箇所とその決着。

#矛盾していた箇所元の状態決着
1長文の文字数レンジSKILL.md「2000文字以上」/ 実行手順「1800〜2500」/ optimize-length.md §4.7「1800〜2200」1800〜2200 に統一(optimize-length.md の値を採用)
2禁止表現リストSKILL.md・create-title.md・apply-style-genome.md・optimize-length.md の4箇所に実体が重複references/title-guidelines.md §3.3 を唯一の正本とし、他は参照のみ
3制約 ID CONST_0074つの agent が同じ ID を別の意味で使用agent 別プレフィックス(TR- / MP- / SP- / IC-)で一意化
4短文投稿エージェントcreate-short-post.md と short-post-optimizer.md が同一責務で並存x-longpost-short-post-optimizer.md 1本へ統合(§4.5 で2つの呼び出しモードを規定)
5見出し2の個数記述箇所により揺れ3〜8個(validate-headings.js の check ID H5 の実装値を正本)
6emoji-selection-guide.mdv3.3.0 の絵文字全面禁止後も旧名のまま、中身は見出しタイトル作成ガイドheading-title-guide.md へ改名(名実一致)
7出力先の絶対パスSKILL.md・scripts・旧 prompt 群に vault の実パスが直書きskills/run-x-longpost-create/references/output-config.json へ env-only 解決契約を集約。未解決時は fail-closed
8重複・冗長ファイルoutput-template-legacy.md / references/changelog.md / LOGS.md / log_usage.js と log_usage.mjs の2重実装legacy / changelog / LOGS は移植せず(CHANGELOG.md を v1.0.0 から新規開始)。log_usage.mjs は ESM 環境向けとして同梱

Key Rules

  • 規定を追記するときは machine-readable authority にだけ判定値を置き、本ファイルには所在と意味だけを追記する。
  • 参照側から正本を指すときは相対リンクを張り、値そのものを再掲しない(再掲すると drift の起点になる)。
  • 数値を変更するときは対応する spec/script を先に更新し、その後で本索引の意味説明と parity test を追従させる。
  • 散文と判定が食い違った場合は spec/script の判定を実行結果とし、散文側を drift として修正する。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

app-excellence

無料日本語概要

アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。

daishiman/harness-dev102026年10月11日 更新

app-orchestrator

無料日本語概要

Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。

daishiman/harness-dev102026年10月11日 更新

run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。

daishiman/harness-dev102026年10月11日 更新

assign-briefing-evaluator

無料日本語概要

確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。

daishiman/harness-dev102026年10月11日 更新

生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。

daishiman/harness-dev102026年10月11日 更新

Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。

daishiman/harness-dev102026年10月11日 更新

daishiman のスキルをすべて見る

このスキルの問題を報告する