email-prompt-building

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Cold Email Prompt Builder

冷邮件提示词构建器

Generate self-contained prompt templates for cold outreach campaigns. Each prompt encodes everything the email generator needs: voice, research data, value prop, proof points, and personalization rules. No external file references at runtime.

为冷邮件推广活动生成独立的提示词模板。每个提示词都包含邮件生成工具所需的全部信息：语气、调研数据、价值主张、证明点和个性化规则。运行时无需引用外部文件。

Architectural Principle

架构原则

This skill is a generator, not a template. It reads the company context file and campaign research, reasons about what fits this specific audience, and produces a self-contained prompt. Each campaign gets its own prompt. Each company gets its own context file. Nothing is hardcoded in this skill.

                          BUILD TIME (this skill)
                          ┌─────────────────────────────────────┐
context file ────────────▶│                                     │
research / hypothesis ───▶│  Synthesize into self-contained     │──▶ prompt template (.md)
enrichment column list ──▶│  prompt with reasoning baked in     │
                          └─────────────────────────────────────┘

                          RUN TIME (email-generation skill)
                          ┌─────────────────────────────────────┐
prompt template (.md) ───▶│                                     │
contact CSV ─────────────▶│  Generate emails per row            │──▶ emails CSV
                          └─────────────────────────────────────┘

该工具是一个生成器，而非模板。 它读取公司上下文文件和活动调研数据，分析哪些内容适合特定受众，然后生成独立的提示词。每个活动对应一个专属提示词，每家公司对应一个专属上下文文件，工具中无硬编码内容。

                          BUILD TIME (this skill)
                          ┌─────────────────────────────────────┐
context file ────────────▶│                                     │
research / hypothesis ───▶│  Synthesize into self-contained     │──▶ prompt template (.md)
enrichment column list ──▶│  prompt with reasoning baked in     │
                          └─────────────────────────────────────┘

                          RUN TIME (email-generation skill)
                          ┌─────────────────────────────────────┐
prompt template (.md) ───▶│                                     │
contact CSV ─────────────▶│  Generate emails per row            │──▶ emails CSV
                          └─────────────────────────────────────┘

What This Skill Reads (inputs)

该工具读取的内容（输入）

Input	Source	What to extract
Context file	`claude-code-gtm/context/{company}_context.md`	Voice, sender, value prop, proof library, key numbers, banned words
Research	`claude-code-gtm/context/{vertical-slug}/sourcing_research.md`	Verified data points, statistics, tool comparisons
Hypothesis set	`claude-code-gtm/context/{vertical-slug}/hypothesis_set.md`	Numbered hypotheses with mechanisms and evidence
Enrichment columns	CSV headers from list-enrichment output	Field names and what they contain
Campaign brief	User describes audience, roles, goals	Target vertical, role types, campaign angle

输入内容	来源	提取内容
上下文文件	`claude-code-gtm/context/{company}_context.md`	语气、发件人信息、价值主张、证明库、关键数据、禁用词汇
调研数据	`claude-code-gtm/context/{vertical-slug}/sourcing_research.md`	已验证的数据点、统计数据、工具对比信息
假设集	`claude-code-gtm/context/{vertical-slug}/hypothesis_set.md`	带机制和证据的编号假设
Enrichment列	列表Enrichment输出的CSV表头	字段名称及其包含的内容
活动简报	用户描述的受众、角色、目标	目标垂直领域、角色类型、活动角度

What This Skill Produces (output)

该工具生成的内容（输出）

A single

.md

file at

claude-code-gtm/prompts/{vertical-slug}/en_first_email.md

containing:

Role line — who the LLM acts as (from context file → Voice → Sender)
Core pain — why this audience has this problem (from research, not generic)
Voice rules — tone, constraints, banned words (from context file → Voice)
Research context — verified data points embedded directly (from sourcing_research.md)
Enrichment data fields — table mapping each CSV column to how to use it
Hypothesis-based P1 rules — rich descriptions with research data, mechanisms, evidence
P2 value angle — synthesized from context file → What We Do, adapted per hypothesis
P3 CTA rules — campaign-specific examples
P4 proof points — selected from context file → Proof Library, with conditions for when to use each
Output format — JSON keys, word limits
Banned phrasing — from context file → Voice → Banned words + campaign-specific additions

一个存储在

claude-code-gtm/prompts/{vertical-slug}/en_first_email.md

的

.md

文件，包含以下内容：

角色行 —— LLM所扮演的角色（来自上下文文件 → 语气 → 发件人）
核心痛点 —— 该受众面临此问题的原因（来自调研数据，非通用内容）
语气规则 —— 语气、约束条件、禁用词汇（来自上下文文件 → 语气）
调研上下文 —— 直接嵌入的已验证数据点（来自sourcing_research.md）
Enrichment数据字段 —— 映射每个CSV字段及其使用方式的表格
基于假设的P1规则 —— 包含调研数据、机制、证据的详细描述
P2价值角度 —— 从上下文文件 → 我们的业务内容中提炼，并针对每个假设进行适配
P3 CTA规则 —— 活动专属示例
P4证明点 —— 从上下文文件 → 证明库中选择，并附带使用条件
输出格式 —— JSON键、字数限制
禁用表述 —— 来自上下文文件 → 语气 → 禁用词汇 + 活动专属新增禁用表述

Building a Campaign Prompt

构建活动提示词

Step 1: Read upstream data

步骤1：读取上游数据

Read these files before writing anything:

claude-code-gtm/context/{company}_context.md
claude-code-gtm/context/{vertical-slug}/sourcing_research.md
claude-code-gtm/context/{vertical-slug}/hypothesis_set.md

在开始编写前，先读取以下文件：

claude-code-gtm/context/{company}_context.md
claude-code-gtm/context/{vertical-slug}/sourcing_research.md
claude-code-gtm/context/{vertical-slug}/hypothesis_set.md

Step 2: Synthesize (the reasoning step)

步骤2：合成（推理环节）

This is where the skill does real work. For each section of the prompt:

Voice → from context file:

Read
```
## Voice
```
section. Copy sender name, tone, constraints, banned words into the prompt.
Do NOT invent voice rules. If the context file doesn't have them, ask the user.

P1 → from research + hypotheses:

For each hypothesis in the campaign, write a rich description using data points from the research.
Explain the MECHANISM (why this pain exists), not just the symptom.
Include specific numbers from the research (coverage percentages, decay rates, time costs).
Write P1 rules that reference enrichment fields by name.
NEVER use generic framing like "scores suppliers" or "manages vendors." Use the
```
platform_type
```
enrichment field or derive the actual description from the company profile. If the enrichment data doesn't include
```
platform_type
```
, instruct the generator to describe what the company actually does based on its description.

Competitive awareness rules (embed in P1/P2):

If enrichment data or research reveals the prospect company has an existing capability that overlaps with your product:
1. NEVER pitch as a replacement. Position as a data layer underneath.
2. Acknowledge their existing tool by name in P1.
3. Shift P2 from "here's what we do" to "here's what we add to what you already do."
4. If the prospect FOUNDED a competing product (career history), either: a. Use Variant D (peer founder) and reference shared context, OR b. Deprioritize. Flag to user as "risky send, needs manual review."

P2 → from context file → What We Do:

Read the product description, email-safe value prop, and key numbers.
Reason about which value angle matters for THIS audience and THIS hypothesis.
Write 2-3 hypothesis-matched value angles with the reasoning embedded.
Use the email-safe value prop, not the raw version (avoid banned words).
Example query rules:
- The example query MUST reference a vertical or category the prospect's platform actually serves. Use enrichment data or company description.
- NEVER reuse the same example query across different prospects.
- Format: "{category} in {geography} under {size constraint}"

P4 → from context file → Proof Library:

Select proof points based on THREE dimensions:

Dimension	Logic
Peer relevance	Proof company should be same size or larger than prospect. Never cite a smaller company as proof to a bigger one.
Hypothesis alignment	Proof point should validate the same hypothesis used in P1.
Non-redundancy	If a stat appears in P2, do NOT repeat it in P4.

If no proof point meets all three criteria, drop P4 entirely (use a shorter structural variant instead).

Banned phrasing → from context file + campaign-specific:

Start with banned words from context file → Voice.
Add any campaign-specific banned phrases discovered during generation or email-response-simulation.

这是该工具的核心工作。针对提示词的每个部分：

语气 → 来自上下文文件：

读取
```
## 语气
```
部分。将发件人姓名、语气、约束条件、禁用词汇复制到提示词中。
不得自行创建语气规则。如果上下文文件中没有相关内容，请询问用户。

P1 → 来自调研数据 + 假设：

针对活动中的每个假设，使用调研数据中的数据点编写详细描述。
解释机制（为什么会存在此痛点），而非仅描述症状。
包含调研中的具体数字（覆盖百分比、衰减率、时间成本）。
编写引用Enrichment字段名称的P1规则。
绝对不要使用“评估供应商”或“管理供应商”这类通用表述。使用
```
platform_type
```
Enrichment字段或从公司简介中提炼实际描述。如果Enrichment数据中不包含
```
platform_type
```
，请指示生成器根据公司描述来描述其实际业务。

竞品认知规则（嵌入P1/P2）：

如果Enrichment数据或调研显示潜在客户公司拥有与你的产品重叠的现有功能：
1. 绝对不要将产品定位为替代品。应定位为底层数据层。
2. 在P1中明确提及他们现有工具的名称。
3. 将P2从“我们的业务内容”调整为“我们能为你现有工具带来的价值”。
4. 如果潜在客户是竞品产品的创始人（从职业经历得知），请选择以下两种方式之一： a. 使用变体D（同行创始人）并引用共同背景，或 b. 降低优先级。标记为“高风险发送，需人工审核”并告知用户。

P2 → 来自上下文文件 → 我们的业务内容：

读取产品描述、适合邮件的价值主张和关键数据。
分析哪些价值角度对该受众和该假设最为重要。
编写2-3个匹配假设的价值角度，并嵌入推理过程。
使用适合邮件的价值主张，而非原始版本（避免禁用词汇）。
示例查询规则：
- 示例查询必须引用潜在客户平台实际服务的垂直领域或类别。使用Enrichment数据或公司描述。
- 绝对不要在不同潜在客户之间重复使用相同的示例查询。
- 格式："{category} in {geography} under {size constraint}"

P4 → 来自上下文文件 → 证明库：

基于三个维度选择证明点：

维度	逻辑
同行相关性	作为证明的公司规模应与潜在客户相当或更大。绝对不要向大公司引用规模更小的公司作为证明。
假设匹配度	证明点应验证P1中使用的相同假设。
非冗余性	如果某个统计数据已出现在P2中，请勿在P4中重复使用。

如果没有证明点同时满足这三个标准，请完全删除P4（改用更简短的结构变体）。

禁用表述 → 来自上下文文件 + 活动专属：

从上下文文件 → 语气中的禁用词汇开始。
添加生成过程中或邮件回复模拟中发现的活动专属禁用表述。

Step 3: Assemble the prompt

步骤3：组装提示词

Write the

.md

file following this skeleton:

markdown

[Role line from context → Voice → Sender]

[Core pain — 2-3 sentences from research. Not generic.]

按照以下框架编写

.md

文件：

markdown

[来自上下文 → 语气 → 发件人的角色行]

[核心痛点 —— 来自调研数据的2-3句话，非通用内容]

Hard constraints

硬性约束

[From context → Voice. Copied verbatim.]

[来自上下文 → 语气，直接复制]

Research context

调研上下文

[Verified data points from sourcing_research.md. Actual numbers, tool names, coverage gaps. This is the foundation for P1.]

[来自sourcing_research.md的已验证数据点。包含实际数字、工具名称、覆盖缺口。这是P1的基础。]

Enrichment data fields

Enrichment数据字段

[Table: field name → what it tells you → how to use it in the email]

[表格：字段名称 → 包含内容 → 在邮件中的使用方式]

Hypothesis-based P1

基于假设的P1

[Per hypothesis: mechanism, evidence, usage rules. All grounded in research data.]

[每个假设对应的：机制、证据、使用规则。全部基于调研数据。]

Role-based emphasis

基于角色的重点

[Map role keywords → emphasis. Use specific data points.]

[将角色关键词映射到重点内容。使用具体数据点。]

Structural variants

结构变体

[Select variant per recipient based on role + seniority from enrichment data. See "Structural Variants" section below for definitions.]

[根据Enrichment数据中的角色+级别选择变体。以下为默认设置，可通过上下文文件或用户输入覆盖。]

Competitive awareness

竞品认知

[Rules for handling prospects with overlapping capabilities.]

[处理拥有重叠功能的潜在客户的规则。]

Proof point selection

证明点选择

[Three-dimensional selection: peer relevance, hypothesis alignment, non-redundancy.]

[三维选择标准：同行相关性、假设匹配度、非冗余性。]

Example query rules

示例查询规则

[Must reference prospect's actual vertical. Never reuse across prospects.]

P1 — [Rules referencing hypotheses and enrichment fields. Use actual platform description, not generic framing.] P2 — [Synthesized value angles per hypothesis. Key numbers from context. Vertical-specific example queries.] P3 — [CTA rules with campaign-specific examples] P4 — [Proof points with conditions. Drop entirely if no proof meets all three criteria.]

[必须引用潜在客户实际服务的垂直领域。绝对不要在不同潜在客户之间重复使用。]

P1 —— [引用假设和Enrichment字段的规则。使用实际平台描述，而非通用表述。] P2 —— [针对每个假设提炼的价值角度。包含上下文文件中的关键数据。垂直领域专属示例查询。] P3 —— [带活动专属示例的CTA规则] P4 —— [带使用条件的证明点。如果没有符合所有标准的证明点，则完全删除。]

Output format

输出格式

[JSON keys]

[JSON键]

Banned phrasing

禁用表述

[From context → Voice + campaign additions]

undefined

[来自上下文 → 语气 + 活动新增内容]

undefined

Step 4: Self-containment check

步骤4：独立性检查

Step 5: Save

步骤5：保存

claude-code-gtm/prompts/{vertical-slug}/en_first_email.md
claude-code-gtm/prompts/{vertical-slug}/en_follow_up_email.md  (if follow-up needed)

claude-code-gtm/prompts/{vertical-slug}/en_first_email.md
claude-code-gtm/prompts/{vertical-slug}/en_follow_up_email.md  (如果需要跟进邮件)

Structural Variants

结构变体

Select structure based on role + seniority from enrichment data. These are defaults. Override from context file or user input.

根据Enrichment数据中的角色+级别选择结构。以下为默认设置，可通过上下文文件或用户输入覆盖。

Variant A: Technical Evaluator (CTO, VP Eng, Head of Data)

变体A：技术评估者（CTO、工程副总裁、数据主管）

4 paragraphs, ≤120 words.

P1: pain with concrete data point
P2: product specs (API-first, pricing model, integration)
P3: low-effort CTA (sample search, not a meeting)
P4: peer proof point (PS)

4段，≤120词。

P1：带具体数据点的痛点
P2：产品规格（API优先、定价模型、集成能力）
P3：低门槛CTA（示例搜索，而非会议）
P4：同行证明点（附言）

Variant B: Founder / CEO (small company, <50 people)

变体B：创始人/CEO（小型公司，<50人）

3 paragraphs, ≤90 words. No PS.

P1: pain tied to their specific stage or market move
P2: value + proof in one paragraph (merge P2+P4)
P3: CTA

3段，≤90词。无附言。

P1：与他们特定阶段或市场行动相关的痛点
P2：价值+证明合并为一段（合并P2+P4）
P3：CTA

Variant C: Executive / Chairman / Board (delegates decisions)

变体C：高管/董事长/董事会成员（委托决策）

2-3 paragraphs, ≤70 words. Forwardable.

P1: one sharp observation about their platform
P2: one sentence value + CTA combined
Optional P3: proof point only if it's a name they'd recognize

2-3段，≤70词。可转发。

P1：关于他们平台的精准观察
P2：价值+CTA合并为一句话
可选P3：仅当证明点是他们熟知的名称时才添加

Variant D: Peer Founder (built something adjacent or competing)

变体D：同行创始人（开发过相关或竞品产品）

2 paragraphs, ≤60 words. Peer-to-peer tone.

P1: acknowledge shared context, state the angle without explaining basics
P2: specific offer, no product pitch

2段，≤60词。同行语气。

P1：认可共同背景，直接说明角度，无需解释基础内容
P2：具体提议，无产品推销

Follow-up Email

跟进邮件

2 paragraphs, ≤60 words total
P1: case study + capability + example
P2: sector-shaped CTA (different angle from first email)

2段，总字数≤60词
P1：案例研究+能力+示例
P2：垂直领域专属CTA（与首封邮件角度不同）

Reference

参考

See references/prompt-patterns.md for patterns distilled from past campaigns.

请查看references/prompt-patterns.md获取从过往活动中提炼的模式。