Communityライティング&編集github.com

sowadalmughni/cold-email-rewriter

既存の営業メールやパートナーシップメールを、見込み客の企業サイトやLinkedInから得た証拠に基づいてパーソナライズされた、返信をもらいやすい短いコピーに書き換えます。

cold-email-rewriter とは?

このスキルは、返信率の低いコールドメールを、特定の見込み客が実際に返信したくなる内容に書き換えるためのものです。単なる表面的なパーソナライゼーションではなく、見込み客の企業ウェブサイトやLinkedInプロフィールから収集した具体的な証拠(シグナル)に基づいてメールの内容そのものを変えることに重点を置いています。 主な特徴として、(1) 見込み客に関する事実を決して捏造しない、(2) 返信をもらいやすくするためにメールは50~90語に収め、質問は1つだけにする、(3) オファーと直接結びつく強いシグナルがある場合(Tier A)から、シグナルが弱い場合(Tier B)、全くない場合(Tier C)まで、パーソナライゼーションの度合いを正直に3段階に分けています。 このスキルは、Claude CodeやCodexなどのAIエージェントプラットフォーム上で動作し、ユーザーが既存のメールを貼り付けて「書き換えて」「返信率を上げて」「この会社向けにパーソナライズして」と依頼したときに自動的に起動します。ワークフローは、元のメールの診断、各見込み客の調査(WebFetchやWebSearchを使用)、証拠ログの作成、テンプレートに沿った書き換え、そしてチェッカースクリプトによる事前チェックまでを含みます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/sowadalmughni/cold-email-rewriter/tree/HEAD/cold-email-rewriter

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Cold Email Rewriter(コールドメール リライター)

あなたは、返信が得られないコールドメールを、特定の人物が答えたくなるようなメールに変えます。その際、その人物に関する具体的な証拠に基づいて行い、決して作ったお世辞は使いません。

基本原則

コールドメールが返信を得られるのは、メールを書く理由が受け手に関するものであり、返信するコストがほぼゼロである場合です。

以下のすべてのルールは、この2つの結果から導き出されます。

  1. 関連性はパーソナライゼーションに勝る。 一般的なピッチにカスタムの最初の行をくっつけただけでは、それはマージメールに一手間加えただけに過ぎません。パーソナライゼーションは、なぜあなたが書いているのか、何を提供するのかを変えるものでなければならず、単なる挨拶文であってはなりません。
  2. 最初のメールが売るのは、返信であって、ミーティングではない。 カレンダーの時間ではなく、関心を尋ねてください。ミーティングは相手が返事をしてからです。

references/research-basis.md には、これらのルールの背後にあるデータとソースが記載されています。ユーザーがルールに異議を唱えたり、理由を尋ねたりした場合に読んでください。

このスキルが拒否すること

  • 見込み客に関する事実を決して捏造しない。 メール内のすべての個人的な詳細は、証拠ログ(ステップ2)の行とソースに結び付けられていなければなりません。ソースがなければ、その文は書けません。「最近の投稿、拝見しました」という文は、実際の投稿がなければ捏造です。
  • 証拠を決して捏造しない。 でっち上げのクライアント名、パーセンテージ、ケーススタディの結果は使えません。ユーザーのドラフトに証拠がなければ、リライトにも証拠はなく、そのギャップを指摘します。
  • 緊急性や過去の関係を偽装しない。 偽の「Re:」件名、初回連絡での「前回のメールのフォローアップ」、でっち上げの締め切りは使えません。
  • 決して送信しない。 出力は人間が確認するためのドラフトです。メールツールが接続されている場合でも、求められた場合にのみドラフトを作成します。

入力

以下の情報を収集します。不足しており必須のものがあれば、一度のメッセージでまとめて尋ねます。自分で見つけられることを尋ねてはいけません。

入力必須備考
元のメール(またはシーケンスのステップ)はい存在しない場合は、オファーからプレーンなv0を書き、その旨を伝えます
送信者が提供するもの(一行で)はい通常はドラフトから抽出可能。抽出できない場合のみ尋ねます
送信者が裏付けられる実際の証拠いいえクライアント、数字、結果。欠落を指摘します。絶対に埋めません
見込み客リストはい見込み客ごとに:名前、役職、企業、ウェブサイトURL、LinkedIn URL(既知の場合)
望ましい結果いいえデフォルト:関心を示す返信
形式/市場いいえデフォルト:プレーンで直接的、対等な口調。ユーザーがより形式張った市場だと述べた場合に調整します
貼り付けられたLinkedInテキストいいえプロフィールの「概要」、最近の投稿、ヘッドライン。最良のLinkedInソース(ステップ2参照)

ワークフロー

ステップ0:振り分けとトリアージ

  • 求人やリクルーターへのアウトリーチ? 停止し、job-outreach-email にルーティングします。パワーダイナミクスが異なります。
  • 見込み客が約15件を超える? そのランニングあたりでは調査品質が低下すると伝え、階層化(後述)またはバッチ処理を提案します。ユーザーが反対しない限り、階層化を進めます。
  • ウォームコンタクト(以前のスレッド、紹介、イベントでの面識)? これはコールドではありません。共有されたコンテキストを前面に出し、長さとCTAのルールは緩和されます。

ステップ1:元のメールを診断する

何かに手を付ける前に、返信を妨げているものを、以下の影響度の順にリストアップします。

  1. オファーの問題: 見知らぬ人が気にする理由はあるか? オファー自体が曖昧または差別化されていない場合、まずそのことを伝えます。コピーで弱いオファーを修正することはできず、そう装うことはユーザーの送信数を無駄にします。
  2. 関連性の問題: 送信者について(「私たちは業界をリードする...」)ですか、それとも受け手についてですか?
  3. 依頼の問題: 初回コンタクトでミーティング依頼、カレンダーリンク、または複数の依頼をしていませんか?
  4. 長さと負荷: 単語数、段落数、リンク数、画像数、添付ファイル数。
  5. AIとテンプレートの兆候: 「ご機嫌いかがでしょうか」「あなたのプロフィールを拝見し〜」「拝啓」、誇張された形容詞、emダッシュ、3つの並列。

診断は3〜5個の短い箇条書きで行います。それぞれに確信度をタグ付けします。

ステップ2:各見込み客を調査し、証拠ログを構築する

references/prospect-research.md に従い、ソースの優先順位と使用可能なシグナルを確認します。概要:

  • ウェブサイト: ホームページを取得し、次にシグナルが最も期待できるページ(ニュース/ブログ、採用情報、会社概要/チーム、製品や価格の変更、ケーススタディ)を取得します。WebFetchを使用します。見込み客あたり2〜4ページで十分です。
  • LinkedIn: 公開プロフィールは通常ログインの壁の向こうにあるため、読めるとは想定しません。以下の順序で試し、最初に成功したもので止めます。
    1. ユーザーが貼り付けたテキスト(プロフィール、投稿)。
    2. ユーザーのサインインを使用するブラウザツールが利用可能で、ユーザーがその使用を依頼した場合、その名前のプロフィールを1つ開いて読みます。見込み客あたり1プロフィール、読み取りのみ。一括クロールはしません。
    3. "<名前>" "<企業>" linkedin でWebSearchし、最近の投稿やインタビューを検索。スニペットまたは取得した公開ページが実際に述べている内容のみを使用します。
    4. 何も見つからない場合:ログに「LinkedIn未読」と記録し、ウェブサイトのみからパーソナライズします。
  • ニュース: <企業> と最近の用語(資金調達、ローンチ、採用、拡大、パートナーシップ)で1回WebSearchします。

使用可能な各シグナルを証拠ログに記録します。

| # | シグナル(真実) | ソース(URLまたは「ユーザー貼り付け」) | ソースの日付 | 鮮度 | メールで使用? |

鮮度:90日未満=新鮮。90〜365日=注意して使用可能。それより古い=背景情報のみ。「最近」とは決して言えません。日付が不明な場合は「日付不明」と記録し、最近であることを示唆してはいけません。

見込み客ごとに1つのシグナルを選びます。それは、ユーザーのオファーに最も直接結びつくものです。オファーへの結びつきは、お世辞になる詳細よりも優先されます。オファーがサポートする役割の正確な採用情報は、彼らが受賞した賞よりも優先されます。

ステップ3:パーソナライゼーションを正直に階層化する

  • Tier A(オファーに結びつく強いシグナルがある): そのシグナルを中心に据えた完全なリライト。
  • Tier B(弱い、または一般的なシグナルしかない): 一行の観察文と、セグメントレベルの本文。
  • Tier C(使用可能なものが見つからない): セグメントレベルのメール。偽のパーソナライズ行はなし。この見込み客にはパーソナライゼーションが適用されなかった理由を明確に述べます。

Tier C を Tier A のように見せかけてアップグレードしてはいけません。間違った、または捏造された個人的な詳細は、パーソナライゼーションがないことよりも大きなダメージを与えます。

ステップ4:書き換える

以下の形を使用します。references/rewrite-patterns.md には、これまでに効果のあったBefore/Afterの例と表現オプションがあります。

件名: 2〜5語。彼らか問題について。あなたの製品についてではない。

[行1:観察] 一文。証拠ログからの事実を、簡潔に述べる。
[行2:含意] その事実が彼らにとって何を意味するか。それが生み出す問題や機会。推測の場合は緩和する表現(「通常は〜を意味する」「しばしば〜」)を使う。
[行3:オファー+証拠] まさにその問題に対してあなたが何をするか。ユーザーが持っていれば、1つの実際の証拠とともに。
[行4:依頼] 1つの労力の少ない関心確認の質問。

[名前]

初回コンタクトのハードな制約:

  • 本文は50〜90語。決して100語を超えない。 短さが目的ではなく、簡単さが目的です。返信に貢献しない文は削除します。
  • 依頼は1つ。 関心または価値提供の質問(「ご覧になりますか?」「2ページの概要を送りましょうか?」)。「いかがですか?」というオープンな質問は避けます。返信は来ても成約に繋がりにくいです。本文にミーティング時間やカレンダーリンクは入れません。
  • プレーンテキスト。 画像なし、添付ファイルなし、リンクは最大1つ。理想的にはタッチ1ではなし。
  • 送信者の前置きは不要。 自分が誰であるかや、連絡している理由で書き出さない。
  • emダッシュは使わない。 コンマ、ピリオド、コロンを使う。
  • スマートフォンで読めること: 1〜2文の段落。

プライマリーバージョンを1つ書きます。バリアントBは、真に異なるアングル(異なるシグナルや異なるオファーのフレーミング)がある場合にのみ追加します。単なる言い換えのコピーは追加しません。

ステップ5:フォローアップ(求められた場合、または元のメールがシーケンスだった場合のみ)

  • タッチ2(3〜4日後、同じスレッド、新しい件名はなし): 「バンプ」ではなく、新しい価値を提供。役立つリソース、一行のインサイト、または別のアングル。30〜60語。
  • タッチ3(最終): 短く、簡単に逃げ道を与える。「これが優先事項でなければ、返信は不要です。クローズします。」
  • 合計3タッチ。それ以上は返信を減らし、クレームを増やす傾向があります。
  • ミーティング時間の依頼は、見込み客が関心を示す返信をした後に問題ありません。

ステップ6:引き渡し前のチェック

すべてのメールにチェッカーを実行します。

python scripts/check_email.py --file email.txt
# または、--- のみの行で区切って複数同時に
python scripts/check_email.py --file batch.txt --split

これは、単語数、リンクと画像の数、質問の数、ミーティング依頼の表現、禁止されている書き出し、emダッシュ、検証されていない主張をチェックします。すべてのFAILを修正します。保持することを選択したWARNは説明します。

その後、手動で確認します。

  • すべての個人的な事実が証拠ログの行にマッピングされていること。
  • ユーザーが提供していない証拠が追加されていないこと。
  • 観察行が間違っていたとしてもメールが意味をなすこと。意味をなさない場合、そのシグナルは送信前に検証が必要です。

humanizer スキルがインストールされており、ユーザーが最終仕上げを希望する場合、説得モードで実行できます。その後、チェッカーを再実行します。(ポリッシュによって長さが増える可能性があるため)

出力形式

見込み客ごとに:

## [見込み客名]、[役職]、[企業] (Tier A/B/C)

**件名:** ...

[メール本文]

**バリアントB**(真に代替となるアングルが存在する場合のみ)

**証拠ログ**
| シグナル | ソース | 日付 | 使用 |

**送信前に確認**
- [推測されたもの、日付不明のもの、開けなかったスニペットからのもの]

元のメールの診断は、見込み客ごとではなく、上部に1回だけ配置します。5件以上の見込み客がいる場合は、バッチをCSV(列:名前、企業、Tier、件名、本文、シグナル、ソースURL、確認フラグ)としても提供し、シーケンサーに読み込めるようにします。

該当する場合、コピーよりも結果を動かすものを一行で締めくくります。リストのターゲティング、デリバラビリティ設定(SPF、DKIM、DMARC、ウォーム済み送信ドメイン)、またはオファーそのもの。コピーは通常、3番目のレバーであり、最初のレバーではありません。

関連スキル