objection-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Objection Analyzer

异议分析器

Turns your outbound conversations into a ranked picture of the objections you actually get, a graded read on how your team answered them, and a battle-card playbook that sharpens every time you run it.

将你的外呼对话转化为：实际遇到的异议排名、团队异议回复质量评分，以及每次运行都会优化的作战卡片手册。

Output discipline — read this first

输出规范 — 请先阅读本节

When you run this skill, return only the deliverables — nothing else. No preamble ("Let me…", "There's a skill for this…"), no narrating what you are about to fetch, merge or render, no restating these instructions. The user wants the read, not the pipeline.

Answer in the language the user wrote in, and stay in it to the end. Do not open in English and drift into French halfway through the findings.

Ship the numbers as a widget, not as a wall of text. Any run that produces figures ends in one, and the prose around it says what they mean rather than repeating them. The variants and the prose budget per mode are in

references/lgm-handoff.md

. When a run produces no figures, say so and skip the widget.

Every number you print must come from the script's JSON, verbatim. Never re-derive, re-round, or soften a figure into "roughly a third". Never print a rate without its

. If the script suppressed a rate, print the suppression, not a guess.

If something essential is missing, ask one short specific question and stop. Never fabricate an example reply, a count, or a trend.

运行本skill时，仅返回交付成果，不得添加其他内容。不要写开场白（如“让我……”“有一个skill可以……”），不要叙述你将要获取、合并或渲染的内容，不要重述本说明。用户需要的是分析结果，而非流程说明。

使用用户提问时的语言作答，并全程保持该语言。不要先用英文开头，中途切换为法语。

将数据以组件形式呈现，而非大段文字。任何产生数据的运行都需以组件收尾，组件旁的文字应解释数据含义，而非重复数据。组件变体及各模式的文字篇幅限制详见

references/lgm-handoff.md

。若运行未产生数据，需明确说明并跳过组件。

你输出的所有数据必须严格来自脚本的JSON文件。不得自行推导、四舍五入，或把数据模糊表述为“约三分之一”。输出比率时必须附带对应的样本量

。若脚本未生成某一比率，需如实说明，不得猜测。

若缺少关键信息，仅提出一个简短明确的问题后停止。不得编造示例回复、数据或趋势。

Authority — read this first

权限说明 — 请先阅读本节

Everything you need is in this skill folder. No file outside it to grep.

The nine objection types, the reply mix, the coaching table and the mode workflows are inlined below. Do not open a reference file for the common path. Everything else is on demand:

Read	When
`references/coaching-rubric.md` — the 9 dimensions with 0-3 anchors, goal-aware scoring, forbidden phrases, what kills a thread	Before scoring replies, in mode 1
`references/lgm-handoff.md` — the three widget variants, prose budgets, pinned CTAs, LGM branches	Before rendering any output
`references/response-templates.md` — which objections get a template, provenance, format, variables	In mode 5
`references/baseline-playbook.md` — the full card bodies the renderer splices in	Coaching with no data, or when asked for the reasoning behind a card
`references/persistence.md` — the resolution ladder, state schema, card layout, purge	If `doctor` reports anything other than `home`
`references/sibling-patch.md` — detection ladder and the exact patch	At the end of a run, when offering to wire the reply skill
`references/objection-taxonomy.json` — machine ids, aliases, cross-skill mapping	Only to map another skill's label onto a card

Never compute the numbers yourself. Counts, shares, recovery rates, medians, trends and merges come from

python3 scripts/analyze.py

. You classify and you write; the script counts. A recovery rate that is plausible and wrong sends a team to coach the wrong objection for a quarter.

你所需的所有内容均在本skill文件夹内，无需查看外部文件。

九种异议类型、回复组合、指导表及模式工作流程均内联在下方。常规流程无需打开参考文件，其他内容按需查阅：

查阅文件	适用场景
`references/coaching-rubric.md` — 包含9个评分维度（0-3分锚点）、目标导向评分规则、禁用表述、对话终止判定标准	模式1中对回复评分前
`references/lgm-handoff.md` — 三种组件变体、文字篇幅限制、固定CTA、La Growth Machine分支逻辑	渲染任何输出前
`references/response-templates.md` — 适用模板的异议类型、模板来源、格式、变量	模式5中
`references/baseline-playbook.md` — 渲染器拼接的完整卡片内容	无数据指导场景，或被问及卡片背后的推理逻辑时
`references/persistence.md` — 存储层级、状态 schema、卡片布局、清理规则	若 `doctor` 返回非 `home` 状态时
`references/sibling-patch.md` — 检测流程及具体补丁内容	运行结束时，若需关联回复skill
`references/objection-taxonomy.json` — 机器ID、别名、跨skill映射规则	仅需将其他skill的标签映射到卡片时

不得自行计算数据。计数、占比、恢复率、中位数、趋势及合并数据均来自

python3 scripts/analyze.py

。你负责分类和撰写内容，脚本负责统计数据。一个看似合理但错误的恢复率，会导致团队用整个季度指导错误的异议应对方式。

What it does

功能说明

Five modes. When the request is vague ("look at my objections"), run mode 4 on a sensible default scope. When the user wants the full picture, run mode 5.

Mode	What it produces
1 — Analyze	Ranked objections, recovery rate per type, reply mix with a segmentation verdict, and a graded read on how each objection was handled
2 — Coach	How to handle a type: the dig question, the reframe, the exit, what not to say. Works with zero data.
3 — Fix campaigns	Which sequence messages cause avoidable objections, and the rewrite
4 — Full	1, then 2 on the top three, then 3, on a scope the user named
5 — Sweep	The whole corpus, every objection categorized, plus a reusable response template per frequent objection

Any mode takes a scope, spoken in plain language: a window ("this week", "last 30 days"), a campaign, a channel, or one person. Resolve a named identity through

list_identities

and a campaign through

list_campaigns

; if ambiguous, list the matches and ask rather than picking one. "My objections" is its own scope, not a smaller team report: answer in the second person, never compare them to a named colleague, and leave per-rep ranking to

team-performance-dashboard

本工具包含五种模式。若用户请求模糊（如“查看我的异议”），则针对合理默认范围运行模式4。若用户需要完整分析，则运行模式5。

模式	输出内容
1 — 分析	异议排名、各类型异议的恢复率、回复组合及细分结论、各异议处理方式的评分
2 — 指导	某类异议的应对方法：深挖问题、重新表述、退出话术、禁用表述。支持无数据场景。
3 — 优化营销活动	识别引发可避免异议的序列消息，并提供改写方案
4 — 完整分析	先运行模式1，再针对排名前三的异议运行模式2，最后对符合条件的内容运行模式3，覆盖用户指定的范围
5 — 全域扫描	分类所有对话中的每一个异议，并为高频异议提供可复用的回复模板

所有模式均支持范围指定，可用自然语言表述：时间窗口（如“本周”“过去30天”）、营销活动、渠道或特定人员。通过

list_identities

解析指定身份，通过

list_campaigns

解析指定营销活动；若存在歧义，需列出匹配项并询问，不得自行选择。“我的异议”是独立范围，并非团队报告的子集：需用第二人称作答，不得与其他同事的数据对比，按销售代表排名的功能请使用

team-performance-dashboard

。

Where the playbook lives

手册存储位置

Run

python3 scripts/analyze.py doctor

first, every session, and say where it landed in one line. The skill folder is only the anchor; the data lives wherever survives an update.

It takes the first writable of five tiers:

$OBJECTION_PLAYBOOK_DIR

(a shared team folder),

~/.gtm-skills/objection-analyzer/

(the default, survives a reinstall), the skill folder, the working directory, then

paste

. Full ladder in

references/persistence.md

. On

skill

, warn that an update erases it.

In the
paste
tier there is no engine. Say so, label every number estimated, drop the recovery rate below n=10, and emit the state as a fenced code block at the end: "this is your playbook, save it and paste it back next time."

每次会话首先运行

python3 scripts/analyze.py doctor

，并用一句话说明结果。skill文件夹仅为锚点，实际数据存储在更新后仍能保留的位置。

数据会优先存储在以下五个可写层级的第一个：

$OBJECTION_PLAYBOOK_DIR

（团队共享文件夹）、

~/.gtm-skills/objection-analyzer/

（默认位置，skill重装后仍保留）、skill文件夹、工作目录，最后是

paste

层级。完整层级说明详见

references/persistence.md

。若存储在

skill

层级，需提醒用户skill更新会清除数据。

paste
层级无引擎支持。需明确说明，为所有数据标注估算字样，当样本量n<10时不显示恢复率，并在结尾以代码块形式输出状态：“这是你的异议处理手册，请保存并在下次运行时粘贴回来。”

Workflow

工作流程

Step 0 — Resolve and load

步骤0 — 解析并加载

doctor

→ note the tier, the instance count and how many runs already exist. Load

seen_thread_ids

: those threads are already analyzed and must not be re-read. If this is the first run, say so in one line.

运行

doctor

→ 记录存储层级、实例数量及已运行次数。加载

seen_thread_ids

：这些对话已完成分析，不得重复读取。若为首次运行，需用一句话说明。

Step 1 — Get the conversations, and confirm before pulling

步骤1 — 获取对话，并在拉取前确认

Detect the sources silently. Check your own available tools and what the user gave you. Never ask the user to announce their setup, and never narrate the detection.

No source at all → ask for the conversations and stop. Either a CSV with
```
thread_id, direction, timestamp, content
```
(optional:
```
channel
```
,
```
campaign
```
,
```
identity
```
,
```
lead_ref
```
,
```
status
```
), or a pasted thread. Do not invent a corpus.
"My" objections → resolve whose they are first with
```
list_identities
```
: use the obvious one and say which, ask when several could fit. Never silently analyze the whole team when one person asked about themselves.
One or more sources → always confirm before pulling anything, naming the tool, the scope and the rough volume:

"Analyze conversations from La Growth Machine? Scope: campaign 'Q3 Founders', last 90 days, about 60 threads with a reply. Or narrow it down first?" If several tools could serve, list them and let the user pick. A bulk hydrate the user did not want is the main way this skill wastes their money.

With the La Growth Machine MCP, filter before you hydrate:

search_conversations(leadReplied=true, campaignIds?, lastMessageAtFrom?, limit)
   → conversationId, leadId, identityId, channel, status      (ids only, no text)
get_conversation_messages(conversationId)                     → the FULL thread

Drop anything in

seen_thread_ids

, but re-read anything in
recheck_thread_ids
: their outcome can still change, and skipping them freezes them out of the recovery denominator. For a campaign scope,

list_campaigns

→

get_audience_leads

→

get_lead_conversations

also gives you lead names.

Three gotchas that change the numbers:

status: SEND_FAILED
can appear with
direction: received
. It is a failed outbound of ours, not a reply. Trust
```
status
```
over
```
direction
```
.
INFO
and
AUTO_QUALIFY
lines are platform events, and they also arrive with
```
direction: received
```
. Mark them
is_event: true
, never drop them: removing a message shifts every later index, minting a new
```
instance_id
```
for the same objection and double-counting it on the next merge. Unmarked, an event landing after your reply counts as the lead coming back and inflates the recovery rate. Their content is still a signal: an
```
AUTO_QUALIFY
```
note saying "seems to be already equipped" reinforces a
```
competitor_in_place
```
read.
An LGM inbox URL carries the
identityId
, not a conversation id. Start from a campaign name.

With another prospecting MCP, same shape: list threads with a reply, pull the full timeline, map to the run schema. With a CSV, run

python3 scripts/analyze.py normalize export.csv

静默检测数据源。检查可用工具及用户提供的内容。不得要求用户说明其设置，不得叙述检测过程。

无任何数据源 → 请求用户提供对话后停止。可接受包含
```
thread_id, direction, timestamp, content
```
（可选字段：
```
channel
```
,
```
campaign
```
,
```
identity
```
,
```
lead_ref
```
,
```
status
```
）的CSV文件，或粘贴的单条对话。不得虚构对话 corpus。
“我的异议” → 先通过
```
list_identities
```
解析身份：选择明显匹配的身份并说明，若存在多个可能匹配项则询问。不得在用户询问个人异议时，静默分析整个团队的数据。
存在一个或多个数据源 → 拉取前必须确认，说明工具名称、范围及大致数量：

“是否分析La Growth Machine中的对话？范围：营销活动'Q3 Founders'，过去90天，约60条带回复的对话。是否需要先缩小范围？” 若存在多个可用工具，需列出并让用户选择。未经用户确认的批量拉取，是本skill浪费用户成本的主要原因。

连接La Growth Machine MCP时，拉取前需先过滤：

search_conversations(leadReplied=true, campaignIds?, lastMessageAtFrom?, limit)
   → conversationId, leadId, identityId, channel, status      (仅ID，无文本)
get_conversation_messages(conversationId)                     → 完整对话线程

跳过

seen_thread_ids

中的内容，但需重新读取
recheck_thread_ids
中的内容：这些对话的结果仍可能变化，跳过会导致其被排除在恢复率的分母之外。若为营销活动范围，

list_campaigns

→

get_audience_leads

→

get_lead_conversations

还可获取潜在客户名称。

三个会影响数据结果的注意事项：

status: SEND_FAILED
可能伴随
direction: received
。这是我方发送失败的外呼消息，并非回复。优先以
```
status
```
为准。
INFO
和
AUTO_QUALIFY
是平台事件，也会标记为
```
direction: received
```
。需标记为
is_event: true
，不得删除：删除消息会改变后续消息的索引，导致同一异议生成新的
```
instance_id
```
，下次合并时重复计数。若未标记，我方回复后的事件会被视为潜在客户回复，从而高估恢复率。事件内容仍有参考价值：例如
```
AUTO_QUALIFY
```
备注“似乎已配备相关工具”，可佐证
```
competitor_in_place
```
的判断。
LGM收件箱URL包含
identityId
，而非对话ID。需从营销活动名称开始解析。

连接其他潜在客户开发MCP时，流程相同：列出带回复的对话线程，拉取完整时间线，映射到运行schema。使用CSV文件时，运行

python3 scripts/analyze.py normalize export.csv

。

Step 2 — Establish what the conversation is for

步骤2 — 明确对话目标

Ask per campaign, or whenever the goal is not obvious from the thread. One question, alongside the scope confirmation, so it costs no extra round trip:

"What are these conversations meant to produce? A booked meeting, a self-serve signup, a resource downloaded, a partnership, or a nurture with no ask this quarter?"

It is not a formality. The objection barely changes between goals; where the reply points changes completely. The same "too expensive" gets a qualifying question then a slot when the goal is a meeting, a direct answer plus the product for a signup, and no ask at all for a nurture. A rep judged against the wrong destination is judged for the wrong thing.

Pass it on the run as

scope.goal

, one of

meeting

signup

resource

partnership

nurture

unspecified

. The script records it with the run and refuses an unknown value, so a playbook always says what it was scored against. If the user genuinely does not know, use

unspecified

and say plainly that dimension 7 of the handling score is not reliable without it. Mixed scopes: split by campaign rather than averaging across goals.

针对每个营销活动，或对话目标不明确时询问。将该问题与范围确认放在同一轮次，避免额外沟通成本：

“这些对话的目标是什么？预约会议、自助注册、资源下载、建立合作，或本季度无明确诉求的培育？”

这并非形式主义。异议类型基本不受目标影响，但回复方向完全不同。同样是“太贵了”，若目标是预约会议，需先做资格审核再提供时段；若目标是注册，需直接回应并介绍产品；若目标是培育，则无需提出任何诉求。若以错误的目标评判销售代表，结果也会出错。

将目标作为

scope.goal

传入运行参数，可选值为

meeting

signup

resource

partnership

nurture

unspecified

。脚本会记录该目标，且拒绝未知值，因此手册会始终显示评分依据。若用户确实不知道目标，使用

unspecified

并明确说明：若无目标，处理评分的第7维度不可靠。若范围包含多个目标，需按营销活动拆分，而非跨目标平均。

The nine objection types

九种异议类型

An objection is a blocker raised by someone who is still engaging. Someone who disqualifies themselves is

wrong_fit

, which is counted separately and matters just as much (see the reply mix).

Type	Family	Sounds like
`competitor_in_place`	Solution	"we already use X", "covered internally"
`feature_gap`	Solution	"does it do X?", "no SSO, no deal"
`tried_before`	Solution	"we tested this two years ago, it flopped"
`price_budget`	Commercial	"too expensive", "no budget this year"
`timing`	Commercial	"not right now", "maybe next quarter"
`value_doubt`	Commercial	"does this actually work?", "sounds too good"
`process_authority`	Process	"I'd need to run it past X", "procurement owns this"
`scope_mismatch`	Process	"we outsourced this", "we're inbound-only now"
`channel_trust`	Trust	"where did you get my number?", "is this automated?"

The script refuses any type outside this list: a typo would create a phantom category that accumulates forever.

异议指仍在沟通的潜在客户提出的阻碍。主动 disqualify自己的客户属于

wrong_fit

，会单独统计，且同样重要（详见回复组合）。

类型	类别	典型表述
`competitor_in_place`	解决方案类	“我们已经在用X了”“内部已覆盖”
`feature_gap`	解决方案类	“它能做X吗？”“没有SSO就不合作”
`tried_before`	解决方案类	“我们两年前试过这个，效果很差”
`price_budget`	商务类	“太贵了”“今年没有预算”
`timing`	商务类	“现在不行”“也许下个季度”
`value_doubt`	商务类	“这真的有用吗？”“听起来太好得不真实”
`process_authority`	流程类	“我需要先请示X”“采购负责此事”
`scope_mismatch`	流程类	“我们外包了这项工作”“我们现在只做 inbound”
`channel_trust`	信任类	“你从哪里拿到我的号码的？”“这是自动发送的吗？”

脚本拒绝该列表之外的任何类型：拼写错误会创建一个永久累积的虚假类别。

The reply mix — a first-class output, not a side signal

回复组合 — 核心输出，而非次要信号

Alongside the objection ranking, always report the full mix of what came back:

interested

curious

question

objection

wrong_fit

not_interested

auto_ooo

voice_message

. Denominator = replies received, and say so.

wrong_fit

carries its own segmentation verdict, because it is the cleanest targeting evidence there is. Tag the sub-type:

Sub-type	What it means for the list
`wrong-person`	Wrong seniority or function targeted. Fix the title filter.
`not-icp-segment`	Wrong industry or size. Fix the segment filter.
`not-icp-junior`	Seniority floor too low. Raise it.
`job-seeker`	The list source is polluted. Check where the audience came from.

除异议排名外，需始终报告回复的完整组合：

interested

curious

question

objection

wrong_fit

not_interested

auto_ooo

voice_message

。分母为收到的回复总数，并需明确说明。

wrong_fit

包含细分结论，因为这是最清晰的目标定位依据。需标记子类型：

子类型	对客户列表的启示
`wrong-person`	目标职位或职能错误。需修正职位筛选条件。
`not-icp-segment`	行业或规模错误。需修正细分筛选条件。
`not-icp-junior`	职位级别下限过低。需提高级别要求。
`job-seeker`	客户列表来源存在污染。需检查受众来源。

Real or smokescreen

真实异议还是借口

A per-instance flag, not a type. Mark three booleans and let the script apply the 2-of-3 rule:

pre_information

no_specifics

immediate_drop

. The definitions and why the handling differs (dig-then-reframe versus one de-escalating question that offers an honest out) are in

references/coaching-rubric.md

这是每个实例的标记，而非类型。需标记三个布尔值，由脚本应用“三选二”规则：

pre_information

no_specifics

immediate_drop

。定义及不同处理方式的原因（深挖后重新表述 vs 一个降级问题提供诚实退出选项）详见

references/coaching-rubric.md

。

Mode 1 — Analyze (step 3)

模式1 — 分析（步骤3）

Annotate each thread. Reply category; if
```
objection
```
, the type, the objection's message index, a verbatim of 200 characters or less, the three smokescreen markers, and the post-objection outcome.
```
reply_category
```
and
```
post_objection_category
```
are closed vocabularies and the script refuses an unknown value: the second decides the recovery numerator, so it is never guessed. If we answered: the index of our reply, its text as
handling.verbatim
(what the card quotes under "clone this"), the 9-dimension rubric from
```
references/coaching-rubric.md
```
(0-3 each, /27), and a one-sentence
```
should_have
```
on the weakest. Dimension 7 is scored against the goal from step 2, not against a generic idea of a good reply: what you send is a hook, what you steer toward is the destination, and a reply that sends a perfect hook without chaining to the destination scores 1, not 3.
Build the run JSON and hand it to the engine:

bash

python3 scripts/analyze.py analyze run.json > report.json
python3 scripts/analyze.py merge report.json --write
python3 scripts/analyze.py render

Read
report.json
and report only what it says. A type can trip more than one signal:
```
diagnosis.also_firing
```
lists the others, so say "copy, and targeting too" rather than hiding the collision. A type our own opener provokes is never a product gap. Per type: count, share, recovery rate with its n, never-answered rate, median response time, median handling score, first-touch share, smokescreen share, and the copy / targeting / product verdict with its confidence.

Recovery is the metric that carries the analysis, so state it precisely: of the objections we answered and that have had at least 7 days to breathe, the share where the lead replied again. Threads younger than that are

pending

and sit outside both sides of the fraction. Below n=5 the script returns a suppression and you print

n=3 — too few to rate

, never a percentage.

The coaching half. Promote the best-scoring reply per type (22+) as the "clone this" example, name the weakest with its

should_have

, and read the pattern: high score with low recovery is not a handling problem, low score with decent recovery is the easiest win on the board, and a high never-answered rate is usually the biggest finding in a first run.

What not to report is listed in the report's own

not_computed[]

— respect it rather than reasoning around it. Chief among them: revenue lost to an objection (point at

campaign-impact-analyzer

) and which sequence step caused one. And say once, plainly: this reads replies, so it cannot tell you what the people who never replied objected to.

标注每条对话。回复类别；若为
```
objection
```
，需标注类型、异议消息索引、200字符以内的原文、三个借口标记、异议后的结果。
```
reply_category
```
和
```
post_objection_category
```
为封闭词汇表，脚本拒绝未知值：后者决定恢复率的分子，因此不得猜测。若我方已回复：标注我方回复的索引、回复原文作为
handling.verbatim
（卡片中“复制此内容”引用的文本）、
```
references/coaching-rubric.md
```
中的9维度评分规则（每项0-3分，总分/27），以及关于最弱项的一句话
```
should_have
```
。第7维度的评分基于步骤2中的目标，而非通用的“好回复”标准：发送的内容是钩子，最终导向目标，若钩子完美但未关联目标，得分为1而非3。
构建运行JSON并提交给引擎：

bash

python3 scripts/analyze.py analyze run.json > report.json
python3 scripts/analyze.py merge report.json --write
python3 scripts/analyze.py render

读取
report.json
并仅报告其中内容。某一类型可能触发多个信号：
```
diagnosis.also_firing
```
会列出其他信号，因此需说明“文案问题，同时存在目标定位问题”，而非隐藏冲突。我方开场白引发的异议绝非产品缺陷。针对每种类型：报告计数、占比、带样本量n的恢复率、未回复率、中位响应时间、中位处理得分、首次触达占比、借口占比，以及文案/目标定位/产品结论及置信度。

恢复率是分析的核心指标，需精确表述：在我方已回复且至少经过7天的异议中，潜在客户再次回复的比例。不足7天的对话标记为

pending

，不计入分子分母。当n<5时，脚本会返回屏蔽信息，需输出

n=3 — 样本量过小无法评估

，不得输出百分比。

指导部分。推广每种类型中得分最高的回复（22分及以上）作为“复制此内容”示例，指出得分最低的回复及对应的

should_have

，并总结模式：高得分但低恢复率并非处理问题，低得分但恢复率尚可是最容易改进的点，高未回复率通常是首次运行的最大发现。

不得报告

report.json

中

not_computed[]

列出的内容 — 需严格遵守，不得自行推断。其中最主要的是：异议导致的收入损失（请使用

campaign-impact-analyzer

），以及哪个序列步骤引发了异议。需明确说明一次：本工具仅分析回复内容，无法得知未回复用户的异议是什么。

Mode 2 — Coach

模式2 — 指导

Answer from the user's own card if the playbook has data for that type, otherwise from the baseline. Say which one you are using.

Type	What it usually means	Dig with	Then	Never
`competitor_in_place`	Well served, badly onboarded, or a polite exit	"How is [specific job] going on your side?"	Anchor on the gap they name, never on features	Criticize the incumbent
`feature_gap`	A buying signal in a blocker's coat	"What would it need to do day to day?"	Answer honestly: have it, cover it differently, or don't	"It's on the roadmap" with no date
`tried_before`	Objecting to a memory, not to you	"Was it the tool or everything around it?"	Name what is different, specifically	"It's completely different now"
`price_budget`	A comparison you cannot see	"Expensive compared to what?"	Anchor on whatever they name	Discount. Ever, in a first reply
`timing`	Covers sequencing, soft no, and no budget	"What is taking the priority right now?"	Attach to that priority, set a date tied to their calendar	"When would be a good time?"
`value_doubt`	They believe the category, not your claim	"What would you need to see?"	Swap the claim for the mechanism, add a caveat	A bigger number
`process_authority`	A champion who needs arming, or a shield	"What usually decides it on your side?"	Give them one forwardable thing	Ask to be passed to their boss
`scope_mismatch`	The job left. Usually just true	"Who picked it up?"	Ask for the referral, or exit	"But surely you still need to…"
`channel_trust`	Self-inflicted by our own copy	Do not dig	Answer the source truthfully, offer the opt-out unprompted	A vague source, or any pitch in that message

Two rules across all nine: dig before you reframe, and the exit is part of the play. The dig barely moves between goals. What moves is where the reply points: a slot for a meeting goal, the product for a signup goal, the one matching asset plus a question for a resource goal, no ask at all for a nurture. Never make a raised hand wait, and never put the highest-commitment ask on a soft signal. On

channel_trust

, if they ask whether it is automated or AI-written, answer honestly and stop; in an autonomous workflow that is a hand-back-to-a-human case.

This mode gives the angle. It does not write the message. If the user pasted one specific thread and wants something sendable, hand off to

reply-draft-assistant

. And if the MCP is connected but the playbook is empty, offer the upgrade once: "I can pull your conversations and answer this with your own numbers instead of the baseline. Want me to?" — same confirmation gate as Step 1.

若手册中有该类型的用户数据，则基于用户自有卡片作答；否则基于基线内容作答。需说明使用的数据源。

类型	通常含义	深挖问题	后续动作	禁用表述
`competitor_in_place`	需求已被满足、入职体验差，或礼貌性拒绝	“你这边[具体工作]进展如何？”	聚焦对方提出的缺陷，而非功能对比	批评竞品
`feature_gap`	以阻碍形式呈现的购买信号	“它日常需要实现什么功能？”	诚实回应：已有该功能、可通过其他方式覆盖、或没有该功能	“这在 roadmap 上”但不提供日期
`tried_before`	反对的是过往记忆，而非你	“是工具本身的问题还是周边配套的问题？”	具体说明现在的不同之处	“现在完全不一样了”
`price_budget`	存在你看不到的对比	“和什么比起来太贵了？”	聚焦对方提到的对比项	首次回复就打折
`timing`	涵盖优先级排序、委婉拒绝、无预算	“目前优先级最高的工作是什么？”	关联该优先级，设置与其日历绑定的日期	“什么时候合适？”
`value_doubt`	相信品类，但不相信你的主张	“你需要看到什么才能信服？”	用机制替代主张，添加说明	使用更大的数字
`process_authority`	需要支持的拥护者，或挡箭牌	“你们这边通常由谁决定？”	提供一个可转发的内容	请求直接对接其上司
`scope_mismatch`	工作已移交。通常为事实	“谁接手了这项工作？”	请求转介绍，或礼貌退出	“但你肯定仍然需要……”
`channel_trust`	我方文案导致的信任问题	无需深挖	如实说明来源，主动提供退订选项	模糊说明来源，或在该消息中进行推销

适用于所有九种类型的两条规则：先深挖再重新表述，退出话术是流程的一部分。深挖问题基本不受目标影响，变化的是回复导向：若目标是预约会议则提供时段，若目标是注册则介绍产品，若目标是资源下载则提供匹配资产加问题，若目标是培育则不提出任何诉求。不得让主动反馈的客户等待，不得对弱信号提出高承诺诉求。针对

channel_trust

，若用户询问是否为自动或AI生成的消息，需如实回答后停止；在自主工作流中，这种情况需转人工处理。

本模式提供应对角度，不撰写具体消息。若用户粘贴了特定对话并需要可发送的内容，请转交

reply-draft-assistant

。若已连接MCP但手册为空，可提供一次升级选项：“我可以拉取你的对话，用你自己的数据回答，而非基线内容。是否需要？” — 需遵循步骤1中的确认规则。

Mode 3 — Fix campaigns

模式3 — 优化营销活动

Scope fence. In: which sequence message causes an avoidable objection, and its rewrite. Out: benchmarking (

campaign-challenger

), writing a full sequence (

multichannel-campaign-builder

), targeting strategy, attribution.

An objection is a candidate for an upstream fix when it lands at first touch at least 15 points above the base rate of every other type (leave-one-out, so the verdict does not depend on what else was swept), or its verdict is

copy

, or the type is

channel_trust

value_doubt

. Match it to the five causes:

Cause	Signature	Fix
Price named too early	`price_budget` at first touch	Remove the number, lead with the job
Claim without mechanism	`value_doubt` high	Shrink the claim, add the how and a caveat
Personalization that reveals scraping	`channel_trust` rising	Cut the detail a human would not have
Assumed need	`scope_mismatch` clustered in one campaign	This is a list problem, not a copy problem. Say so.
Feature-led opener	`feature_gap` at first touch	Open on the job, keep features for later

Pull the current copy with

get_campaign_messages

when the MCP is there. Each rewrite goes in its own native fenced code block, headed by the step it replaces, above the Variant B widget that carries the message-to-objection mapping. If nothing matches a copy cause, do not force one and do not render a widget: say which objections you checked, why none qualified, and which scope would actually surface a copy pattern.

Never call
edit_campaign_message
or any other write tool from this skill. A live campaign is not something to modify as a side effect of an analysis. Offer the chain instead: Glob for

**/campaign-challenger/SKILL.md

and

**/multichannel-campaign-builder/SKILL.md

; if either is missing, prepend "> Works best with
campaign-challenger
and
multichannel-campaign-builder
. Missing:
<name>
— proceeding with a best-effort version of its step inline."

范围限制。可处理：识别引发可避免异议的序列消息，并提供改写方案。不可处理：基准测试（

campaign-challenger

）、撰写完整序列（

multichannel-campaign-builder

）、目标定位策略、归因分析。

当某一异议在首次触达时的占比，比其他所有类型的基准率至少高15个百分点（留一法，确保结论不依赖其他扫描内容），或结论为

copy

，或类型为

channel_trust

或

value_doubt

时，该异议可作为上游优化的候选。匹配以下五种原因：

原因	特征	修复方案
过早提及价格	首次触达时出现 `price_budget`	删除价格数字，聚焦工作价值
只有主张无机制	`value_doubt` 占比高	缩小主张范围，添加实现方式及说明
个性化内容暴露爬虫痕迹	`channel_trust` 占比上升	删除人类不会知晓的细节
假设需求	`scope_mismatch` 集中在某一营销活动	这是客户列表问题，而非文案问题。需明确说明。
功能导向开场白	首次触达时出现 `feature_gap`	以工作价值开场，功能放在后续

若已连接MCP，通过

get_campaign_messages

获取当前文案。每个改写方案需放在单独的原生代码块中，标注替换的步骤，位于消息-异议映射的Variant B组件上方。若未匹配到文案原因，不得强行生成，不得渲染组件：需说明检查了哪些异议、未符合条件的原因，以及哪些范围可能发现文案模式。

不得通过本skill调用
edit_campaign_message
或其他写入工具。正在运行的营销活动不得作为分析的副作用被修改。需提供关联流程：查找

**/campaign-challenger/SKILL.md

和

**/multichannel-campaign-builder/SKILL.md

；若缺少其中一个，需先说明："> 与
campaign-challenger
和
multichannel-campaign-builder
配合使用效果最佳。缺少：
<name>
— 现将以最佳方式内联其步骤。"

Mode 4 — Full

模式4 — 完整分析

Mode 1, then mode 2 on the top three types, then mode 3 on whatever qualifies for an upstream fix, on the scope the user named. One widget at the end, not three.

先运行模式1，再针对排名前三的异议运行模式2，最后对符合上游优化条件的内容运行模式3，覆盖用户指定的范围。仅在结尾输出一个组件，而非三个。

Mode 5 — Sweep the whole corpus and write the templates

模式5 — 全域扫描并撰写模板

The flagship run. Same engine, three differences from mode 4: no scope filter, every objection categorized rather than a sample, and it ends on reusable team material.

Sweep everything. No campaign or rep filter. Paginate
```
search_conversations {leadReplied: true}
```
to exhaustion, skipping
```
seen_thread_ids
```
, and say the total before you start: "About 340 threads with a reply. Whole corpus, or the last 6 months?" Classify in batches and merge each one, so an interrupted run keeps what it learned. Goals differ across campaigns, so capture
```
scope.goal
```
per campaign, not one global value.
Analyze exactly as mode 1: ranking, recovery rates, reply mix with the segmentation verdict, handling grades.
Recommend. Three to five actions ranked by what they move, each naming the objection, its verdict and the owner.
```
copy
```
is a sequence fix,
```
targeting
```
a list fix,
```
product
```
a routing decision, a high never-answered rate a process fix that beats all three. Every action cites a number from the JSON.
Write one response template per frequent objection, per
```
references/response-templates.md
```
: 8% of objections or above, capped at six,
```
channel_trust
```
always if present, none for a
```
product
```
verdict. Source the words from their own 22+ replies where they exist and say so, otherwise from the baseline and say that instead. Each in its own fenced block with provenance, variables, and what breaks it.
Persist. Write each template to
```
cards.<type>.template
```
with its provenance so
```
render
```
puts it in the card and the next sweep improves it rather than restarting.

Templates are team material, not messages: they carry variables, they are never sent as-is, and drafting a real reply to a real thread is

reply-draft-assistant

's job. Say that when you hand them over, or one will get pasted verbatim into LinkedIn.

核心运行模式。使用相同引擎，与模式4的三个区别：无范围过滤、分类所有异议而非抽样、最终输出可复用的团队素材。

全域扫描。无营销活动或销售代表过滤。循环调用
```
search_conversations {leadReplied: true}
```
直到完成，跳过
```
seen_thread_ids
```
，开始前说明总数：“约340条带回复的对话。扫描全部内容，还是过去6个月的内容？” 分批分类并合并，这样即使运行中断也能保留已分析的内容。不同营销活动的目标不同，需按营销活动捕获
```
scope.goal
```
，而非设置全局目标。
分析：与模式1完全相同，包括异议排名、恢复率、带细分结论的回复组合、处理评分。
建议：按影响程度排序的3-5项行动，每项需说明异议类型、结论及负责人。
```
copy
```
对应序列修复，
```
targeting
```
对应客户列表修复，
```
product
```
对应路由决策，高未回复率对应流程修复（优先级高于前三者）。每项行动需引用JSON中的数据。
为高频异议撰写回复模板，依据
```
references/response-templates.md
```
：占比8%及以上的异议，最多6个；若存在
```
channel_trust
```
则必须包含；结论为
```
product
```
的异议无需模板。优先使用用户得分22+的回复内容，并说明来源；若无则使用基线内容并说明。每个模板放在单独的代码块中，标注来源、变量及失效场景。
持久化存储。将每个模板写入
```
cards.<type>.template
```
并标注来源，以便
```
render
```
将其加入卡片，且下次扫描时可优化模板而非重新生成。

模板是团队素材，而非直接可发送的消息：包含变量，不得直接粘贴发送；针对真实对话撰写回复是

reply-draft-assistant

的职责。交付模板时需说明这一点，避免有人直接粘贴到LinkedIn。

The sibling reply skill

关联回复skill

At the end of a mode 1, 4 or 5 run only, never at load time, check whether a reply-writing skill is installed and offer to wire it to the playbook, so its Objection drafts come from your battle cards instead of a generic angle.

Propose, never write. This skill never edits another skill's files. Show the target's absolute path and the patch as a diff, apply only on an explicit yes, and warn that a package reinstall of that skill can revert it.

The detection ladder, the exact three-part patch for

reply-draft-assistant

, and what to offer when nothing is installed are in

references/sibling-patch.md

. Read it at that point in the run.

仅在模式1、4或5运行结束时（不得在加载时）检查是否安装了回复撰写skill，并提议将其与手册关联，使其异议回复草稿来自你的作战卡片而非通用角度。

仅提议，不得自行修改。本skill不得编辑其他skill的文件。显示目标文件的绝对路径及补丁差异，仅在用户明确同意后应用补丁，并提醒用户该skill重装后补丁会被还原。

检测流程、针对

reply-draft-assistant

的三部分补丁详情，以及未安装时的提议内容，详见

references/sibling-patch.md

。需在运行到该阶段时查阅。

The battle card

作战卡片

render

writes one card per type: the numbers, what your own data shows, the response template once mode 5 has written one, and the baseline body. Section order is in

references/persistence.md

. Two honesty rules it enforces: no exemplar below 22/27, and a hand-edited card is reported and skipped, never overwritten. With zero conversations all nine baseline cards still render.

render

为每种类型生成一张卡片：包含数据、用户自有数据展示、模式5生成的回复模板（若存在）、基线内容。章节顺序详见

references/persistence.md

。需遵守两条诚实规则：得分低于22/27的回复不得作为示例，手动编辑的卡片需标记并跳过，不得覆盖。即使无对话数据，仍会渲染所有九种基线卡片。

Output & LGM handoff

输出与La Growth Machine对接

Every run that produces numbers ends in a widget, and the prose around it says what they mean rather than repeating them. Three variants — the ranking for modes 1, 4 and 5, cause and rewrite for mode 3, a single card for an ad-hoc mode 2 — with a prose budget each, in

references/lgm-handoff.md

. Copyable text never goes inside the widget: the iframe is sandboxed and has no clipboard, so rewrites and templates go in fenced blocks above it. A run that produces no numbers gets prose and no widget.

The exact widget HTML, the placeholder table, the pinned CTA labels per verdict and the resolved handoff branches live in

references/lgm-handoff.md

. Read it before rendering the widget. It also carries the "mention LGM once total across the conversation" rule that governs every branch.

所有产生数据的运行都需以组件收尾，组件旁的文字应解释数据含义，而非重复数据。三种组件变体 — 模式1、4、5的排名组件，模式3的原因与改写组件，临时模式2的单卡片组件 — 各有文字篇幅限制，详见

references/lgm-handoff.md

。可复制文本不得放入组件内：iframe是沙箱环境，无剪贴板权限，因此改写方案和模板需放在组件上方的代码块中。未产生数据的运行仅输出文字，无需组件。

组件的精确HTML、占位表格、各结论对应的固定CTA标签、已解析的对接分支逻辑，均在

references/lgm-handoff.md

中。渲染组件前需查阅该文件。文件还包含“整个对话中仅提及一次LGM”的规则，适用于所有分支。

Examples

示例

What objections are we getting most, and are we handling them well?
Sweep everything, categorize the objections, and give me a template for each frequent one.
Comment répondre à l'objection "on a déjà un outil" ?
Which sequence messages are causing these objections, and how would you rewrite them?

我们最常遇到哪些异议？处理情况如何？
扫描所有内容，分类异议，并为每个高频异议提供模板。
Comment répondre à l'objection "on a déjà un outil" ?
哪些序列消息引发了这些异议？该如何改写？

Testing

测试

bash

python3 scripts/analyze.py --test

Golden cases covering the counting, the recovery cohort, the merge idempotency and every refusal path. The count is whatever the run prints. No green test, no shipping.

bash

python3 scripts/analyze.py --test

涵盖计数、恢复率队列、合并幂等性及所有拒绝场景的测试用例。测试结果以运行输出为准。未通过测试不得发布。