mcpField
C
campaign-planner

campaign-planner

github.com/aaron-he-zhuマーケティング・グロース3.0k1.1k 回インストール今日更新
リポジトリ

campaign-planner について

campaign-plannerは、インフルエンサーキャンペーンを戦略から実行計画まで設計するスキルです。マーケティング担当者向けに、提供された目標や根拠を計画にまとめ、不足する判断材料を明示します。

主な機能

  1. 01キャンペーン目標と戦略の設計
  2. 02インフルエンサーの選定基準と構成
  3. 03コンテンツと日程の計画
  4. 04予算とKPIの設計
  5. 05実行トラッキングモード

活用シーン

  1. 01製品ローンチ向け施策の作成
  2. 02提示された予算に基づく配分計画
  3. 03不足している施策判断の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/aaron-he-zhu/aaron-marketing-skills --skill campaign-planner

インストール後、Claude Code で/campaign-plannerを入力して読み込まれたか確認します。

同梱ファイルreferences/influencer-tiers.mdreferences/templates.md

詳細

キャンペーンプランナー

戦略から実行計画まで、インフルエンサーキャンペーンを設計します。ビジネス目標とクリエイティブの実行を結び付ける、実行可能な青写真です。

対象範囲の境界 — 製品ローンチ:このスキルが担うのは、ローンチにおけるクリエイター領域です。ローンチ自体(ティア/タイプの決定、ローンチカレンダー、プレス施策、コミュニティのローンチ当日、準備完了ゲート)は、ローンチの専門領域(launch-tier-plannerおよび関連スキル)が担います。そこから、このスキルにはlaunch-registryの日付とステージに沿った、クリエイターチャネルのサブプランが渡されます。「クリエイターと製品をローンチする」場合はここから始め、「製品をローンチする」場合はそちらから始めます。

クイックスタート

Create an influencer campaign plan for [product launch]
Plan an influencer campaign for [brand] with [budget] targeting [audience] during [timeframe]

スキルの契約

  • 読み取り: 要求されたモード(plan-only | tracker-only | both)、プラン作成のためのブランド、製品、オーディエンス、キャンペーン種別、予算、タイムライン、制約事項。また、実行可能なトラッキングのために、既存の campaign_id、正確なバージョン付きキャンペーンプランの参照/ハッシュ、ロックされた §8 測定契約、ロックされた空でないクリエイタースコープ。memory-management が有効な場合、過去のオーディエンスプロファイルと過去キャンペーンのベンチマークがホットキャッシュから読み込まれます。
  • 書き込み: デフォルトではキャンペーンプランをインラインで出力します。正確な保存承認があれば、memory/influencer/campaign-planner/YYYY-MM-DD-<topic>.md に書き込みます。実行トラッキングでは、共有の5種類のコントロールスキーマ(エビデンスの観察、ロックされた測定契約、実際の実行者アクションに対するアクションインテント/レシートのみ、およびサイクルレトロ)に対して検証される個別の JSON アーティファクトを出力し、その後コントローラーがそれらの正確な参照/ハッシュを選択された実行系統にバインドします。references/templates.md §10 の Markdown/YAML トラッカーは、決定論的な読み取り専用の Influencer 互換ビューであり、authoritative: false とマークされます。そのドメインブロック自体はスキーマ検証済みのコントロールアーティファクトではなく、それらを編集してもランタイム状態は決して変わりません。バリデーターを持たないスタンドアロンホストは、正確な WARM 承認の後にセマンティックのみの互換スナップショットを保存できますが、NOT_VERIFIED とマークする必要があり、単一ヘッド、レシート、永続性、クローズ強制を主張することはできません。明示的な上流/ユーザーの campaign_id を再利用します。プラン作成モードでは、存在しない場合にランダムな campaign-<UUIDv4> を1つ生成し、系統を通じて保持します。tracker-only は、欠落している ID、プラン、契約、スコープ、チェックポイントを決して捏造しません。すべての行は安定した不透明な creator_ref を保持し、保存されたすべての live_post_ref は修飾リゾルバーに裏付けられた不透明なものです。生の名前、ハンドル、URL、ショートコード、プロバイダー ID、隠されたロケーターマップは一時的なままです。
  • プロモート: 別途の正確な承認がある場合にのみ、承認されたキャンペーン名、目的、予算、公開日、KPI ターゲットを memory/hot-cache.md にプロモートします。トラッカーのステージや支払い状態をプロモートすることは決してありません。クリエイター行がクローズされた後、エビデンスに裏付けられた実効レート、署名済み権利ウィンドウ/有効期限、または測定されたパフォーマンスベースラインを含む各レジストリ提案には、別途の正確な承認が必要です。それらの事実を正規化できるのは creator-registry のみです。予測ターゲット、stage、next_action、due_at、payment_status は WARM の作業状態のままです。
  • 完了条件:
    • 選択されたモードが明示されている: plan-only は §§1〜9 を完了し、tracker-only は必須の既存入力から §10 のみを完了し、both は §10 の前に §§1〜9 を完了します。
    • プラン作成モードでは、目的、戦略、インフルエンサー構成、成果物、タイムライン、予算配分、コンティンジェンシー、KPI は、ユーザーが提供した場合、または互換性のあるソース日付付きプランニングアンカーがそれを裏付ける場合にのみ具体化されます。裏付けのない必須の選択はすべて NEEDS_INPUT のままであり、スキルがリポジトリのデフォルトからそれを埋めることは決してありません。§8 の測定設計は、そのキャンペーン/プランバインディング、不変のプランハッシュ/バージョン、承認、空でないクリエイタースコープ、およびクリエイター/成果物ごとの一意のチェックポイントが存在する場合にのみ実行ロックされます。そうでない場合は、正確なロック入力を NEEDS_INPUT/DONE_WITH_CONCERNS として報告し、クローズ適格なトラッカーを作成しません。
    • トラッキングが要求された場合、各クリエイターは検証済みのソースアーティファクトと、ステージ、次のアクション、期日、権利有効期限、エビデンス参照、外部支払いハンドオフ状態を含む1つの決定論的な非権威プロジェクションブロックを持ちます。プロジェクションはそのソースアーティファクトの参照/ダイジェストと現在のヘッドを保持し、状態ソースとして手動編集されることは決してありません。
    • 各トラッカークリエイターは1つの安定した不透明な creator_ref を使用します。すべてのアイデンティティ解決、公開、終端チェックポイント解決、クリエイタークローズ、キャンペーンクローズ、マイグレーション、遅延イベントは、不変の参照と正確なキャンペーン/クリエイタースコープ、および該当する場合は単一の非分岐の現在のヘッドを持ちます。
    • 保存されたすべての live_post_ref は不透明で、修飾リゾルバーに裏付けられています。外部アクションには現在の正確な権限と一致するインテント/レシートアーティファクトが必要です。以前の保存、プラン、ゲート、パス、ケイパビリティ、プロジェクションが権限を付与することは決してありません。生の投稿ロケーターと再利用可能な包括承認がアーティファクトセットやプロジェクションに入ることは決してありません。
    • トラッキング対象のライブ投稿は、必要なチェックポイントごとにレシートを持ち、各チェックポイントの最新の明示的に非スーパーシードされたレシートがクローズゲートを制御します。不一致、不明な開示、または変更/削除された投稿はレビューのためのエビデンスであり、承認済みとして黙って扱われることは決してありません。
    • クローズされたクリエイター行は、その一意の現在のクローズレシートヘッドを指します。クローズされたキャンペーンは、一意の現在のキャンペーンクローズヘッドを指し、ロックされた空でないクリエイタースコープとの正確な等価性を証明し、テンプレート §10 の厳格なゲートを通過します。どちらの closed 値も成功の同義語として扱われることはありません。
    • 重大な遅延イベントは、以前のレシートを書き換えることなく追記されます。参照修正は、修正後のゲートが依然として通過する場合に新しいクローズレシートを追記します。失敗したゲートが通過レシートを受け取ることはできず、手動での再オープンは、テンプレート §10 のステージ/アクションベースラインの下での新しいキャンペーン所有作業のために予約されています。
    • プラン作成の結果は、ブリーフ生成と未解決の承認を明示します。トラッカー専用の結果は代わりに、現在のステージが示唆するエビデンス/アクションのオーナーを明示するか、何も残っていない場合はチェーン完了として停止します。デフォルトでブリーフ生成に逆戻りすることは決してありません。
  • 主要な次のスキル: plan-only/both では、brief-generator。tracker-only では、Next Best Skill のステージ固有のハンドオフを使用するか、完了時に停止します。
引き継ぎの概要

skill-contract.md §Handoff Summary Format に記載された標準形式で出力してください。

データソース

このファミリーは Tier 1 です。すべてのスキルは、ライブ連携なしで動作します。提供されたブランド、オーディエンス、予算、タイムラインの情報は計画の骨子作成に役立ちますが、メッセージング、プラットフォーム/ティアの組み合わせ、コンテンツ形式、プロモーションの仕組み、緊急時の対応策、レート、KPI 目標は決まりません。これらの選択には、ユーザーの指示または互換性のある日付付きの計画エビデンスが必要です。それ以外の場合は NEEDS_INPUT のままにしてください。

利用可能な場合、計画を強化するオプションのコネクター:

  • ~~influencer database — インフルエンサーの構成を決め、ティアごとのフォロワー数の範囲を検証します。
  • ~~social platform analytics — プラットフォームごとのリーチとエンゲージメントのベンチマークを設定します。
  • ~~CRM — コンバージョン目標とアトリビューションを既存のパイプラインデータに合わせます。
  • ~~analytics — 過去のキャンペーン実績を取得し、現実的な KPI と予算効率の目標を設定します。

カテゴリごとの無料/キー不要データの取得方法については、CONNECTORS.md を参照してください。コネクターがない場合は、不足している入力をユーザーに尋ね、ユーザー提供のエビデンスで裏付けられる項目のみを使って進めてください。残りの項目には NEEDS_INPUT を付け、役に立つ骨子を返してください。

手順

作業を始める前に、モードを1つ選び、明示してください。plan-only は §§1–9 を実行し、§10 は実行しません。tracker-only は §10 のみを実行し、既存の campaign_id、正確なバージョン付き plan_ref とプランハッシュ、現在ロックされている §8 の測定契約、およびロック済みの空でないクリエイター範囲を必要とします。いずれかの関連付けが欠落、不一致、分岐、または未検証の場合は、プランを再構築したりプレースホルダーのトラッカーを作成したりせず、NEEDS_INPUT を返してください。both は §10 の前に §§1–9 を実行します。クリエイターの選定がまだロックされていない場合は、プランと、不足している範囲/契約の入力内容を正確に返してください。また、明示的に求められた場合に限り、クローズ対象にならない部分的なトラッカーヘッダーをインラインで返してください。クリエイターの身元をでっち上げたり、実行可能な状態だと称したりしないでください。plan-only または both では、明示的な上流またはユーザー指定の campaign_id を再利用してください。新しいキャンペーンに ID がない場合は、ランダムな campaign-<UUIDv4> を1回生成し、変更せずに維持してください。tracker-only では、ID がないと処理を進められません。キャンペーン名、日付、クリエイターハンドル、変更可能なプラン内容から ID を生成したり、決定論的に導出したりしないでください。

プラン作成モードでは、9つのステップを順番に進めてください。各ステップの記入用テンプレートは references/templates.md にあります。一致するブロックをコピーし、ステップ9で組み立ててください。角括弧内は、提供された値またはソースで裏付けられた値に限って置き換えてください。プレースホルダーを埋めるために数値、身元、ベンチマーク、事実をでっち上げないでください。未解決の任意項目は Unknown のままにし、必須項目が欠けている場合は NEEDS_INPUT を返してください。

  1. キャンペーン要件を収集する — campaign_id、ブランド、バリュープロポジション、オーディエンス、キャンペーン種別、タイムライン、予算、制約事項を記録します(テンプレート §1)。
  2. 目的を定義する — 1 つの SMART な主目的と副目的を設定し、成功と失敗の定義を明示します(テンプレート §2)。
  3. 戦略を策定する — ビッグアイデア、戦略ステートメント、オーディエンス、キーメッセージ、キャンペーンの柱、プラットフォーム配分、差別化要素は、ユーザー承認済みのカノンまたは互換性のある出典日付付きエビデンスからのみ導出します。それ以外の場合は、UGC やプロモコードなどの戦術をデフォルトにするのではなく、意思決定フィールドを NEEDS_INPUT のまま保持します(テンプレート §3)。
  4. インフルエンサー基準を定義する — ティア構成、必須および優先の選定基準、除外条件、理想的なプロフィール、関係性の種類を定めます。ユーザーが宣言した、または互換性のある出典日付付きのフォロワー分類のみを使用します。references/influencer-tiers.md が提供するのは記録契約であり、普遍的な範囲やパフォーマンスに関する主張ではありません(テンプレート §4)。
  5. コンテンツ要件を計画する — プラットフォーム/フォーマット別の成果物、必須要素、クリエイティブディレクション、テーマ、承認チェーンを、提供された意思決定と最新のプラットフォーム/権利エビデンスから導出します。デフォルトの UGC フォーマット、プロモメカニクス、コンテンツミックスを考案してはいけません(テンプレート §5)。
  6. タイムラインを作成する — 主要な日付、4 フェーズの週次計画、ガントビューを作成します(テンプレート §6)。
  7. 予算を配分する — 提供された総額を、ユーザー承認済みのルールまたは互換性のある出典日付付きコストエビデンスのみに基づいて、カテゴリ別、宣言されたフォロワー帯別、プラットフォーム別に分解します。コンティンジェンシー、CPM/CPE、コンテンツあたりのコスト目標は、そのルール/アンカーが提供されている場合にのみ追加します。それ以外の場合は NEEDS_INPUT を使用し、パーセンテージやレートを考案してはいけません(テンプレート §7)。
  8. 成功指標を確立する — 主要 KPI と出典日付付き比較対照、副次指標およびコンバージョン指標、レポート頻度、ならびに非カノンの実行前測定契約を設定します。これには、ベースライン、成果単位、読み戻しウィンドウ、アトリビューション基準、意思決定ルール、意思決定責任者、正確なキャンペーン/プラン バージョン/ハッシュ、ロック承認、空でないクリエイタースコープ、および構造化されたクリエイター/成果物ごとの固有の公開チェックポイントが含まれます(テンプレート §8)。すべての外部比較対照には、不透明な出典参照、観測日、比較可能なウィンドウ/コホートが必要です。それ以外の場合は「業界平均」を示すのではなく、Unknown/NEEDS_INPUT のまま保持します。スコープまたは契約の変更は、新しい不変バージョンと明示的な §10 マイグレーションを伴います。ロックされたブロックをその場で編集してはいけません。
  9. プランドキュメントをコンパイルする — エグゼクティブサマリー、上記の完全なセクション、リスク軽減策を含む付録を作成します(テンプレート §9)。デフォルトではインラインで返します。正確な WARM パスの承認後にのみ保存します。

tracker-only または both の場合は、references/templates.md §10 を参照してインフルエンサードメインのフィールドと互換性ビューを確認してください。ガバナンスされたホストでは、まずソース管理成果物を検証し、トラッカーを読み取り専用の投影として生成します。トラッカーの編集を追記、マイグレーション、ステージ/エビデンス/ポインターの変更、再オープン、クローズとして受け入れてはいけません。クリエイター行はロックされたスコープと一致しなければならず、アクティブブロックは正確に 8 つのフィールドを保つ必要があります。アイデンティティポインターとクローズポインターは隣接したままにします。アイデンティティおよびステートのヘッドは、解決可能で、同一スコープで、一意で、フォークされていないものでなければなりません。スコープ/契約/アイデンティティ/チェックポイント/検証/レシート/クローズ/レイトイベントのギャップがある場合は、PARTIAL CHECKPOINT COVERAGE — NOT CLOSE-ELIGIBLE と表示されます。経過時間がステートを進めることはありません。セマンティックのみのホストでは、同じビューをインラインで返すか、正確なパススコープの承認後に NOT_VERIFIED 互換性スナップショットを保存します。payment_status は外部の準備状況/エビデンスのみを記録し、資金を送金することは決してありません。 各公開チェックポイントには、append-publication-receipt ビュー更新のための新規ホスト認可の下で、同一キャンペーン/クリエイター/チェックポイントのドメインに不変の publication_receipt が付与され、単一ヘッドのスーパーセッション連鎖を持ちます。この YAML ブロックは共有の evidence-observation にマッピングされます。これは action-receipt ではなく、このスキルが何かを公開したことを証明するものではありません。実際の公開には、エグゼキュータの前に別個の正確な action-intent が必要であり、その後に対応する action-receipt が必要です。live_post_ref は、qualified-resolver に裏付けられた不透明な参照にすぎません。生の URL/スラッグ/プロバイダー ID は一時的なものにとどまり、未解決の入力は unknown のままです。verified の開示/バージョン一致には、正確な観察、凍結された承認済みアセット/監査者、およびエビデンス参照が必要です。欠落、不一致、クロススコープ、またはフォークされたエビデンスはブロックされ、アセットを creator-content-auditor にルーティングします。承認や変更を決して推測してはなりません。

クリエイターがクローズされるのは、該当する各チェックポイントが、1 つの支配的な検証済み公開レシート、またはエビデンスに裏付けられた終端の非適用解決を持ち、§10 のすべてのゲートを通過した場合のみです。新規のアトミックな close-creator 認可は、そのレシートの追記、行/エビデンスの変更、およびポインター更新を明示しなければなりません。キャンペーンのクローズには、別個の同等のスコープを持つ close-campaign 認可と、正確な creator→current-close マッピングが必要です。フォークは両方のブランチをブロックします。訂正は履歴を保持し、ゲートを再評価し、必要と判断された場合にのみ、新たに認可されたクローズヘッドを追記します。参照のみの訂正は、作業を手動で再オープンしません。

後発の権利/投稿/帰属/支払い/データに関するエビデンスは、新規の append-late-event 認可の下で、キャンペーンにバインドされた §10 の late_event_note を使用します。付随するステージ/アクション/エビデンス/ポインターの変更は、そのアトミックな認可で明示するか、別途承認する必要があります。supersede-artifact は、同一スコープおよび意味を持つ正確な旧参照と置換参照をバインドします。manual-reopen は、キャンペーンが所有する新規作業にのみ使用されます。それ以外の場合は、訂正を追記し、ゲートが通過すれば新規のクローズヘッドを追記します。履歴を保持し、決して自動再オープンや reopened ステージの捏造を行ってはなりません。

ユーザーが何に注意が必要かを尋ねた場合、明示的な as_of 時刻とユーザーが選択した権利ホライズンを使用して、検証済みのソースアーティファクト(または明確にラベル付けされたセマンティックのみの互換スナップショット)からテンプレート §10 の例外キューを生成します。これは読み取り専用のプロジェクションです。cron、ポーリング、自動ステージ変更、プロジェクションの書き戻し、または外部変更は行いません。

例

ユーザー: 「TikTok と Instagram で Gen Z をターゲットにした、予算 $50K の新しいサステナブルスニーカーのローンチに向けたキャンペーンプランを作成して」

出力: 提供されたオーディエンス、プラットフォーム、および $50K の総額を保持するプラン骨子。サステナビリティの主張/メッセージカノン、クリエイター構成、コンテンツ形式、プロモ/アトリビューションメカニクス、レート、コンティンジェンシー、KPI ターゲット、および正確な日付は、ユーザーが提供するか、互換性のあるソース日付付きアンカーが提供されるまで NEEDS_INPUT のままです。マイクロヘビー、UGC、プロモコード、またはパーセンテージのデフォルトは推測されません。(より詳細なウォークスルーは references/templates.md にあります。)

参考資料

  • references/templates.md — 9つの計画ステップすべての記入用テンプレート、任意の簡易 WARM トラッカー、記入例、成功のヒント。
  • references/influencer-tiers.md — ユーザー/ソースの日付が記載されたパートナーモデルとフォロワー数の範囲に関する宣言契約です。普遍的な範囲やパフォーマンスに関する主張は提供しません。
  • skill-contract.md — 共通の契約と引き継ぎスキーマ。
  • state-model.md — メモリ階層と保存先の規約。
  • CONNECTORS.md — コネクターのカテゴリごとの無料/キー不要のデータレシピ。
  • audience-mapper — この計画の対象となるオーディエンスを定義します。
  • brief-generator — 計画をインフルエンサーごとのブリーフに変換します。
  • budget-optimizer — 予算配分を改善します。
  • influencer-discovery — 条件に合うインフルエンサーを見つけます。

次に最適なスキル

  • 計画作成の主要スキル:brief-generator — 承認済みの計画を具体的なインフルエンサー向けブリーフに変換します。
  • 計画作成の代替スキル:budget-optimizer で配分をストレステストする、または influencer-discovery で確定済みのクリエイター対象範囲を作成または補完します。
  • トラッカーのみ、公開/承認が保留中の場合:creator-content-auditor — 引用された公開済み投稿を、凍結された承認済みアセットと照合して確認します。編集や増幅を許可するものではありません。
  • トラッカーのみ、読み戻し/照合の期限が来ている場合:performance-analyzer — 日付入りの §8 読み戻しアーティファクトを作成します。最終レポートにこのアーティファクトを含められるのは、証拠が揃ってからです。
  • トラッカーのみ、未完了の運用項目がある場合:現在の next_action で指定された担当者/スキルにのみ引き継ぎます。後期段階の行をブリーフ作成に差し戻さないでください。すべての完了ゲートを通過し、残りのアクションがない場合は、停止して一連の処理が完了したことを報告します。

終了時の注意:このセッションで呼び出したスキルを記録するため、訪問済みセットを保持してください。該当する次のスキルをこのセッションですでに実行済みの場合は、再度呼び出さずに停止し、一連の処理が完了したことを報告します。起点となるリクエストから3ホップを超えて連鎖させないでください。

コメント