cold-email-sequence-generator-skill

適格なコンタクトリストとバリュープロポジションから、マルチタッチのコールドメールシーケンスを作成します。その出力はチャットテキストではなく、レビュー可能な Gmail の下書き一式です。各メールには A/B の件名、1 つの CTA、タイミング、そして別れのタッチが含まれます。製品情報は Epiphan カタログから、トーンは Epiphan Brand MCP から、受信者リストは `qualify_lead` から取得します。 キーワード: `cold email sequence`、`email campaign`、`outbound sequence`、`nurture`、`re-engagement`、`breakup email`

<quick_start> 呼び出し順のツール:

1. 入力 — コンタクトリスト（HubSpot リスト ID、CSV、または名前付きコンタクト）、業種、シーケンスタイプ、 バリュープロポジション、証拠ポイント。リストがない場合は確認する。業種がない場合はドメインから推測し、フラグを立てる。
2. バリアント — config.json を読み込み、variants.enabled が true なら bash scripts/variant-assigner.sh cold-email-sequence-generator-skill $(date +%s) を実行し、 割り当てられた prompt_suffix を適用する。
3. ゲート Q — コンタクトごとに qualify_lead。除外されたコンタクトは除外し、STALE AE LEAD の行は Tim 向けに一覧表示し、下書きは作成しない。判定から得られる ATL ティアが並び順を決めます。
4. ゲート S — シーケンスが扱うすべての製品、仕様、競合に関する主張について search_product_catalog を実行し、続いて Epiphan Knowledge の search を実行します。未検証の場合は下書きに [spec unverified] と記載します。
5. ゲート B — get_writing_style を 1 回実行し、続いてすべての件名と本文に対して check_my_copy を実行します。
6. ゲート D — コンタクトごと、タッチごとに mcp__claude_ai_Gmail__create_draft を実行し、送信元は [email protected]、件名の接頭辞は [Seq N/M] とします。send_message は決して使用しません。
7. 納品 — サマリーテーブル（コンタクト / ティア / 下書きしたタッチ数 / ゲートフラグ）に加え、以下に示すサイドカーと実行ログの行を出力します。送信は batch-send-drafts-skill の役割です。 </quick_start>

<house_rules> 顧客対応スキルです。出力前に、ゲートを順番に実行します（詳細: /.claude/skills/epiphan-house-rules-skill/reference/gates.md）: S: 製品に関する主張の前に search_product_catalog（Epiphan AI）または Epiphan Knowledge search。B: 顧客対応するすべての文字列に対して check_my_copy。 Q: 候補の抽出直後、ティア分け・エンリッチメント・下書きの前に qualify_lead。D: アウトバウンドテキストは Gmail の下書きになり、決して送信されません。 識別子（オーナー ID、ポータル、メール、シート数）はそのスキルの reference/identifiers.md から取得します — ここでは再掲しません。 ゲートが失敗した場合は reference/self-healing.md に従い（リトライ、フラグ付きでの縮退、Tim へのアラート、停止）、/.claude/skill-runs/.jsonl に行を追記します。 </house_rules>

<variant_support> このスキルは config.json を介して A/B バリアントをサポートします。

1. このスキルの config.json を読み込む — variants.enabled が true か確認する
2. 有効な場合、実行する: bash scripts/variant-assigner.sh cold-email-sequence-generator-skill $(date +%s)
3. 割り当てられたバリアントの定義にある prompt_suffix を適用してワークフローを変更する
4. 結果のサイドカーにバリアント名を記録する（以下の最終ステージを参照）

現在の実験: cold-email-subject-style-001

• control: 標準の 7 メールフレームワーク
• concise: 5 メールフレームワーク、メールあたり 50 語まで </variant_support>

<success_criteria>

• すべてのコンタクトに対して、下書き作成前に qualify_lead が実行された。除外された行と stale-AE の行は下書きされず、報告される
• シーケンスタイプが選択されている（Classic 7、Fast-Track 5、Long-Play 12-14、Event-Based、Re-Engagement）
• すべての製品または競合に関する主張が、Epiphan Knowledge の search 結果に由来するか、[spec unverified] を伴う
• すべての件名と本文が check_my_copy を通過し、修正が下書き作成前に適用されている
• コンタクトごと、タッチごとに Gmail の下書きが 1 つ存在し、送信元は [email protected]、件名の接頭辞は [Seq N/M] である
• 各メールに A/B の件名、1 つの CTA、送信日のオフセットがある。最終タッチは別れのメールである
• ゲートフラグを含む結果のサイドカーと実行ログの行が書き込まれている </success_criteria>

## ステージ 1: 入力と候補の抽出

以下いずれかを受け付けます: HubSpot リスト（hubspot_list_members）、HubSpot 検索（hubspot_search_contacts）、 CSV、または名前付きのコンタクト。コンタクトごとに以下を取得します: メールアドレス、名、役職、組織、業種、HubSpot id。 シーケンスごとに以下を取得します: タイプ、バリュープロポジション、Tim が使用を希望する証明ポイント、パーソナライゼーションのフック。

ステージ 2: ゲート Q — qualify_lead

コンタクトごとに qualify_lead を呼び出します。返された判定をそのまま適用します: 顧客、チャネルパートナー、 製品のみの関与者、配信抑制対象、AE が所有するアクティブ案件を除外します。STALE AE LEAD の行は Tim の判断のためにサマリーに表示します。順序付けのために ATL/GRAY/BTL のティアを維持します（ATL が最初）。qualify_lead が 1 回の再試行後も利用できない場合: 停止し、状態を書き込み、Tim に伝えます — ゲートを通していないリストに対して下書きを作成しないでください。

ステージ 3: シーケンス設計

タイプ	タッチ数	期間	用途
Classic	7	2 週間	完全新規のコールドリスト
Fast-Track	5	1 週間	ウォームまたはイベント関連のリスト
Long-Play Nurture	12-14	4-6 週間	予算サイクルまたは RFP 時期のアカウント
Event/Trigger	3-5	イベント固有	Extron SMP EOL、新規建物、録画失敗、カンファレンス
Re-Engagement	5	2 週間	失注案件または 90 日以上停滞したコンタクト

メールの役割（Classic 7）:

#	役割	目的	長さ	CTA
1	イントロダクション	問題の再定義、製品名なし	50-100 語	ソフトな質問
2	価値の証明	検証済みの証明ポイント	75-125 語	具体的な時間
3	別の切り口	別の課題	50-75 語	はい/いいえの質問
4	社会的証明	同業者による裏付け（検証済み）	60-90 語	簡単な返信
5	リソース共有	求める前に与える	40-60 語	「役に立ちますか？」
6	直接の依頼	率直なミーティング依頼	30-50 語	日時
7	打ち切り	終了の許可	25-40 語	「ファイルを閉じてよろしいですか？」

タイミング: 0、2、4、6、8、10、14 日目。火〜木の午前（受信者のタイムゾーン）が優れており、月曜の 受信トレイの滞留と金曜の午後は避けます。各下書きの件名メモに日数のオフセットを記録し、 batch-send-drafts-skill がそれらを並べられるようにします。

ステージ 4: ゲート S — 仕様と主張の検証

本文を一行でも書く前に: 名前を挙げたすべての製品について search_product_catalog を実行します（SKU が 現行であることを確認します。EOL 製品には確認応答を付け、仕様は決して付けません）。次に、正確な仕様、機能、または競合他社の事実について Epiphan Knowledge の search を実行します。証明ポイントと ケース参照は、ナレッジの検索結果または Tim が提供した入力から取得しなければなりません。顧客、数値、引用を決して捏造しないでください。検証されていない 主張 → インラインで [spec unverified] と記述し、ステージ 4 を名指しして outcome を partial に設定します。

ステージ 5: ゲート B — ブランドボイス、その後執筆

セッションごとに 1 回 get_writing_style を実行します。以下のテンプレートから各タッチを書き、次に すべての件名バリアントとすべての本文に対して check_my_copy を実行します。ステージ 6 の前に修正を適用します。 1 回の再試行後に Brand MCP がダウンしている場合: そのまま下書きし、各本文の先頭に [brand check skipped] を付け、ステージ 5 を名指しして outcome を partial にします。

ステージ 6: ゲート D — Gmail の下書き

コンタクトごと、タッチごとに mcp__claude_ai_Gmail__create_draft を [email protected] から実行します:

• 件名: [Seq N/M] <winning A/B subject> — 代替の件名は本文の最初の行に A/B alt: … として入れ、Tim がレビューで差し替えられるようにします。
• 本文: check_my_copy で承認されたタッチ、署名は identifiers.md に従います。
• send_message や reply を決して呼び出さないでください。Gmail の書き込み失敗 → 1 回再試行し、その後サマリーでそのタッチを 下書き未作成として報告します（outcome partial、ステージ 6）。

ステージ 7: サマリー

SEQUENCE STAGED — <type>, <M> touches, <date>
 Contact              Tier   Drafts   Flags
 J. Smith (u.edu)     ATL    7/7      —
 R. Lee (city.gov)    GRAY   7/7      [spec unverified] x1
 K. Ng (hosp.org)     —      0        STALE AE LEAD (Ron Epstein, 112d) — Tim decides
Excluded by qualify_lead: 4 (2 customer, 1 partner, 1 AE-active)
Next: batch-send-drafts-skill to review and send.

メールテンプレート

角括弧はステージ 1 の入力とステージ 4 の検証済みの事実のみから埋めます。

メール #1: イントロダクション

件名（A/B テスト）:

• A（好奇心）: Quick question about [org]'s [specific challenge]
• B（価値）: [Verified outcome] for [org type]
• C（個人的）: [Name], saw your post about [specific topic]

Hi [First Name],

I noticed [specific observation about their org/role] and thought you might be facing [specific challenge].

Teams like [verified peer org type] have [verified outcome] without [common objection].

Worth a quick 15-minute conversation to see if the same applies at [org]?

[Signature]

P.S. - [Personalized one-liner from research]

メール #2: 価値の証明

件名: "How [peer org type] achieved [verified result]"

[First Name],

Following up — wanted to share how this worked for a [peer org type].

They were [situation]. In [timeframe], they:
- [Verified result #1]
- [Verified result #2]

They got started without [common objection].

Would [Day] at [Time] work for 15 minutes?

[Signature]

メール #3: 別の切り口

件名: 「[org] についての別の考え」

Hi [First Name],

I realize [original pain point] might not be top of mind right now.

But what about [alternative pain point]?

Most [their role]s tell me [common complaint], which is why [mini value prop, no spec unless verified].

If this hits closer to home, happy to share how [quick win].

[Signature]

P.S. - If neither is relevant, just let me know and I'll stop.

メール #4: ソーシャルプルーフ

件名: 「[Mutual connection] さんが連絡するよう勧めてくれました」または「[peer] は [challenge] にどう対応しているか」

[First Name],

I was speaking with [title] at a [peer org type] about [challenge].

Here's what they said after [solution]:
"[Quote supplied by Tim or from knowledge base — never invented]"

Open to a quick call to hear what's working in [vertical]?

[Signature]

メール #5: リソースの共有

件名: 「これが役立つかもしれないと思いました」

[First Name],

No ask here — just sharing something helpful:

[Resource description]: [Link]

We put this together after hearing [their role]s struggle with [pain point]. Useful even if you never buy anything from us.

Hope it helps.

[Signature]

メール #6: 直接の依頼

件名: 「本題に入りましょう」

[First Name],

Let me be direct: I think we could help [org] [achieve outcome] based on [observation].

I'd like to show you:
1. [Specific thing #1]
2. [Specific thing #2]
3. [How peers in your role use it]

15 minutes. No pressure. How's [day/time]?

[Signature]

メール #7: 終わりの挨拶

件名: 「あなたのファイルを閉じてよろしいですか?」

[First Name],

I'll assume [topic] isn't a priority right now — totally fine.

I'll close your file unless I hear otherwise. If you want to revisit, [time-sensitive reason, e.g. budget cycle], so a quick chat now might save you a step later.

No worries either way — appreciate your time.

[Signature]

P.S. - If someone else at [org] should hear about this, happy to redirect.

終わりの挨拶のバリエーション: 許可を求める(「関連性がない / 優先度が低い / タイミングが悪い — どれですか? #3 なら、いつ確認すればよいですか?」) · 紹介依頼(「明らかに私は適切な相手に届いていません — [topic] の担当者は誰ですか?」)。Gate S で検証されていない限り、競合他社の顧客名を挙げる FOMO 的な文言は避けてください。

業界別クイックスタート

• 高等教育 (ICP 90): 期末試験週の信頼性 → 同業キャンパスの実績 → 配信の課題 → リソース(CMS 連携ドキュメント)→ 直接の依頼 → 終わりの挨拶
• 裁判所 (ICP 85): 記録の欠落 → 郡の実績 → 無人の 8 時間セッション → リソース → 直接の依頼 → 終わりの挨拶
• 政府 (ICP 80): AV 担当者を増やさない議会の録画 → 市の実績 → 投稿の遅延 → リソース → 直接の依頼 → 終わりの挨拶
• 医療 (ICP 75): 臨床 IT の負担を増やさない手術室の録画 → 医学教育の実績 → 学習者のアクセス → リソース → 直接の依頼 → 終わりの挨拶
• 企業向け AV / 礼拝 / K-12: 同じ流れ。Tim のインプットから、その業界の最大の課題に合わせて切り口を差し替えてください

A/B テストとベンチマーク

順にテストしてください: 件名(疑問文 vs 平叙文、パーソナライズ vs 汎用)、本文の長さ(50 vs 100 語)、CTA のスタイル、送信時刻。方法: 最初の 100 件の連絡先を 50/50 に分割し、48 時間で判定し、勝った方を残りに適用します。ベンチマーク(メール 1 の開封率 35-55%、シーケンスの返信率 8-25%、ミーティング予約 1-6%)は計画上の目安であり、コピーに記載する主張ではありません。

ローンチ前チェックリスト

• Gate Q レポートを確認済み(除外行と古い AE 行について Tim が承認済み)
• Tim が送信する予定のドラフトに [spec unverified] または [brand check skipped] のフラグが残っていない
• パーソナライズ変数がすべて入力済み。リテラルの角括弧が残っていない
• リンクをテスト済み。添付ファイルなし
• batch-send-drafts-skill を実行する前に、1 日の送信上限を Tim と合意済み

<self_healing> 失敗 = ドラフトが生成されない。部分失敗 = いずれかのステージが劣化(そのステージを明示: Q の停止、S の未検証、B のスキップ、D の書き込み失敗)。はしご: 1 回リトライ → 劣化(インラインフラグ付きでドラフト、コアは維持)→ Tim に通知(要約行、無人なら Slack DM)→ リストに対して qualify_lead が利用できない場合は停止。完全な契約: ~/.claude/skills/epiphan-house-rules-skill/reference/self-healing.md。 </self_healing>

<outcome_sidecar> 毎回の実行の最後に ~/.claude/skill-analytics/last-outcome-cold-email-sequence-generator-skill.json を書き込み、~/.claude/skill-runs/cold-email-sequence-generator-skill.jsonl に 1 行追加します:

{"ts":"<UTC ISO8601>","skill":"cold-email-sequence-generator-skill","version":"<frontmatter version>",
 "variant":"<assigned variant or default>","status":"success|partial|error","runtime_ms":0,
 "metrics":{"contacts_in":0,"contacts_qualified":0,"contacts_excluded":0,"stale_ae":0,
            "emails_generated":0,"drafts_created":0,"spec_unverified":0,"brand_skipped":0},
 "error":null,"session_id":"<date>"}

status が partial/error の場合は、error に失敗したステージを明示する必要があります。SessionStart スイープがこれを取り込みます。 </outcome_sidecar>