script-generator

スクリプトジェネレーター

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

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

このスキルは、ユーザーが以下の用途向けにスクリプト対応の入力を作成したい場合に使用します：

• AI UGC トーキングヘッド動画
• TikTok または Instagram のスライドショーまたはカルーセル広告クリエイティブ
• フックテストパック
• 後からストーリーボードやレンダリングリクエストの作業に渡せるスクリプトバリアント

このスキルは スクリプトオブジェクト レイヤーに位置します。

用途：

• 曖昧なユーザーの依頼を構造化されたスクリプトブリーフに変換する
• 弱いブランド優先または機能優先の入力を修正する
• テスト可能なフックおよびスクリプトのバリアントを生成する
• エビデンスに基づく推奨と暫定ドラフトを分離する
• ストーリーボードまたはリクエスト設計へのクリーンな引き継ぎを準備する

用途ではないもの：

• プロジェクトまたはキャンペーンのファイルスキャフォールドの作成
• ストーリーボードグリッドプロンプトの作成
• プロバイダー対応のレンダリング JSON の作成
• 暫定スクリプトをベンチマークで検証済みの真実であるかのように見せること

中核となる考え方

優れた AI UGC スクリプトは「自然な話し言葉＋製品のベネフィット」ではありません。

それはカジュアルなコンテンツを装ったコンバージョン用スクリプトです。

目標は以下ではありません：

• 「もっと人間らしく聞こえるようにする」
• 「もっとバイラルにする」
• 「もっとプレミアムにする」

目標は以下です：

• 視聴者に一つの具体的な疑問を生み出す
• 広告だと気づかれるまでの時間を遅らせ、注意力を獲得する
• メカニズムや証拠を読み取れるようにする
• 冒頭の緊張感が機能してから初めて製品を明かす
• 1つのアセットにつき1つのコアメッセージを保つ
• テストして後工程に引き継げるスクリプトオブジェクトを出力する

共有ファイルシステムのコンテキスト

references/source-context.md を読んでください。

キャンペーンまたはプロジェクトレベルのソースファイルが存在する場合、それらを安定したコンテキストとして利用します：

• brand.md
• persona.md
• product.md
• hooks.md

これらのファイルは共有の信頼できる情報源（ソースオブトゥルース）入力です。

このスキルはそれらを読み取り、使用することができます。 このスキルはそれらを作成または管理しません。

入力の優先順位

入力を以下の順序で正規化します：

1. 明示的な現在のタスク入力
2. キャンペーンまたはプロジェクトのソースファイル
3. ベンチマークまたはリサーチ成果物
4. ユーザーの自由記述テキスト

ソースファイルが存在するという理由だけで、現在の依頼を無視しないでください。 安定したソースファイルがスクリプトの品質や一貫性を直接向上させる場合、それらを無視しないでください。

最小スクリプトブリーフ

バリアントを作成する前に、依頼を最小限の有用なスクリプトブリーフに正規化します。

必須スロット：

• productOrOffer
• targetUser
• goal
• formatTarget
• corePainOrDesire

重要な補助スロット：

• audienceAwareness
• mechanismOrReasonWhy
• proofAvailable
• ctaStyle
• constraints
• sourceBasis

必須スロットが欠けている場合は、まず最小限の安全なバージョンを推測します。 欠落しているフィールドがスクリプト構造を実質的に変える場合にのみ質問します。

エビデンスルール

エビデンスに基づくスクリプト生成を優先します。

有用なエビデンスソース：

• ベンチマークレポート
• パターンテーブル
• マスターテーブル
• ランディングページ
• 承認済み製品シート
• 承認済みフックライブラリ
• キャンペーンの信頼できる情報源ファイル

エビデンスが不完全な場合、デフォルトで停止しないでください。

代わりに以下を分離します：

• Observed
• Inference
• Open question

その後、ユーザーがまだスクリプトを必要としている場合にのみ、暫定ドラフトを生成します。

暫定ドラフトを検証済みの推奨として提示しないでください。

最初の判断

リクエストが主に以下であるかを判断します：

• ugc_video
• slideshow
• both

汎用的なスクリプトを1つ生成し、それが両方に等しく効果があるかのように見せないでください。

スクリプト品質ルール

references/script-quality-rules.md をお読みください。

すべての出力は、次のデフォルトを強制する必要があります:

• ブランドの紹介ではなく、具体的な視聴者の疑問から始める
• 広告だと感じさせる前に、問題や欲求を示すか示唆する
• フックに役立つ場合にのみ製品を明かす
• アセットごとにコアメッセージを 1 つに保つ
• 結果だけでなく、仕組みを読み取れるようにする
• 説得を二の次にして、まずリテンションのために書く
• ブランディングよりフックを先に
• 説明より好奇心を先に
• 緊張感が効き始めてから製品を出す
• 広範な主張より仕組みを先に
• CTA より証拠を先に
• 巧妙さよりシンプルさを先に

ユーザーの下書きがこれらのルールに違反している場合は、文言を磨く前に構成を修正してください。

標準スクリプトの骨格

使用可能な各スクリプトバリアントは、次の要素に対応させる必要があります:

• Hook
• Problem recognition or desire trigger
• Proof or mechanism
• Product role
• Outcome
• CTA

圧縮は許容されます。

次の要素を完全に欠いた最終バリアントを出力しないでください:

• フック
• 仕組みまたは証拠
• 製品の役割

認知度ルール

バリアントを展開する前に、オーディエンスの認知度ステージを見積もってください:

• unaware
• problem_aware
• solution_aware
• product_aware
• most_aware

次に、以下を確定してください:

• スクリプトが前提としてよいこと
• まだ説明すべきでないこと
• 製品の直接的な言及を早い段階で出せるかどうか

認知度のミスマッチは、単なるコピーの問題ではなく、スクリプトの問題です。

アングルルール

ユーザーが 1 つの固定された切り口を明示的に求めない限り、1 つのアングルだけを書かないでください。

推奨される主アングルを 1 つ選び、それから隣接するテスト可能なバリアントを生成してください。

対応するアングルファミリー:

• pain_recognition
• proof_first
• contrarian
• mistake_correction
• process_reveal
• comparison
• before_after
• identity_or_social_stake

各バリアントは、何をテストしているのかを明示する必要があります。

アングルやフックの役割を変えない些細な書き直しで、ユーザーを圧倒しないでください。

フックと公開のルール

完全なバリアントを書く前に、以下を確定してください:

• viewerQuestion
• hookMechanism
• productRevealRule
• proofRole
• ctaRole

これらが不明確な場合、スキルはすぐに洗練されたコピーへ飛び込むべきではありません。

動画スクリプトモード

次の場合に使用します:

• 人間の信念の移転が重要である
• 説明が重要である
• 製品の扱い方や仕組みを示せる

デフォルトの執筆ルール:

• コピーブロックではなく、話し言葉のように書く
• 短い節を優先する
• 軽い言い直しを許容する
• 次のような自然な表現を許容する:
  • I didn't expect this
  • the weird part is
  • what actually matters is
• 次のような一般的なブランド言語は避ける:
  • revolutionary
  • transforms your routine
  • game-changing
  • seamless
  • 中身のない形容詞の羅列

単一の固定された尺のテンプレートをハードコードしないでください。

代わりに、ペーシングスロットを使用してください:

• opening hook
• specific pain or desire
• product use or proof
• result or payoff
• cta close

推奨ペーシングを含めてもかまいませんが、秒数よりもスロットのほうが重要です。

スライドショーモード

次の場合に使用します:

• コンセプトが視覚的である
• 証拠をカードに分解できる
• 各フレームが小さな好奇心を生み出せる

デフォルトの執筆ルール:

• 1 スライド = 1 つの認知的な役割
• 各スライドを短く、すぐに読み取れるように保つ
• 最初のスライドは好奇心、共感、または緊張感を生み出す必要がある
• スライドの並び全体に進行が存在する必要がある
• スライドのふりをした機能の箇条書きを出力しないでください

このモードは、文の区切りで分割された話し言葉のスクリプト行ではなく、スライドの流れを返すべきです。

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

1. ブリーフを正規化する

最小限で十分なスクリプトブリーフを確定します。

入力が広範な場合は、まず推測し、後で質問します。

2. ソースコンテキストを確認する

最小限で有用なソースコンテキストを読み込みます:

• brand.md — ボイスの境界、禁止フレーズ、ポジショニングのため
• persona.md — ナレーターの信頼性と製品との関係のため
• product.md — 主張、仕組み、反論、証拠のため
• hooks.md — テスト済みの型、反復防止、バリエーションの方向性のため

ファイルが欠けている場合は、その結果を書き留めてください。 欠けているファイルをデフォルトでブロッカーとして扱わないでください。

3. バリアントの前に戦略を固定する

次の内容を出力するか、筋道立てて検討してください:

Format target:
Audience awareness:
Primary angle:
Support angles:
Viewer question:
Hook mechanism:
Product reveal rule:
Proof role:
CTA role:
Main source basis:
Confidence level:

4. バリアントを生成する

デフォルトの出力セット:

• 8〜12 個のフック
• ugc_video がスコープに含まれる場合は 3〜5 個の動画スクリプトバリアント
• slideshow がスコープに含まれる場合は 2〜3 個のスライドショーフロー

各バリアントには次を含める必要があります:

• variantId
• angle
• whatIsBeingTested
• hook
• scriptFlow
• whyThisShouldWork
• mainRisk

5. スクリプト QA ルーブリックを実行する

すべての最終出力には次を含める必要があります:

• Viewer question clear?
• Ad feeling delayed enough?
• Product reveal timing ok?
• One core message only?
• Mechanism legible?
• Proof concrete enough?
• CTA soft enough?
• Video-native or slideshow-native?
• Main drift risk

バリアントが依然として弱い場合:

• 返す前に修正する、または
• なぜ弱いままであるかを明示的に述べる

ユーザーが書いたという理由だけで、弱いドラフトをそのまま通してはいけません。

6. 下流へのハンドオフを返す

次のスキルを 1 つだけ提案してください。

典型的な次のステップ:

• シーンのロジックをパネルにすべき場合は storyboard-grid-writer
• スクリプトがリクエスト計画に十分安定している場合は video-request-architect
• プロンプトのドラフトがすでに存在し、診断が必要な場合は prompt-preflight-qa

出力形状

タスクにとって最小限の有用な組み合わせを返してください。

一般的な形状:

• script brief summary
• script strategy block
• source context
• hook library
• video script variants
• slideshow flow variants
• qa block
• downstream handoff

スクリプト戦略ブロック

次を含める必要があります:

• goal
• formatTarget
• audienceAwareness
• primaryAngle
• supportAngles
• hookMechanism
• viewerQuestion
• productRevealRule
• proofType
• softCtaRule
• sourceBasis
• observed
• inference
• openQuestions
• mainDriftRisks

ソースコンテキスト

次を含める必要があります:

• brandContext
• personaContext
• productContext
• hookContext
• confidenceLevel

次のような値を使用してください:

• from brand.md
• from persona.md
• from product.md
• from hooks.md
• from benchmark patterns
• from landing page
• from user input
• missing

信頼度レベル:

• grounded
• partially_grounded
• provisional

アンチパターン

以下を行わないでください:

• 視聴者の疑問がまだ得られていない段階でブランド名から始める
• 1 つのアセット内に複数の無関係な約束を保持する
• 何が販売されているのか視聴者にわからなくなるまで製品の役割を隠す
• メカニズムを曖昧な成果の主張に置き換える
• コピーの箇条書きのように読めるスライドショー出力を出す
• 広告のパンフレットのコピーのように読めるトーキングヘッド出力を出す
• hooks.md が生のライブラリにすぎないのに、検証済みのパフォーマンスの真実として黙って扱う

失敗モード

次の場合には停止するか、明確に警告してください:

• スクリプトの指定が不十分で、構造が変わる場合
• ユーザーが 1 つのアセットにあまりに多くのメッセージを詰め込みたがっている場合
• 信憑性のあるメカニズムや証拠が存在しない場合
• スクリプトが依然として、クリエイターネイティブな語りではなくブランドが話しているように聞こえる場合
• 出力形式がプラットフォームの役割に合っていない場合

そのうえで次を提示してください:

• 最も近い使用可能な修正版
• 未解決の主なリスク
• 次に正直に打開するための要素