outreach-manager

アウトリーチマネージャー

パーソナライズされた、プロフェッショナルで粘り強いアウトリーチを行い、交渉を管理し、関係の進展を追跡します。中心となる領域はインフルエンサー（クリエイターへのアウトリーチ）です。同じ仕組み（パーソナライズ、複数回の接触を含む進行計画、交渉スクリプト、パイプラインの追跡）は、press-media-relations からメディアリスト、切り口、解禁条件を引き継いだ場合のメディア／アナリストやローンチパートナーへのアプローチにも、social-selling-planner または advocacy-program-designer から温かい 1 対 1 の紹介を引き継いだ場合のソーシャルセリング／アドボカシー参加者の募集にも活用できます。リスト、切り口、解禁条件は引き継ぎ元のスキルが管理し、このスキルは提案の実行を担います。

クイックスタート

最短の呼び出し方：

Write an outreach message to @[influencer] for [campaign]

依頼内容と予算の差を交渉します：

Help me negotiate with @[influencer] who is asking for $[X] when our budget is $[Y]

スキル契約

• 読み取り：認可された上流アーティファクトに含まれている場合は、安定した不透明な creator_ref に加え、一時的な対象ハンドル／プロフィールロケーター、プラットフォーム、フォロワー数、ニッチ。キャンペーンと製品のコンテキスト、報酬の種類と予算、納品物とスケジュール、管轄区域、予定チャネル、適法根拠の参照、連絡先情報の取得元／適格性の証拠、仮名化された同意対象者 ID、ユーザーから提供された、またはメモリから読み込まれた過去の連絡履歴。名簿に登録されたクリエイターについては、本人との紐付けが検証済みの場合に限り、クリエイター登録簿の集約 ID を再利用し、認可されたアーティファクトまたは検証済みの登録簿リンクを通じて解決してから、creator-registry の投影である memory/creators/<aggregate-id>.md を確認し、確認済みの連絡経路、最後に合意した料金、交渉／返信履歴を取得します。生のハンドルから連絡経路を導出してはなりません。
• 書き込み：デフォルトではアウトリーチ用アーティファクトをインラインで返します。正確な WARM 保存認可がある場合に限り、memory/influencer/outreach-manager/YYYY-MM-DD-<topic>.md に保存します。明示的に引き継がれた不透明な creator_ref、または検証済みのクリエイター登録簿の集約 ID を再利用します。それ以外の場合は、この一連の処理用にランダムな creator-<UUIDv4> を一度だけ生成します。生のハンドル、名前、プロフィール URL、メールアドレス、プロバイダー ID、または決定論的ハッシュから creator_ref を導出してはなりません。保存前に、生のロケーターと解決済みの受信者 ID を、安定した creator_ref と解決可能な不透明な recipient_ref、contact_source_ref、handle_ref、および証拠／承認の参照に置き換えます。生の URL またはハンドルを永続化された source_ref として使用してはなりません。認可されたソースアーティファクトまたは検証済みの登録簿リンクで不透明な ID／連絡先参照を解決できない場合は、identity_status: unresolved に設定し、生のロケーターとの隠れた対応関係を保存せず、cross_session_locator_required: true に設定して、送信時に一時的なロケーターを再度要求します。生のハンドル、名前、プロフィール URL、メールアドレス、電話番号、郵送先住所、プロバイダー ID、認証情報を永続化してはなりません。サイクル終了時に結果を更新する場合（最終合意料金、返信履歴、確認済みの連絡経路参照）には、それぞれについて memory/events/creators.ndjson への operation: propose リクエストに対する個別の正確な認可が必要です。正規の名簿レコードを書き込むのは creator-registry のみです。
• 昇格：個別の正確な認可がある場合に限り、長期的に有用な事実（確認済みのパートナー、合意済みの料金、よくある反論のパターン、返信率のベースライン）を memory/hot-cache.md に昇格させます。
• 完了条件：
  • 対象となる各インフルエンサーについて、パーソナライズされたピッチと少なくとも 1 つのバリエーションが用意されていること。
  • パーソナライズに使用したすべての事実に source_ref と observed_at が記録されていること。検証できない事実はプレースホルダーのままにするか、省略すること。
  • 連絡したすべてのクリエイターについて、連絡しないまま終了した状態も含め、フォローアップの頻度とパイプラインのステータスが記録されていること。
  • 管轄区域、チャネル、適法根拠、連絡の適格性が明示されていること。送信／予約は、正確な承認と送信時点での抑制対象の確認が行われるまで実行できないこと。
  • 確認済みのパートナーに、引き継ぎ用の合意条件が明示されていること。
• 次に実行する主なスキル：contract-helper

引き継ぎサマリー

skill-contract.md §Handoff Summary Format に記載された標準形式を出力します。

データソース

下書きの作成にライブ連携は不要です（Tier 1）。このスキルは、提供された入力に基づいて動作します。インフルエンサーのハンドル名、フォロワー数、ニッチ、予算、納品物を貼り付ければ、ツール接続なしで、下書きであることを明示した内容を作成できます。送信やスケジュール設定は別です。実行直前に、仮名化された対象者 ID と、ライブの consent-registry 抑止クエリが必要です。クエリを利用できない場合や失敗した場合、送信の許可とはみなされません。

コネクターを使うと作業を効率化できる場合は、次の ~~ プレースホルダーを使用してください。

• ~~influencer database — ハンドル名、フォロワー数、ニッチ、過去の提携実績を取得し、手入力を省きます。
• ~~social platform analytics — オーディエンスの属性と最近の投稿を確認し、パーソナライズに役立てます。
• ~~CRM — パイプラインのステータス、最終連絡日、次のアクションを同期します。
• ~~email/DM tool — 最新の適格性確認とライブの抑止チェックを通過した、現在送信期限を迎えている、正確に承認済みの単一の連絡のみを送信します。プロバイダーの機能にかかわらず、将来の連絡はスケジュール設定しない下書きのままにします。

カテゴリごとの無料・キー不要の方法については、CONNECTORS.md を参照してください。連携は必須ではありません。連携がない場合は、ユーザーに直接入力を求めてください。ターゲットやキャンペーンの詳細が不足していても、取り消し可能な下書きの作成を妨げるものではありません。明示的な角括弧付きプレースホルダーを使用し、未確認のパーソナライズ要素は一般化して、仕上げに必要な最小限の入力を明示してください。

手順

実行時の読み込み

• ../../../references/runtime-invocation.md
• ../../../references/registry-event-protocol.md

手順

ユーザーがアウトリーチの支援を依頼した場合は、以下の手順を実行してください。各手順には references/templates.md に入力用テンプレートがあります。該当するブロックをコピーしてプレースホルダーを置き換えてください。メッセージを送信する前に、references/cold-copy-rules.md の厳格な文面ルールを適用してください。

下書きと送信の境界：下書きの作成は取り消し可能ですが、送信やスケジュール設定は外部への副作用を伴います。候補リストやパーソナライズに必要な事実が不足している場合でも、事実を捏造せず、明示的なプレースホルダーを使った初回連絡の下書きを本文内に作成し、DRAFT — NOT SENT と表示して、パーソナライズに何が必要かを示してください。安全なプレースホルダー付きの下書きを作成できる場合は、入力を求めるだけで終わらせないでください。

以下の条件をすべて満たすまで、何も送信またはスケジュール設定しないでください。

• 正確な受信者（セグメントやプレースホルダーではないこと）、意図するチャネル、最終メッセージ、およびその連絡をスケジュール設定する場合は、具体的な ISO-8601 形式の dispatch_at タイムスタンプとタイムゾーンを提示し、明示的な承認を得ていること。承認が対象とするのは、現在送信期限を迎えている単一の連絡のみです。Day 3–4 などの下書き上の期間は正確な承認ではなく、後続の連絡を事前にスケジュール設定することを承認やプロバイダーの機能が許可することもありません。
• 法域、チャネル、証拠の参照情報を伴う適法な根拠、連絡の適格性が記録されていること。適格性が Unknown または未入力の場合は、許可されていないものとして処理します。このスキルは法的根拠を捏造せず、法的助言も行いません。
• 実際の各配信ジョブ内で、一時的な受信者を解決した後、プロバイダーの送信呼び出しの直前に、以下に示すとおりバンドルのランタイムを解決して検証し、ライブの consent-registry is-suppressed を実行すること。抑止対象という結果、対象者 ID の欠落、履歴へのアクセス不能または破損、ランタイム／スキーマの失敗、クエリエラーがあった場合は、その配信を中止してください。「抑止対象ではない」という結果で解除されるのは抑止ブロックのみです。それだけで適法な根拠が証明されたり、連絡が許可されたりするわけではありません。連絡のたびにキャッシュ済みの結果を再利用しないでください。

AARON_SKILLS_ROOT="${CLAUDE_PLUGIN_ROOT:-$(git rev-parse --show-toplevel 2>/dev/null || true)}"
PROJECT_ROOT="${PROJECT_ROOT:-}"
SUBJECT_ID="${SUBJECT_ID:-}"
case "$PROJECT_ROOT" in
  /*) ;;
  *) echo "PROJECT_ROOT must be an absolute project path; stop dispatch." >&2; exit 1 ;;
esac
if [ -z "$AARON_SKILLS_ROOT" ] || [ -z "$PROJECT_ROOT" ] || [ -z "$SUBJECT_ID" ] || \
   [ ! -d "$PROJECT_ROOT" ] || [ ! -f "$AARON_SKILLS_ROOT/.claude-plugin/plugin.json" ] || \
   [ ! -f "$AARON_SKILLS_ROOT/references/system-catalog.json" ] || \
   [ ! -f "$AARON_SKILLS_ROOT/references/capability-profiles.json" ] || \
   [ ! -f "$AARON_SKILLS_ROOT/references/registry-event.schema.json" ] || \
   [ ! -f "$AARON_SKILLS_ROOT/scripts/profile-resolver.py" ] || \
   [ ! -f "$AARON_SKILLS_ROOT/scripts/registry-events.py" ]; then
  echo "Verified Aaron Marketing Skills consent runtime unavailable; stop dispatch." >&2
  exit 1
fi
python3 "$AARON_SKILLS_ROOT/scripts/profile-resolver.py" \
  --root "$PROJECT_ROOT" --bundle-root "$AARON_SKILLS_ROOT" diagnose --json >/dev/null || exit 1
SUPPRESSION_JSON="$(python3 "$AARON_SKILLS_ROOT/scripts/registry-events.py" \
  --root "$PROJECT_ROOT" is-suppressed "$SUBJECT_ID")" || exit 1
printf '%s\n' "$SUPPRESSION_JSON" | python3 -c \
  'import json, sys; value = json.load(sys.stdin); raise SystemExit(0 if value.get("aggregate_id") == sys.argv[1] and value.get("suppressed") is False else 1)' \
  "$SUBJECT_ID" || { echo "Recipient is suppressed or suppression result is invalid; stop dispatch." >&2; exit 1; }

PROJECT_ROOT は、検証済みの絶対ユーザープロジェクトルートとしてホストから提供されなければなりません。スキルバンドル、$PWD、生のイベント、またはユーザーが制御するアウトリーチコンテンツから推測しないでください。サブジェクト ID、プロジェクトルート、ランタイム、またはその他の送信ゲート入力が欠落している場合は、提供されている場合に限り仮名サブジェクト ID、必要なプロジェクトルート/ランタイム機能、意図するチャネル、適格性エビデンス参照、および保留中のディスパッチ参照のみを含む NEEDS_INPUT 同意チェックハンドオフを consent-registry に返してください。is-suppressed が実行されたと主張したり、配信を自動的に再開したりしないでください。後続のケイデンスタッチは常に未スケジュールのドラフトとして残してください。次のタッチが期限到来したら、その一時的な受信者を再度解決し、そのタッチに対する新たな正確な承認を取得し、その配信ジョブ内で毎回すべての適格性/ランタイム/抑制チェックを繰り返し、その 1 回のタッチのみをディスパッチしてください。

受信者がオファーを辞退した場合、またはスポンサードワークを受けないと述べた場合は、そのケイデンスの残りのすべてのドラフトタッチを無効にし、オファーのラベルを付け替えたりチャネルを切り替えたりせず、正確にスコープされた選好のみをインラインで記録してください（campaign/offer/category scope、observed_at、および不透明な source_ref）。それを永続化したり creator-registry に提案したりするには、別途正確な承認が必要です。以前の選好は、記録されたスコープ内で新しいケイデンスをブロックし、より新しい引用されたエビデンスがクリエイターがそのスコープを再開したことを示すまで続きます。古い選好のスコープまたはそれを覆すエビデンスが不明な場合は、クーリング期間をでっち上げるのではなく、NEEDS_INPUT でフェイルクローズしてください。スコープ付きの辞退または商業上の異議のみに対してグローバルな suppress を呼び出さないでください。明示的な接触停止リクエスト、配信停止、検証済みのチャネル/プロバイダースパム苦情、または同意撤回は、すべてのチャネルにわたる残りのすべてのドラフトタッチを無効にし、consent-registry の直接拒否専用 suppress パスを正確なサブジェクトフリーの理由コードで使用します：接触停止 → user-request、配信停止 → unsubscribe、検証済みスパム/プロバイダー苦情 → complaint、同意撤回 → withdrawal。検証済みランタイムが利用できない場合は、その正確な immediate-suppress-handoff を発行し、抑制がまだ記録されていないことを述べてください。

1. アウトリーチの背景情報を集め、IDを固定する — キャンペーン／製品の背景情報、一時的なターゲットのハンドル／プロフィール識別子、プラットフォーム、フォロワー数、ニッチ、報酬の種類、予算、納品物、スケジュールを記録します。明示的に引き継がれた不透明な creator_ref を再利用するか、IDとの紐付けが検証済みの場合に限りクリエイターレジストリの集約 ID を使用します。それ以外の場合は、この系譜に対してランダムな creator-<UUIDv4> を一度だけ生成します。生の識別子を creator_ref に使用したり、ハッシュ化したりしてはいけません。認可されたソースアーティファクトまたは検証済みのレジストリリンクによって解決できる場合に限り、不透明な handle_ref、recipient_ref、contact_source_ref、または証拠の source_ref を保存します。それ以外の場合は、identity_status: unresolved を設定し、生の識別子や非表示のマッピングは保存せず、cross_session_locator_required: true を設定して、送信時に生の識別子を再度求めます。保存されるアーティファクトや引き継ぎに含めるのは、不透明な ID／連絡先／証拠の参照情報、管轄区域、チャネル、適法根拠の証拠、連絡可否の判定だけとし、生のハンドル、氏名、プロフィール／コンテンツの URL、メールアドレス、電話番号、郵送先住所、プロバイダー ID、認証情報は含めません。検証済みの名簿登録済みクリエイターに再度連絡する場合は、コールドピッチではなく、確認済みの連絡経路の参照情報と最後に合意した料金を起点にします。テンプレート：ステップ 1。
2. パーソナライズしたアウトリーチを作成する — パーソナライズのポイント（最近のコンテンツ、スタイル、オーディエンス、価値観、過去のパートナー）を列挙し、各事実に source_ref と observed_at を付けてから使用します。検証できない内容は省略するか一般化し、個人的な視聴、購入、製品使用、関係性の履歴を決して捏造しません。次に、主メッセージに加えて、DM 向けの短縮版と、正式なメール／マネジメント向けの版を作成します。テンプレート：ステップ 2。メディア／アナリスト／ハンターを対象とする場合：専門分野と最近の報道内容をもとにパーソナライズし、報酬の提案ではなく記事の切り口を最初に提示します。プレス・メディアリレーションのアーティファクトに記載されたエンバーゴ条件を一字一句そのまま使用し、引用やデータを決して捏造しません。主張には承認済みメッセージハウスの内容のみを使用します。
3. フォローアップのシーケンスを作成する — 4 回の接触を含む戦略的な期間（0 日目／3～4 日目／7～8 日目／14 日目、その後 21 日目にアーカイブ）を作成します。各回で、証拠に基づく新しい価値、または承認済みの新しい価値を加え、メッセージを短くしていきます。これらの範囲は計画上の目安にすぎません。今後の連絡は必ず未スケジュールのままにし、連絡時期が来たら、その連絡だけを承認／確認／送信します。スケジュールする場合は、タイムゾーンとともに、具体的な ISO-8601 形式の dispatch_at を 1 つ指定します。連絡を妨げる対象範囲の希望やその他の否定的なシグナルがない場合に限り、フォローアップは最大 3～4 回とし、断りやすい表現にして、承認済みで連絡可能なチャネルのみを使用します。新しいチャネルを使うには、そのチャネル独自の連絡可否の証拠と、明示的な承認が必要です。キャンペーン／オファーの辞退があった場合、その頻度での連絡を終了し、対象範囲の希望をインラインで記録します。これを永続化するには、別途、明示的な認可が必要です。その対象範囲内で後日連絡を再開するには、より新しい再開の証拠が必要です。明示的な連絡停止（user-request）、配信停止（unsubscribe）、検証済みのスパム／プロバイダー苦情（complaint）、または同意撤回（withdrawal）があった場合は、さらに上記の抑止処理を実行します。テンプレート：ステップ 3。
4. 交渉を支援する — 要望と予算の差を整理し、次に価値交換、範囲調整、将来的な価値の戦略を、すぐ使えるスクリプトと異議／対応の表とともに適用します。テンプレート：ステップ 4。
5. アウトリーチのパイプラインを追跡する — ステージ別の件数とコンバージョン率、クリエイターごとの詳細なパイプライン、今日優先するアクション、パイプラインの健全性（返信率、確認率、確認までの時間、主な異議）を記録します。オファーの辞退は、その頻度での連絡の終了と対象範囲の希望として記録します。明示的な連絡停止（user-request）、配信停止（unsubscribe）、検証済みのチャネル／プロバイダーへのスパム苦情（complaint）、または同意撤回（withdrawal）は、抑止イベント／引き継ぎ参照情報とともに、連絡禁止の終了状態として記録します。どちらの行にも、フォローアップのアクションを残してはいけません。テンプレート：ステップ 5。進行中のサイクルの追跡はここで行います。サイクルが終了したら（確認済みまたはアーカイブ済み）、終了結果を 1 行の operation: propose 更新として提示し、別途、明示的な認可を得て、creator-registry で照合できるようにします。

例

ユーザー: "creator_ref: creator-042 向けのアウトリーチ文を作成してください。source_ref: [opaque authorized evidence ref]、observed_at: [ISO 8601]、observable_detail: [exact visible detail] とともに、一時的なコンテンツロケーターを提供しました。[claims-or-brief-ref] に記載された承認済みのキャンペーン、オファー、製品の表現のみを使用してください。"

出力（抜粋）：

## Outreach for `creator_ref: creator-042`

### Personalization Points
- Content item: `[content title or format supported by content_ref]`
- Observable detail: `[exact visible detail from supplied evidence]`
- Evidence: `source_ref: [opaque authorized evidence ref]`  •  `observed_at: [ISO 8601]`

### Primary Message
Subject: `[evidence-backed content topic]` — collaboration idea from `[Brand]`

`[Recipient name resolved transiently at dispatch]`, your `[content item]` `[observable detail supported by content_ref]`. I'm `[Sender]` from `[Brand]`. `[Approved campaign/product sentence from claims-or-brief-ref]` We're offering `[approved compensation]` for `[approved deliverable]`. Open to hearing more?

複数バージョンの完全な出力、フォローアップのスケジュール、交渉ガイド、パイプライントラッカーは references/templates.md にあります。

参考資料

• references/templates.md — 5つのステップすべての記入式テンプレート、完全な作成例、アウトリーチのヒント。
• references/cold-copy-rules.md — コールドアウトリーチ文の厳格なルール：冒頭文で禁止される表現、各ステップの文数上限、控えめな CTA、観察内容の示し方、ステップ 1 でリンクを記載しないこと。
• skill-contract.md — 共通契約と引き継ぎサマリーの形式。
• state-model.md — メモリ階層と保存先の規約。
• runtime-invocation.md — ライブ抑制クエリの実行前に、安全なバンドルルートの解決と機能ランタイムの検証を行う方法。
• CONNECTORS.md — コネクターカテゴリごとの無料／キー不要のデータ取得手順。
• STAR ベンチマークの採点基準は references/star-benchmark.md を参照してください。後続レビューの品質採点に使用します。
• expert-panel.md — 送信前にアウトリーチ文を厳しく検証する複数ペルソナによるレビュー手法。
• 関連スキル：influencer-discovery、fit-scorer、brief-generator、contract-helper、creator-content-auditor。

次に最適なスキル

• 主スキル：contract-helper — パートナーが確定したら、合意した商取引条件と権利を契約書にまとめてから、コンテンツ制作に進みます。
• 代替：creator-content-auditor — 契約書／ブリーフが作成され、クリエイターがコンテンツのドラフトを作成した後に限り、公開前にそのコンテンツを確認します。
• 代替：brief-generator — 詳細を希望するクリエイターに、キャンペーンブリーフ一式を送信します。

終了に関する注意：訪問済みセットを保持してください。このチェーン内のスキルがこのセッションですでに呼び出されている場合は、再実行せず、チェーン完了として報告してください。引き継ぎの最大深度は 3 です。

関連スキル

• influencer-discovery - アウトリーチするインフルエンサーを見つけます
• fit-scorer - 最初に連絡する相手の優先順位を付けます
• brief-generator - 確定したパートナーにブリーフを送ります
• contract-helper - 契約を締結します