xiaohongshu-article-packager

Xiaohongshu 記事パッケージャー

以下の共有パブリックスキルルールに従ってください：

• postplus-shared パブリックスキルルール

このスキルは、ユーザーが次のことを希望する場合に使用します：

• 元の下書きを公開可能な Xiaohongshu 画像投稿に変換する
• 音声スクリプトをページ分割された画像投稿コンテンツに変換する
• 意見記事をページ、階層、画像の方向性、レンダリング可能なページに変換する
• 元のテキストを保持しつつ、レイアウトやレンダリングに適した構造化されたコンテンツパッケージを生成する

このスキルは レイアウトパッケージング のためのものです。 以下には使用しません：

• プラットフォームのスクレイピング
• 競合リサーチ
• 直接投稿
• 元のテキストに存在しない主張の捏造
• デフォルトでの元のテキストの書き換え

リクエストが主にプラットフォームリサーチに関するものである場合は、skills/20-research/xiaohongshu-research を使用してください。

核心的な考え方

元のテキストを別の文章に変えてはいけません。

作業には2つの層があります：

1. 書き換えなしの構造化
   • 元のテキストを読みやすいページに分割する
   • どの元の行をより大きく強調するに値するか選ぶ
   • ユーザーが並べ替えを求めない限り、元の順序を保持する
2. レンダリングパッケージング
   • ページの役割を割り当てる
   • 画像を配置する
   • クリーンなレイアウト指示またはレンダリング用の HTML/CSS を準備する

デフォルトの目標は：

• 読みやすい
• 元の文言に忠実
• 元の情報密度に忠実
• 元の語り口に忠実

入力

典型的な元の入力：

• markdown ファイル
• 長い段落のダンプ
• トーキングヘッド動画用に書かれたスクリプト
• 粗い箇条書き
• 情報が多すぎる統合メモ

有用なオプション入力：

• 希望するページ数
• 配置する画像アセット
• 希望するビジュアルの方向性
• 出力が次のいずれであるか： カルーセルページまたは1枚の長い画像

これらが欠けている場合は、元のテキストから最小限の安全なセットを推測してください。

出力契約

デフォルトの出力は、以下のセクションを含むパッケージであるべきです：

1. 元のルール
   • 文言が保持されていることを明記する
2. カバーコピー
   • ユーザーが明示的に書き換えを許可しない限り、元の行または元の行の断片のみを使用する
3. ページプラン
   • デフォルトで6〜10ページ
   • 1ページにつき1つの明確な目的
4. ページコピー
   • 各ページに割り当てられた元のテキスト
5. レイアウトブリーフ
   • 下流のレイアウトのための構造化された指示
6. レンダリングファイル
   • 要求された場合のオプションの HTML/CSS

ユーザーがファイルを求める場合は、以下を優先してください：

• 01-outline.md
• 02-titles.md
• 03-pages.md
• 04-caption.md
• 05-layout-brief.md

パッケージを作成する際は references/output-template.md を読んでください。

デフォルトのワークフロー

1. デフォルトで元のテキストを不変として尊重する

ユーザーが明示的に書き換えを求めない限り：

• 言い換えない
• 圧縮しない
• 要約行を追加しない
• CTA 行を追加しない
• 別途キャプションを追加しない

許可される操作：

• ページに分割する
• 元の行を見出しサイズに昇格させる
• 元のテキストの周りで画像モジュールを移動させる
• 中立のページラベルを追加する

2. ページ構成を決定する

デフォルトは 6〜10 ページです。

各ページは1つの役割のみを担うべきです：

• カバー
• 緊張
• 重要な区別
• 証拠または説明
• 結果
• 締めくくりまたは CTA

N 文字ごとに機械的にページ区切りを使用しないでください。 元のテキストの自然な段落または文の境界で分割してください。

3. 書き換えずにページの読みやすさのために書く

各ページについて：

• 1つの主要なポイントを保つ
• 元のソース行を昇格させることによってのみ、目に見えるタイトルまたは強調行を与える
• 密集した壁のようなテキストブロックを避ける
• 最初の2行を、前のページからの文脈なしで読めるようにする

ページが妥当な密度を超える場合は、分割してください。

4. レイアウトを意識したコピーを準備する

下流のレンダラーまたはレイアウトモデルが構造から恩恵を受けると想定してください。

各ページについて、明確に分離してください：

• pageRole
• 使用する場合の元のテキストからの headline
• 必要に応じて subhead
• 元のテキストからの body
• 使用する場合の元のテキストからの emphasisLines

次に、統合されたレイアウトブリーフを準備してください。

ユーザーが参照 PDF のウォームグラデーションカードスタイルを希望する場合は、references/layout-system.md を読んでください。

品質ルール

1. ソース優先

ソースに存在しない権威、事例、指標、個人的なエピソードを捏造しないでください。

2. ステルスな書き換えの禁止

以下を黙って変更しないでください:

• 文のリズム
• 情報密度
• 話し言葉の言い回し
• ユーザー自身の言葉遣いの癖

3. AI らしい整理の回避

ソースを以下に無理やり当てはめないでください:

• きれいな二項対立の公式
• 過度に整理された要約的な言葉
• 自分好みの言い回しパターン

ソースがそう言っているなら、明示的に書き換えを求められない限りそのままにしてください。

4. カバーコピーはソースから

カバーでは以下を使用してください:

• 原文の行
• または原文の行の断片

モデルが新しく考案した見出しではありません。

ヒューリスティクス

良いカバー素材

• 力強い原文の書き出し
• 力強い原文の判断
• 力強い原文の修辞的な問いかけ

弱いカバー素材

• 多くの前振りがあって初めて機能する行
• モデルによる新たな説明を必要とする行

一般的な入力の形

よくあるユースケースは以下です:

• アクティブな作業フォルダまたは近くのプロジェクトディレクトリにある下書き
• 特にトーキングヘッドのスクリプトや創業者・運営者の視点の下書き
• 元の意見を失わずに Xiaohongshu で公開できると感じられる出力が必要

例えば:

• 話し言葉のスクリプト -> Xiaohongshu 画像投稿のページ分割
• 長い意見記事 -> カバー + タイトル + 8 ページの画像投稿
• 創業者からのメッセージ -> 画像投稿で読みやすい形に適したバージョン

デフォルトのファイル配置

ユーザーが出力をディスクに書き込むよう求めた場合は、ソースの下書きの隣に兄弟フォルダを作成することを優先してください。例えば:

<source-dir>/<draft-name>-xhs-package/

出力契約のデフォルトファイル名を使用して、そこにパッケージファイルを保存してください。

公開スキルの実行契約

• ページ計画のメモ、ソースの抜粋、中間のパッケージングファイルは <work-folder>/.postplus/xiaohongshu-article-packager/ の下に置いてください
• 最終的なユーザー向けページパッケージのみを .postplus/ の外に置いてください
• より広範なパッケージングの前に、1 つの下書きと 1 つのパッケージ対象に対して 範囲を限定した最初のパスから始めてください
• ソースが不十分または詳細不足の場合は、不足している素材を捏造したり 顧客固有のパス前提に頼ったりするのではなく、直ちに停止してください

失敗モード

以下の場合、停止してソースが不十分であると伝えてください:

• 明確な主張がない
• 下書きがスローガンだけである
• ユーザーが素材にない主張や事例を期待している

そのうえで、以下のいずれかを提案してください:

• より軽いレイアウトパス
• 追加のソース素材の依頼
• 実際に存在する内容に基づく、より狭いページの選択