公众号文章排版引擎

公众号文章排版 Skill

一篇 Markdown 文章を、微信公衆号エディタに直接コピー＆ペーストしてもスタイルが失われない HTML に変換します。

中核となる資産は references/ ディレクトリ以下のテーマコンポーネントライブラリ（各テーマ：デザイン変数＋各コンポーネントの完全な HTML＋テンプレート骨格＋マッピングルール）と、汎用インクリメンタルライブラリ（コードブロック／画像・GIF／小ラベルタイトル、全テーマ共通）の 1 セットです。テーマ一覧は references/theme-index.md を唯一の情報源とします。本 SKILL.md はフローと決定のみを担当し、具体的な HTML コードはすべてコンポーネントライブラリから取得し、記憶に頼って手書きしないでください。

ワークフロー

0. 入力とフォーマットの正規化

ユーザーから提供される可能性があるもの：Markdown テキストまたは .md ファイルパス（そのままステップ 1 へ）、.docx、.pdf、.txt/マークアップなしプレーンテキスト、Web リッチテキスト。Markdown 以外の入力は、まず references/format-normalize.md を読み、そのルールに従って Markdown ドラフトに変換し、構造を確認する必要があります（docx は scripts/extract_docx.py を使用、PDF は Read でページごとに読み取りノイズ除去、プレーンテキストは見出しからヒューリスティックに構造を推定）。何も提供されなかった場合は、ユーザーに要求します。

ユーザーが「直接排版 / 自動排版 / ワンクリック / 質問不要」と明示した場合は、全自動モードに移行します：構造確認とテーマ選択の質問をスキップし、自動で構造を推定、題材に応じてテーマを選択、排版チェックを行い、納品時に決定理由（章構成、自擬タイトル、テーマ選択理由）を添付します。

1. テーマ選択（自動推薦制）

references/theme-index.md（テーマ情報の唯一の情報源）を読みます。記事の題材に基づいて最も適したテーマを能動的に推薦し、ユーザーにワンステップで確認を取ります——推薦はするが、勝手に確定はしません：

• ユーザーがすでにリクエストでテーマを指定している → そのまま使用、質問しない。
• 題材に明確な適合がある → 単一質問で確認：「XX（理由）をおすすめしますが、確認しますか？それとも別のものにしますか？」選択肢として推薦項目＋1～2 つの代替案＋「すべて見る」を提示。題材→テーマの適合参考（theme-index の「適用シーン」列）：
  • チュートリアル / レビュー / チェックリスト / ツール総ざらい / 知識整理 / 方法論解説（情報密度が高い）→ 摸魚綠
  • 深層分析 / 意見 / 力強い話題 → 紅白色系
  • デザイン / テクノロジーレビュー / 専門的意見 / ハイエンドブランド → 石墨極簡風
  • 禅 / ミニマルライフ / 深いエッセイ → 留白禪意風
  • ツール比較 / クリエイティブレビュー（領収書の視覚的メタファー）→ 摸魚票據風
  • 社内報メモ / 深層レビュー / ケーススタディの振り返り → 橄欖手記
• 明確な傾向がない → デフォルトでは theme-index の最初の行（摸魚綠）を推薦項目として最初に配置し、AskUserQuestion を使用してユーザーにいくつかのテーマから選んでもらいます（テーマが 4 つを超える場合は、まず雰囲気ごとにグループ化して質問し、そのグループ内のテーマについて再度質問）。
• 全自動モード（ユーザーが「直接排版 / ワンクリック / 質問不要」と明示）→ 質問せず、題材に最も合致するテーマまたはデフォルトの最初の行を自動選択し、納品時に選択理由を説明。
• ユーザーが既存のテーマに満足しない / 新しいスタイルを希望する → 「カスタムテーマ生成」フロー（次節参照）に進み、生成して登録した後、このステップに戻って選択。
• theme-index が空 → 排版を停止し、まずテーマスタイルを追加する必要があることをユーザーに通知（「カスタムテーマ生成」に進むことができます）。

ユーザーがテーマを決定した後、そのテーマ内部のコンポーネントマッチング（ステップ 3、4：記事タイプの判定 → そのテーマのレシピテーブルに従ってコンポーネントの組み合わせを選択）に進みます。

2. コンポーネントライブラリの読み取り（2 つ）

(1) theme-index のそのテーマの「コンポーネントライブラリファイル」列に従い、そのテーマ専用のコンポーネントライブラリ references/theme-{識別子}.md を読みます（イントロダクションカード、セクション見出し、本文マーキング、署名など、テーマ専用コンポーネントを含む）。 (2) 同時に汎用インクリメンタルライブラリ references/common-components.md を読みます——コードブロック、画像/GIF、小ラベルタイトルの 3 種類は全テーマ共通で、現在のテーマのメインカラーを適用するだけです。

以降の生成は、これら 2 つのコンポーネントライブラリに完全に基づき、HTML はすべてこれらから取得し、手書きしません。

3. Markdown 構造の解析

要素	識別ルール
記事タイトル	# タイトル または frontmatter title
冒頭のイントロダクション	記事の先頭にある > 引用 ブロック
セクション見出し	## 見出し
サブセクション	### 見出し
太字 / ハイライト / 下線	**文字** / ==文字== / <u>文字</u> または ++文字++
引用段落	冒頭以外の > 文字
画像 / GIF	、（GIF は画像と同様に処理）
コード / コマンド / Prompt	``` フェンスコードブロック ```、インライン `code`
区切り線 / リスト	---、*** / - 項目 または 1. 項目
テーブル	| で区切られた Markdown テーブル（docx 変換から来ることが多い）→ 優先的にテーマライブラリのテーブル/カードコンポーネントを使用（テーマライブラリのマッピングルールに従う）

構造の解析後、記事タイプを判定します（支配的なタイプを取得、複合可）：チュートリアル/操作ガイド、総ざらい/ツールチェックリスト、意見/深層分析、インタビュー/人物特集、データ振り返り/レポート、ライフ/感情エッセイ、ケーススタディ。判定基準：手順とコマンドが多い→チュートリアル；並立する項目が多い→総ざらい；引用と人物の語りが多い→インタビュー；数字と比較が多い→データ；論証と推論が多い→意見。

4. レシピに従ってコンポーネントの組み合わせを選択 → HTML を組み立て

まず選択したテーマライブラリの「記事タイプ → コンポーネント組み合わせレシピ」テーブルを確認し、記事タイプに応じて本篇のコアコンポーネントの組み合わせとアクセントコンポーネントを決定します——コンポーネントライブラリを取得したら、段落ごとにランダムにコンポーネントを選択しないでください。レシピにより、同じタイプの記事の排版スタイルの一貫性が保証されます。レシピ以外の要素は、テーマライブラリのマッピングルールテーブルに従って補完します。

次に、テーマライブラリの**「完全な記事テンプレート骨格」セクション**に従って組み立て、各 Markdown 要素を対応するコンポーネントに置き換えます：

• 骨格の順序はテーマライブラリに従います。テーマによって骨格が異なる場合があるため、他のテーマの骨格を流用しないでください。
• インラインマーキングは意味に応じて、選択したコンポーネントライブラリ内の対応するコンポーネントを検索します（コンポーネント番号はライブラリごとに統一されていないため、常に意味に基づき、固定番号を流用しないでください）：**太字**→メインカラー太字；==ハイライト==→純色薄背景ハイライト；<u>文字</u> または ++文字++→下線；~~文字~~→蛍光ペン（純色薄背景）；>引用→引用ハイライトブロック。
• 汎用インクリメンタルライブラリからのコンポーネント：``` コードブロック ``` → 1a ダーク / 1b ライトコードブロック、インライン `code` → 1c；![説明](url) → 2a 画像（説明がある場合のみ説明コンポーネントを追加）、.gif → 2b GIF；強調が必要な小見出し/強調 → 3a 左縦棒小見出し または 3b ピルタグ、金言 → 3d、ヒント注釈 → 3e。優先順位：まずテーマライブラリのマッピングルールテーブルを確認——そのテーマに同等の意味を持つコンポーネント（自身の金言/ヒントブロックなど）がある場合は、スタイルの一貫性を保つためにテーマライブラリのバージョンを使用します；テーマライブラリに対応するコンポーネントがない場合のみ、汎用ライブラリの 3x を使用し、その色変更ルールに従ってテーマカラーに変更します。
• 1 つの記事では、選択したテーマのコンポーネントのみを使用し、テーマをまたいで混在させないでください。
• 強調と小見出しには「小ラベル/左縦棒」を使用し、破線枠を使用しないでください：小見出しや一部の内容を強調する場合は、左縦棒小見出し（3a）、ピルタグ（3b）、左縦棒金言/ヒントブロック（3d/3e）を使用します；タイトルを囲む四周の破線枠（dashed border）は使用しないでください。重くて目立ちすぎます。

5. コンプライアンスチェック（必須）

生成された HTML をターゲットファイルに書き込んだ後、必ずチェックスクリプトを実行し、ERROR がゼロになって初めて完了とします：

# スクリプトがあるスキルの絶対パスを呼び出し、HTML パラメータもその実際のパスを使用します（両方のディレクトリは通常異なります）
<SKILL_ROOT>/scripts/validate_gzh_html.py <生成された.html の実際のパス>

これは、プラットフォームで禁止されている項目と <span leaf> ラッピングを確定的にチェックします。ERROR が報告された場合は、ステップ 4 に戻って修正します；半角句読点の WARNING もゼロになるまで修正してから納品します（これは実際の使用で最も頻度の高い修正ポイントです）。

グラデーション背景の WARNING は項目ごとに処理します：文字ハイライト、引用/データ/ガイドカードの背景は、デフォルトでテーマ内の純色または rgba 純色に変更します；ユーザーが明示的に保持を要求した場合、納品時に darkmode-no-gradient ポップアップが発生する可能性があることを注記します。純粋な装飾的なグラデーションも警告が表示されますが、まだポップアップが発生することが確認されていないため、保持する場合は同様にリスクを説明します。

6. 出力

成果物フォーマット：純粋な <section>…</section> 本文フラグメント。グローバルコンテナから開始し、<!DOCTYPE>/<html>/<head>/<body> でラップしないでください——公衆号エディタは本文フラグメントのみを受け付け、余分なドキュメントシェルは破棄されるか、貼り付けに干渉します。

1. クリーンな本文ファイル：HTML を現在の作業ディレクトリに保存し、ファイル名は {元のファイル名}_排版_{テーマ中国語名}({英語識別子}).html とします（英語識別子 = theme-index のコンポーネントライブラリファイル名から theme- プレフィックスと .md 拡張子を除いたもの）。このファイルはチェックと手動貼り付けのための保険として使用します。
2. 「コピー」ボタン付きプレビューページ（ユーザーがワンクリックでコピーでき、手動での全選択が不要）：

   <SKILL_ROOT>/scripts/wrap_preview.py <上記のクリーンな本文.html>
   

   出力 {...}_预览.html——ブラウザで開くと、右上隅に「公衆号にコピー」ボタンがあり、クリックするとレンダリングされたリッチテキストがクリップボードにコピーされます（Ctrl+A/Ctrl+C と同等）。その後、公衆号エディタで Ctrl/⌘+V で貼り付けます。ボタンとスクリプトはプレビューシェル内にのみ存在し、コピーされる section 内には含まれません。そのため、公衆号に貼り付けられるものは、依然としてクリーンでコンプライアンスに準拠した本文です。
3. ユーザーに伝える：{...}_预览.html を開く → 右上隅の「コピー」をクリック → 公衆号エディタに貼り付け。また、保険としてクリーンな本文ファイルのパスも提供します。チェックスクリプトの結論（合格 / 残りの warning）を添付します。

生成時のインテリジェント処理（このスキルの特徴であり、必ず実行すること）

1. セクション自動番号付け：## の出現順に 01/02/03… を割り当てます；最終章が結語/まとめタイプの場合は、テーマライブラリで指定された結語番号バリアント（例：∞）を使用し、テーマライブラリで指定がない場合は数字番号を継続使用します。
2. 英語ラベル：中文セクション見出しから英語ラベルを生成します（実測→TEST、教程→TUTORIAL、总结→SUMMARY、思考→THOUGHTS…）。テーマライブラリに対応するスロットがある場合に使用します。
3. 本文キーワード下線（中核的特徴）：各本文段落について、能動的に 1～3 個の最も重要なフレーズを見つけ出し、そのテーマの下線 CSS（theme-index 参照）でマークします。中核的な意見、結論、重要なデータ、固有名詞を優先的にマークします；フレーズは 4～15 文字；段落全体に要点がない場合はマークしなくても構いません。原文に太字がまったくなくても、能動的に下線を追加します——これは出現頻度が最も高い基本的なマークです。
4. イントロダクションキーワードハイライト：冒頭の金言から中核的な単語を識別し、ハイライトコンポーネントでマークします。
5. 目次抽出：すべての ## から最初の 3 つを抽出し、ガイド/目次のポイントとします（テーマライブラリに目次コンポーネントがある場合）。
6. 冒頭のイントロダクションカードの署名：記事の著者またはテーマに基づいて決定します——記事に署名がある場合は「—— 著者名」と書き、明確な著者がいない場合はテーマに関連する短い署名にするか、省略します。決して「甲木」と固定で書かないでください（末尾の署名エリアも {{著者名}} プレースホルダーを使用します。第 7 条参照）。
7. 末尾の著者署名エリア（著者が自分で記入、末尾の 1 か所のみ）：デフォルトでは誰の名前もハードコードせず、プレースホルダー署名を使用してユーザーが自分のものに置き換えられるようにします。
   • 1 行目（著者紹介）：私は {{著者名}}、{{一言紹介、例：AI の知見とノウハウを共有することに情熱を注いでいます}}——ユーザーがリクエスト/好みで署名や紹介を提供した場合は、そのまま記入します；提供されなかった場合は、{{著者名}} / {{紹介}} のプレースホルダーを保持し、納品時にユーザーに自分の署名に置き換えるよう促します。
   • 2 行目（インタラクション促進、汎用的にそのまま保持可能）：今日の記事が役に立ったと思ったら、**「いいね」「在看」「転送」**の三連をお願いします。また次回お会いしましょう
   • 原文の末尾にすでに著者署名段落がある場合（例：「我是 XXX…」）→ 原文の署名をそのまま使用し、プレースホルダーに置き換えません。
8. リスト変換：テーマライブラリのマッピングルールに従って処理します；専用のリストコンポーネントがない場合は、インデントされた本文段落に変換します。
9. 中文全角句読点：本文の句読点は一律全角（，。！？：；""''（）—— …）を使用し、半角の , . ! ? : や英語のストレート引用符 " ' は使用しません。HTML 生成時に直接カーブ引用符 ""'' を使用し、ストレート引用符を書いて後から置き換えることはしません——原文のストレート引用符は書き換え時にその場で変換します。例外：コードブロック、インラインコード、英語固有名詞/URL/コード識別子の内部は元のまま保持します。

視覚的階層（3 段階の段階的強調、全テーマ共通）

階層	役割	頻度	手段
アンカー階層	最強のアンカー：製品名/手順/CTA/中核的金言	全文 ≤ 5 か所	メインカラー太字、ダーク背景白文字引用
マーキング階層	本文キーワード、各段落 1～3 か所	高頻度	下線マーキング
コンテナ階層	引用ブロック、コンセプトタグ、長文強調	必要に応じて	薄背景引用、蛍光ペン、バッジ

プラットフォームレッドライン（中核、完全なチェックはチェックスクリプトに任せる）

• 禁止：<style>/<script>/<div>、class/id 属性、position:fixed/absolute/sticky、float、@media/@keyframes、display:grid、CSS 変数、外部フォント/CSS。
• 必須：スタイルはすべてインライン style；すべてのテキストノードは <span leaf="">テキスト</span> でラップする（そうしないと貼り付け後にスタイルが失われる）。
• 使用可能：display:flex（制限あり）、border-radius、box-shadow、<section>/<p>/<span>/<strong>/<img>/<h3>。
• グラデーション背景の互換性：グラデーションはレンダリング可能ですが、公衆号の darkmode-no-gradient コンテンツ構造検出をトリガーする可能性があります；文字とカードの背景はデフォルトで純色を使用し、グラデーションは追加しません。古いコンポーネント/カスタムテーマでこれに遭遇した場合も、ステップ 5 に従って処理します。

Gotchas（実際の排版で踏んだ落とし穴）

• <span leaf> ラッピングの漏れが最も一般的な致命的エラーです——公衆号に貼り付けた後、スタイルがすべて失われます。ステップ 5 のチェックスクリプトでカバーするので、スキップしないでください。
• 下線：段落ごとに実行し、各段落 1～3 個のフレーズ。段落全体に線を引かないでください（焦点がぼけます）。また、ある段落にはマークし、別の段落には漏れることがないようにしてください；リスト項目のキーとなる説明にも同様にマークします。
• セクション番号の乱れ：厳密に ## の順序に従い、番号を飛ばさないでください；結語番号バリアントは最終章にのみ使用し、中間の章では使用できません。
• 署名エリアは末尾の 1 か所のみ：固定の文案を使用し、中間や複数箇所に表示しないでください；原文の末尾にすでに著者署名/「点赞在看转发三连」タイプの段落がある場合は、それらを識別して統合し、この唯一の署名エリア/CTA カードにまとめ、原文の段落を残したままさらに生成しないでください。
• 画像説明の捏造：![説明](url) に実際に説明テキストがある場合のみ、説明コンポーネントを生成します；![](url) の空の alt に対して説明を捏造しないでください。
• 画像はアダプティブ、引き伸ばさない：<img> は一律 max-width:100%;height:auto;display:block;margin:0 auto——画像自身のサイズで表示、中央揃え、大きな画像はコンテナ幅に収め、小さな画像は元のサイズを保持します。width:100% は使用しないでください（小さな画像も引き伸ばされてぼやけます）；テーブル/カバーカード/フローチャートなどのレイアウト要素のみ width:100% を使用します。
• テーマをまたいだコンポーネントの混在：1 つの記事では、選択したテーマ + 汎用ライブラリのコンポーネントのみを使用し、他のテーマからコンポーネントを借りてきません。
• アンカー階層の滥用：最強の強調は全文 ≤ 5 か所。あちこちに太字があると、重点がなくなります。
• 原文内容の欠落：各段落、各画像を変換し、欠落がないようにします；原文の実質的な内容を勝手に追加または削除しないでください。
• プレースホルダー画像の残留：署名エリア/CTA コンポーネントに名刺画像のプレースホルダー（例：<img src="...名片或引导图URL">）が含まれている場合、実際の画像 URL がない場合はその行全体を削除し、プレースホルダーを成果物に残さないでください。
• 目次は厳選であり、全量ではない：前書きガイド/目次コンポーネントは厳選された 3 つの中核的な見どころを表示し、完全なセクションリストではありません；セクションが 3 つを超える場合は、最も重要な 3 つを選び、無理に詰め込んだり、読者に 3 章しかないと誤解させたりしないでください。
• 破線枠を使用しない：見出し/強調を目立たせるには、小ラベルまたは左縦棒（汎用ライブラリ 3a–3e）を使用し、border:…dashed の四周破線枠で見出しを囲まないでください。例外：テーマライブラリで明確に定義された破線コンポーネント（摸魚綠 の quote-box 引用枠、oneliner-card 亮点カードなど）は、そのテーマのスタイル特徴であるため、テーマライブラリの用法に従って通常通り使用します。
• 句読点を半角と混在させない：本文に半角カンマ、ピリオド、英語のストレート引用符 " ' が現れた場合は、すべて全角に変更します；ただし、コードブロック/インラインコード内の半角記号はそのまま保持し、コードを「全角化」しないでください。
• コード/Prompt は必ずコードブロックを使用：記事内のコード、コマンド、プロンプトワードは、汎用ライブラリのコードブロックコンポーネント（1a/1b）を使用し、通常の段落や引用ブロックに詰め込まないでください。そうしないと、インデントと等幅が失われます。
• コードブロックはコンパクトに、大きな空白を避ける：汎用ライブラリ 1a/1b の「各行に 1 つの <p style="margin:0">」という書き方を使用し、決して white-space:pre を使用しないでください——これは HTML ソースコード内の span 前のインデントと行間の改行をそのままレンダリングし、大きな左インデント + 空行を生み出します；インデントには全角スペース 　 のみを使用し、行間は line-height:1.6 に依存します。
• 未完成素材は中央揃え：【插入…】、録画待ち/GIF/動画/成果画像などのプレースホルダーは、汎用ライブラリの 2c 中央揃え素材プレースホルダーブロック（薄背景柔らかい破線枠 + 中央揃えアイコンと説明）を使用し、左揃えのヒントブロックは使用しないでください。

カスタムテーマ生成（第 2 のワークフロー）

ユーザーが組み込みテーマ以外の新しいスタイルを希望する場合（「新しいテーマを生成 / カスタムスタイル / この参考画像をもとにコンポーネントライブラリを作成」と言う、または既存のテーマに満足しない場合）、references/theme-generator.md を読み、そのフローに厳密に従って実行します：

1. 好みを収集：テーマの説明は必須（または参考画像）、名前/ID/五色/フォント/3 種類の TAG/角丸/影は空でもよく、自動補完されます；一度にすべて質問し、フィールドごとに追跡質問しません。
2. ブロックライブラリ HTML を生成：theme-generator.md 末尾の【生成プロンプトワード】をそのまま実行し、45～75 個の Block からなる完全なブロックライブラリを生成し、assets/theme-previews/{theme-id}.html に保存します——すべてのブロックが同一ページに連続して配置され、ユーザーはブラウザでページ全体を一度に閲覧してスタイルを確認し、ブロックごとに確認することはありません。
3. 変換 + 登録：ユーザーがスタイルを確認した後、標準形式の references/theme-{識別子}.md に変換します（必ず <span leaf=""> ラッピングを追加し、プレビュー用の id を削除し、5 つのセクションを補完します。ルールの詳細は theme-generator.md のステップ 3 を参照）。theme-index.md に登録し、component_lint.py を実行して ERROR を 0 にします。
4. 納品後、そのテーマは常駐の選択可能なテーマとなり、以降の排版は組み込みテーマと完全に同等の権限を持ちます。

生成段階ではプロンプトワードのルールに従います；テーマライブラリへの変換段階では、本ファイルの「プラットフォームレッドライン」と「新しいテーマ追加の規範」に従います（両者が矛盾する場合、テーマライブラリが排版成果物を直接決定するため、後者が優先されます）。

新しいテーマ追加の規範

新しいテーマは references/theme-{英語識別子}.md という名前で、内容には以下が必須で含まれていなければなりません：

1. デザイン変数クイックリファレンステーブル（メインカラー/薄背景/ダークテキスト/見出し色/本文色/区切り線色など）
2. 各コンポーネントの完全な HTML（インラインスタイル + <span leaf=""> ラッピング、上記の「プラットフォームレッドライン」に従う）
3. 完全な記事テンプレート骨格（コンポーネントの組み立て順序；ディレクトリ/ナビゲーションコンポーネントがある場合は、カバー/イントロダクションに対する相対的な位置を明確にする）
4. 記事タイプ → コンポーネント組み合わせレシピテーブル（各記事タイプのコアコンポーネントの組み合わせ + アクセントコンポーネント。レシピは排版スタイルの一貫性の鍵）
5. Markdown → コンポーネントマッピングルールテーブル

追加後、references/theme-index.md に 1 行登録し（テーマ名 / メインカラー / 適用シーン / コンポーネントライブラリファイル / 本文下線 CSS）、python3 scripts/component_lint.py . を実行して、コンポーネントライブラリにアンチパターンがないことを確認します（ERROR 0）。

トリガーとテーマ選択の回帰テストケースは references/eval-cases.md にあります（メンテナンス時に回帰確認用であり、単回の生成には影響しません）。