weekly-performance-advisor

Weekly Performance Advisor

基于用户自己的 La Growth Machine（LGM）数据，生成其专属的 Weekly Performance Advisor：一个双标签页的实时产物。本技能完全自包含——检测环境、评估营销活动、分类回复和填充仪表板所需的所有规则都写在下面。不会引用其他文档。

始终遵守两条硬性规则：

1. 只展示下载用户自己的数据。 只能从其已连接的 MCP 中提取数据。绝不注入其他人的数字、营销活动名称、回复或示例。模板初始为空白；运行时使用用户的实时数据填充。如果无法获取某个值，则显示文档规定的空状态——绝不使用占位数字，也绝不借用其他来源的值。
2. 输出是实时产物，不是已保存的 HTML 文件。 在 Generate 模式下，在内存中填充模板，并使用可用的产物工具将其渲染为实时产物（无论当前 Cowork 版本提供什么工具来创建／更新产物，都不要硬编码工具名称）。刷新时，更新现有产物，而不是创建新产物。assets/dashboard-template.html 文件仅用作构建源文件。

---

两种模式

• Setup 模式（首次运行，或 LGM 尚未连接／尚未选择身份时）：交互式。检测环境，必要时指导安装，并询问范围界定问题。采用对话方式。
• Generate 模式（完成设置后的每次运行）：运行引擎、填充模板并生成产物和简短交接说明。在此模式下遵守输出规范——返回产物和几行交接说明，不要逐步叙述过程。

如果本项目中已完成设置（存在 ./.lgm-wpa/ 快照且 LGM 已连接），则直接进入 Generate 模式；只有缺少信息时才重新提问。

---

Phase 0 — 检测（静默，不提问）

检查你自己的工具列表——不要询问用户安装了什么。

• 是否存在 LGM MCP？ 如果可以使用名为 mcp__* 的 La Growth Machine 工具，即视为存在，例如以下任意工具：list_identities、list_campaigns、get_campaign_stats、get_conversations_to_reply、get_conversation_messages、search_conversations。（在终端中也可以运行 claude mcp list，确认输出中有 LGM 服务；但只要工具可用即可——绝不询问用户。）
• 是否存在 CRM／交易 MCP？ 是否可以使用 HubSpot MCP（交易／公司／联系人工具）？
• 是否可以使用 campaign-impact-analyzer 技能？（用于构建可选的交易／€ 层。）

记录这三个布尔值，然后继续。不要告知用户检测结果。

---

Phase 1 — LGM MCP 门槛

如果存在 LGM MCP： 用一行说明“LGM connected ✓”，然后进入 Phase 2。

如果不存在 LGM MCP： 仪表板完全基于 LGM 数据构建，因此目前无法运行。用一句话解释，然后指导安装（不要询问“是否已安装”——你已经知道它没有安装）：

1. 在 gtm-system 仓库中运行安装程序并完成浏览器登录：

   sh install.sh
   

   （或者使用该仓库 README 提供的 curl 单行命令）。身份验证采用浏览器 OAuth——无需粘贴 API 密钥。
2. 如果还没有 LGM 账户 → 请前往 https://app.lagrowthmachine.com 注册，然后重新运行安装程序。
3. 用户运行安装程序后，重新检测（Phase 0）。循环执行，直到 LGM 工具出现，然后继续。

保持友好简洁；这只是门槛，不是说教。

阶段 2 — 身份范围（一个实际问题）

调用 list_identities。接着，为了选择一个合理的默认项，获取每个身份的活动负载：调用 list_campaigns {status:"RUNNING"}（分页），并按 identity.id 统计运行中的活动数量。

询问要跟踪哪个身份，默认选择运行中活动最多的身份（说出其名称，并请对方确认或切换）。说明之后可以添加更多身份，以查看团队整体情况（仪表板支持多个身份——合并其活动和回复）。

存储选定的身份 ID 和显示名称；以下所有 LGM 数据拉取均限定在这些身份范围内。

---

阶段 3 — 交易层（可选，增量添加——绝不阻塞）

仪表板内置了一个**“来自活动的交易”框。没有 CRM 时，该框会显示 — 和说明 “连接 HubSpot 以拉取交易数据”。可以提供更丰富的数据层，但绝不能因此阻塞构建。**

• 存在 CRM/交易 MCP → 现在就询问：“要我添加交易/€ 数据层（哪些活动实际带来了销售管道），还是先发布仪表板，之后再添加？”
• 不存在 CRM MCP → 询问“你用什么跟踪交易？”（HubSpot / Salesforce / Sheets / 其他 / 无）。
  • 使用 HubSpot 但尚未连接 → 提供连接选项（连接后即视为“存在”）。
  • Salesforce / Sheets / 其他 / 复杂情况 → 优先构建仪表板；之后再添加交易层。

委派（不要在此处重新实现关联逻辑）：

• 如果 可用 campaign-impact-analyzer → 将 LGM×CRM 交叉引用委派给它，以填充“来自活动的交易”框（交易数量 + €、本周数据、整体组合数据）。使用其输出填入 {{DEALS_VALUE}} / {{DEALS_NOTE}}。
• 如果 不可用 campaign-impact-analyzer → 不要阻塞，也不要内联执行一连串关联操作。发布仅包含 LGM 数据的仪表板（交易框显示 —），并在交接说明中添加提示： “要添加交易/€ 数据层，请从 gtm-system 安装 campaign-impact-analyzer，然后重新运行。”

---

阶段 4 — 构建

使用用户的实时数据运行引擎（见下文）→ 填写 assets/dashboard-template.html 中的所有占位符 → 使用可用的 artifact 工具渲染为实时 artifact（2 个标签页；首次运行时创建，后续运行时更新现有 artifact）→ 将本周快照写入 ./.lgm-wpa/。

阶段 4.5 — 设置每周刷新（例行任务）

仪表板有一个 ↻ 刷新按钮。只有设置了每周例行任务，重新拉取数据并更新 artifact 后，该按钮才会生效——因此可以询问是否现在设置（仅在对方同意时执行）：

询问（英文，尽量照原文）： "To make the ↻ Refresh button live, I can set up a weekly routine that re-pulls your La Growth Machine data and updates this dashboard every Monday morning. Want me to set it up?"

• 同意 → 使用可用的调度工具创建定时任务，频率为每周一早上 （每周）；任务提示词需在相同身份范围内以 Generate 模式重新运行本技能，并 更新现有 artifact（而不是创建新的 artifact）。建议存储以下任务提示词：

  "Re-run the weekly-performance-advisor skill in Generate mode for identity/identities []: pull fresh La Growth Machine data, recompute the engine, update the existing Weekly Performance Advisor artifact, and write this week's snapshot to ./.lgm-wpa/. Do not ask questions; setup is already done."

  • 在运行时记录工具返回的任务 ID，并传入模板作为 {{REFRESH_TASK_ID}}，以便 ↻ 按钮触发该用户自己的任务。该 ID 在创建时按用户解析——绝不要在发布文件中硬编码 ID。
  • 按钮已会调用 runScheduledTask(<that id>)，并在无法运行时显示友好提示。
• 不同意 / 跳过 → 将 {{REFRESH_TASK_ID}} 设为空字符串。↻ 按钮会退回显示友好提示（不会影响其他功能）；说明对方随时可以重新运行本技能来启用该例行任务。

阶段 5 — 交接

成果呈现后，进行简短交接（不要逐步叙述）：

• To do 标签页 = 本周要做的事：要采取的行动、要处理的回复（按紧急程度排序），以及唯一需要修复的 🔴 营销活动。Weekly performance 标签页 = 统计数据：包含 WoW/30 天变化的计数 KPI、按量加权的健康指标，以及完整的营销活动全景。
• **每周刷新：**如果他们启用了例行任务（阶段 4.5），↻ 按钮和周一任务会让仪表板保持最新；否则，他们可以随时重新运行此技能（并在那时启用例行任务）。 累积 2 周以上的快照后，变化数据和 30 天趋势才会显示。
• **例行任务状态：**确认是否已设置周一自动刷新（阶段 4.5）。如果他们跳过了，请提醒他们，在例行任务创建之前，↻ 按钮不会生效。
• **在 LGM 中对回复分类：**提醒他们在 LGM 收件箱中为回复添加标签（感兴趣 / 不感兴趣）——这样下周的积极回复数量和趋势会更准确。
• 成果中的 Fix-this 按钮会打开一个可复制粘贴提示词的模态框（现成的提示词会调用对应的 gtm-system 技能——/reply-draft-assistant、/campaign-challenger、/sales-nav-search-builder、/won-deal-icp-finder），供他们粘贴到新对话中。

---

引擎（内嵌 — 完整复现）

所有评分均为确定性的。百分比取整数。文案中不要使用短横线（en dash），使用普通连字符。

E1. 拉取（限定为所选身份）

1. list_identities → 解析所选身份 ID 和名称。
2. list_campaigns {status:"RUNNING"}（分页）→ 保留 identity.id ∈ 所选身份的营销活动。
3. 对每个保留的营销活动调用 get_campaign_stats → 获取各渠道计数器。
4. 回复 — 分两次拉取（不要混为一谈）：
   • 待处理回复列表 → get_conversations_to_reply {identityIds:[...selected]}： 当前等待你回复的对话串。用于生成 E8（To do 标签页中的行）。
   • 本周计数集合 → 使用 search_conversations 筛选本周收到的回复（潜在客户自周一以来有回复），范围限定为所选身份 — 无论你是否已经回复。用于生成 E9 计数 KPI。这能确保概览计数准确：你已经回复过的“感兴趣”潜在客户虽然已离开待处理队列，但仍必须计入本周。
   • 对于任一集合中尚未出现在最新快照 classifiedReplyIds 中的对话串，读取 get_conversation_messages 并进行分类（增量处理 — 不要重新分类已知 ID）。

E2. 规范化每个营销活动

campaign = {
  id, name, contacted,
  li: {accept, reply, csent, msent} | null,     // % values; csent = connection-request sends, msent = message sends
  em: {sent, deliv, open, reply, click, bounce, atag, eng} | null
}

• atag = 邮件步骤包含跟踪用的 <a href> 链接（只有这种情况下，点击才是真正的 KPI）。
• eng = 邮件有任何可计分的互动 =（邮件回复 > 0）或（邮件点击 > 0）。
• contacted < 20 的营销活动属于低样本量：列出，但不要评分或排序。

E3. 基准常量（内置 — 不得引用，成果中不得出现来源或品牌名称）

每个 KPI 分为 3 个区域：🟢 达标 / 🟡 关注 / 🔴 待修复。(good, floor, direction)：

linkedin_acceptance = (30, 20, up)
linkedin_reply      = (25, 15, up)
email_open          = (60, 45, up)
email_reply         = (6,  3,  up)      # cold-email calibration
email_click         = (8,  4,  up)      # shown, NOT status-driving
email_bounce        = (15, 25, down)    # lower is better
email_deliverability= (90, 80, up)      # not shown as a gauge (see note)

• 不设置送达率指标。在 LGM 中，Delivered = Sent − Bounced，因此“送达率”就是 100 − bounce，并非真正反映邮件进入收件箱情况的信号。我们改为跟踪退信率（可采取行动的邮件技术健康指标）。五项整体指标为：LinkedIn 接受率、LinkedIn 回复率、邮件退信率、邮件打开率、邮件回复率。
• MIN_SEND = 10：KPI 或步骤至少需要 10 次发送才能评分，否则标记为“样本量不足”。

**zone(k, v)：**up → 若 v≥good，则为 g；若 v≥floor，则为 y；否则为 r。down → 若 v<good，则为 g；若 v≤floor，则为 y；否则为 r。 sev(k, v)（低于底线的幅度，≥0）：up → max(0,(floor−v)/floor)；down → max(0,(v−floor)/floor)；四舍五入到 3 位小数。

E4. 每个活动的 KPI 集合（kpis_for）

按顺序输出 (kpi, value, state, driving)：

• 如果有 li：linkedin_acceptance（csent≥10 时计分，否则为 insuf）、linkedin_reply（ msent≥10 时计分，否则为 insuf）。
• 如果有 em，且 em.sent≥10 且 em.eng：email_open、email_reply，然后仅当 em.atag 时加入 email_click（不计为驱动项），再加入 email_bounce。
• 如果有 em，且 em.sent≥10 但 em.eng 为假：不对任何邮件 KPI 计分 → 显示该行 “Email：{sent} 封已发送 · {open}% 打开率 · 0 条回复 · 0 次点击 - 已送达，无互动可供评分”。

E5. 主渠道加权 → 状态

• li_sends = li.msent (or 0)、em_raw = em.sent (or 0)、total = li_sends + em_raw。
• primary = 'li' if li_sends ≥ em_raw else 'email'。SEC_MIN = 0.30。
• balanced = li_sends>0 AND em scored AND min(li_share, em_share) ≥ 0.30。
• is_driving(k)：
  • email_click → 永不计为驱动项。
  • linkedin_* → li present AND li.msent≥10 AND (primary=='li' OR balanced)。
  • email_bounce → 只要邮件已计分，就计为驱动项（技术健康始终计入）。
  • email_open / email_reply → email scored AND (primary=='email' OR balanced)。
• driving_reds / driving_yellows = 状态为 🔴 / 🟡 的驱动 KPI。
• status = 如果有任何 driving_reds，则为 To fix；否则，如果有任何 driving_yellows，则为 Watch；否则为 On target。 （内部的 “On target” 表示健康状态；绝不显示 “Healthy” 或 “needs work” 这两个词。）
• 次要渠道的红色指标（状态为 🔴 且不是驱动项，指标为 linkedin_acceptance/linkedin_reply/ email_open/email_reply）→ 不要因此改变整个活动的状态；改为添加 “待修复的邮件环节” 或 “待修复的 LinkedIn 环节” 标签。

E6. 修复项 #1（诊断）：针对待修复的活动

• 在 driving_reds 中，按漏斗顺序选择最薄弱的步骤，排除最后的分手步骤： FUNNEL = [email_bounce, linkedin_acceptance, email_open, linkedin_reply, email_reply] → 按此顺序选择 第一个红色步骤。
• s = sev(k, v)；conf = high if s≥0.4 else medium。如果被标记的步骤发送量 <20，则将 conf 上限设为 medium（驱动证据不足）。逐字展示“当前文案”时，标注步骤类型（Intro / Follow-up / BreakUp）；被标记的步骤不得是分手步骤。
• 每个 KPI 对应的原因 + 路由技能：

  linkedin_acceptance -> "targeting or connection note" -> sales-nav-search-builder
  linkedin_reply      -> "message copy"                 -> campaign-challenger
  email_open          -> "subject line or setup"        -> campaign-challenger
  email_reply         -> "message copy"                 -> campaign-challenger
  email_bounce        -> "list quality / warm-up"       -> won-deal-icp-finder   (also flag list hygiene / email verification)
  

• 渠道建议（reco）：如果 LinkedIn 回复和邮件回复均已计分，且其中一个为红色、另一个为绿色或黄色，则建议优先使用表现较强的渠道，并改进或取消较弱渠道的环节。
• 排序： prio = maxsev(driving_reds) × contacted。待修复卡片按 prio 降序排列。

E7. 按数量加权的整体指标

对于五个指标中的每一个，在渠道活跃且已计分的活动中汇总Σ分子 / Σ分母（而非百分比的平均值）。四舍五入到整数百分比。N_LI = 为 LinkedIn 指标提供数据的活动数；N_EM = 为邮件指标提供数据的活动数。指标区间 = zone(k, weightedValue)。

E8. 回复分类 + 紧急程度排序

• 根据对话，将每条新收到的回复分类为 interested / neutral / not_interested / wrong_fit。hot = 明确提出通话/会议请求。corr = LGM 自动判定为感兴趣，但你在此处进行了更正。chan ∈ {LINKEDIN, EMAIL}。act（可采取行动）= cls ∈ {interested, neutral}。
• 等待天数 = floor((asOf − lastMessageAt)/86400000)，最小为 0；urgent = 可采取行动且等待天数 > 3。
• 紧急程度排序（仅限可采取行动的回复）：第 0 组 = 通话请求（hot），第 1 组 = 感兴趣，第 2 组 = 中立； 每组内等待时间最长的排在最前。每行显示 “等待 X 天” 徽标（紧急 → 红色标记）。
• 仅将感兴趣和中立的回复列为行。 not_interested / wrong_fit 折叠为一个计数，并放在 “在 LGM 收件箱中打开 ↗” 链接后；在此处显示小型 “已更正 N 条” 计数，让自动判定更正保持醒目。 不回写到 LGM（用户在 LGM 中进行验证）。

E9. KPI 计数（北极星指标、全组合、本周）——可安全刷新

从本周已收到的集合（E1 步骤 4b，search_conversations）获取计数，不要 从待处理队列获取，这样已回复的潜在客户仍会计入。

• TOTAL_POSITIVE_REPLIES（主指标）= 本周收到的、分类为 interested 的对话数 （包括来电请求），覆盖整个组合。
• TOTAL_REPLIES（次要指标）= 本周收到的对话数（本周任何潜在客户回复）。
• 周累计 + 可安全刷新：在快照中保存本周的正向回复数和总回复数（以及 classifiedReplyIds）。在同一 ISO 周内重新运行时，合并已计数 ID 和新获取的集合——刷新只能增加，绝不能删除本周已计入的回复。（跨周时，计数按预期每周重置。）
• 切勿将“0 个正向潜在客户”作为主指标显示；如果为零，只显示 0，并注明增幅限制。

E10. 周期比较（增幅）

从 ./.lgm-wpa/ 中的滚动快照历史记录获取（保留 ≥5 周）：

• 每个计数 KPI 和每个仪表盘指标都显示与上周相比和与过去 30 天周平均值相比 （最近 ≤4 个此前周）。使用箭头 ▲/▼；上升 = 绿色，下降 = 红色——退信率反转（下降为好）。
• 单位：计数无单位；仪表盘指标使用 pt。增幅为零时 → +0。
• 暂无历史记录 → 显示 — · 趋势将在 2+ 周后开始，并标注 "基准周 - 累积 2+ 周的历史数据后开始显示趋势。" 有历史记录时，标注 "增幅比较本周与上周及过去 30 天周平均值。"

E11. 健康卡片（仪表盘指标下方，“每周表现”标签页）

将任何单句“结论”替换为两张卡片：

• 🟢 On target — 列出当前为绿色的仪表盘指标（`"LinkedIn acceptance 53%, email bounce 7% ...
  • 全部达标。"`）。
• 🟡 Watch — 针对每个非绿色仪表盘指标，使用 "<KPI> <v>% - 低于/高于 <good>% 目标 <gap>pt， <note>"，其中 note = 如果 gap ≤ 3，则为 仅需优化，无需紧急处理，否则为 值得检查一下（如果该指标为红色，则为 需要改进）。添加徽标 N 个营销活动待修复。然后添加一行红色文字： "实际修复：N 个营销活动需要在其主要渠道上修复 - <name>（<KPI> <v>%）；……先重写该文案。"——这样 🔴 营销活动会继续显示在此标签页，并指向“待办”标签页。
• **空状态：**没有 🔴 营销活动时，“待修复”卡片区域显示 "本周没有 🔴 营销活动 - 所有正在运行的营销活动在其主要渠道上均为 On target 或 Watch。"

E12. 状态用语（全文统一使用以下三个词）

🟢 On target · 🟡 Watch · 🔴 To fix——在仪表盘图例、两张健康卡片、全景徽标和营销活动卡片中保持一致。不要显示“健康”“需要改进”或“To improve”。

---

填充约定 — assets/dashboard-template.html 中的占位符

读取 assets/dashboard-template.html，计算以下值，替换每个 {{...}}，并将结果渲染为实时产物。转义所有用户提供的文本（活动名称、回复备注、潜在客户姓名），以用于 HTML。仪表的彩色区间和目标刻度线须在填充时根据 E3 常量计算得出（参见仪表代码片段）——切勿硬编码区间宽度；更改阈值时，区间也会随之移动。

占位符	来源 / 值
{{WEEK_LABEL}}	当前周的星期一，例如 Jul 6, 2026（仅用于标题）。
{{LAST_UPDATE}}	本次数据拉取的日期，例如 Jul 7, 2026。
{{REFRESH_TASK_ID}}	Phase 4.5 中运行时捕获的计划任务 ID（此用户自己的任务）。如果未创建例行任务，则填入空字符串——此时 ↻ 按钮会改为显示友好的提醒。切勿在模板文件中写入真实 ID。
{{SR_SUMMARY}}	单行屏幕阅读器摘要：Weekly Performance Advisor, week of {WEEK_LABEL}: {posReplies} positive replies of {totalReplies}; {tofixCount} campaigns to fix; {nAct} actionable replies including {nHot} call requests.
{{TODO_COUNT}}	nAct（可采取行动的回复）——待办标签页的计数徽标。
{{MOVES}}	2-3 个 <li>...</li> 项目（参见代码片段 M）。根据电话请求、表示感兴趣的回复、中性回复和待修复数量生成。
{{N_ACT}}	可采取行动的回复数量（用于 3 处）。
{{N_HOT}}	电话请求数量。
{{REPLY_PROMPT}}	已转义的回复分类提示词（代码片段 P）。
{{REPLY_ROWS}}	每条可采取行动的回复对应一个 <tr>，按紧急程度排序（代码片段 R）。
{{INBOX_LINK}}	如果存在不可采取行动的回复：填写带修正后计数的收件箱链接（代码片段 I）；否则填写空字符串。
{{TOFIX_CARDS}}	按 prio 排序的待修复卡片（代码片段 C）；或者填写空状态卡片（E11）。
{{TOTAL_POSITIVE_REPLIES}}	posReplies（E9）。
{{TOTAL_REPLIES}}	totalReplies（E9）。
{{POS_REPLIES_DELTA}} / {{TOTAL_REPLIES_DELTA}}	每个计数 KPI 对应的变化量 span（代码片段 D）。
{{DEALS_VALUE}}	默认值为 —；如果运行了交易数据层（Phase 3），则填入交易数量 / €。
{{DEALS_NOTE}}	默认值为 connect HubSpot to pull deal data；否则填写简短的交易备注。
{{DELTA_CAPTION}}	E10 标题（历史数据与基准数据的对比）。
{{N_LI}} / {{N_EM}}	仪表数据源计数（E7）。
{{GAUGES}}	按以下顺序排列的五个总体仪表：linkedin_acceptance、linkedin_reply、email_bounce、email_open、email_reply（代码片段 G，每个仪表都需放在带有 delta 的 .stat 中）。
{{HEALTH_CARDS}}	.hcards 区块（E11，代码片段 H）。
{{PANORAMA_ROWS}}	每个评分活动对应一组 prow+drow，先列待修复项，再按联系人数降序列出关注 / 达标项（代码片段 PANO）。
{{LOW_SAMPLE_ROWS}}	低样本表头行 + 每个低样本活动对应一行（代码片段 LOW）；如果没有则填写空字符串。

代码片段 G — 仪表（根据常量计算区间）

对于 (good, floor) 的“越高越好” KPI；指针左侧位置 = clamp(value,0,100)%；z = zone(k,value)：

<div class="stat"><div class="k">{LABEL}</div>
 <div class="gauge"><span class="gbands">
  <span class="gb r" style="left:0;width:{floor}%"></span>
  <span class="gb y" style="left:{floor}%;width:{good-floor}%"></span>
  <span class="gb g" style="left:{good}%;width:{100-good}%"></span>
  <span class="gtick" style="left:{good}%"></span>
  <span class="gneedle {z}" style="left:{value}%"></span></span>
  <span class="gval {z}">{value}%</span><span class="gtgt">target ≥{good}%</span></div>
 <div class="dwrap">{DELTA}</div></div>

对于**“越低越好”**的 KPI（email_bounce）：区间为 g（0→good）、y（good→floor）、r（floor→100），刻度位于 good，目标文本为 target <{good}%。标签：LinkedIn acceptance、LinkedIn reply、Email bounce、Email open、Email reply。同一仪表标记（通过 .dg 实现行布局）也用于活动详情行——在详情行中不带 .stat / delta 包装。

代码片段 D — 变化量 span

<span class="delta"><span class="dl">vs last wk</span> <b class="d {cls}">{▲/▼ ±d}{unit}</b><span class="dl">· vs 30d</span> <b class="d {cls}">{▲/▼ ±d}{unit}</b></span>

cls ∈ up/down/flat。没有历史数据时 → <span class="delta none">- · trend starts after 2+ weeks</span>。

代码片段 M — 动向列表（示例结构；根据数据调整）

<li><b>Answer the {nHot} call requests</b> ({callNames}){ - firstCall waited Xd if urgent}. Then reply to {firstInterested} and nudge the {nNeutral} warm neutrals.</li>
<li><b>Rewrite the flagged copy</b> on the {N} campaign(s) leaking their main-channel reply rate.</li>
<li><b>Keep classifying replies in LGM</b> so next week's trend stays live.</li>

如果没有回复，则删除第 1 行；如果没有待修复活动，则删除第 2 行。切勿编造；只提及数据中已有的名称 / 数量。

代码片段 R — 回复行（仅限可采取行动的回复，按紧急程度排序）

<tr><td class="cname">{lead}{ <span class="hotpill">CALL</span> if hot}{ <span class="corrpill" title="LGM auto-qualify said interested; corrected">corrected</span> if corr}</td>
<td><span class="wbadge{ urgent}">waited {X}d</span></td>
<td><span class="chan {li|em}">{LINKEDIN|EMAIL}</span></td>
<td><span class="rcls {good|neu}">{interested|neutral}</span></td>
<td class="rnote">{why}</td></tr>

代码片段 I — 收件箱链接（带修正后的计数）

<a class="inboxlink" href="https://app.lagrowthmachine.com/" target="_blank" rel="noopener">{N} more replies (not interested / wrong fit){, M corrected} - open in LGM inbox ↗</a>

代码片段 P — 回复分类提示词（写入按钮的 data-prompt，并进行转义）

Use the /reply-draft-assistant skill. Handle my {nAct} actionable replies across all running campaigns, most urgent first: {nHot} call requests ({callNames}) first, then {nInterested} interested and {nNeutral} warm neutrals to nudge (some have waited over a week). Draft each in the thread language for my approval. If the /reply-draft-assistant skill is not installed, download it from https://github.com/LaGrowthMachine/gtm-system first, then run it.

片段 C — 待修复卡片

包含 card-name 的卡片，带有 badge tofix + contacted N 元信息，以及一个 修复此项按钮，其 data-prompt（经过转义）按路由技能构建：

• campaign-challenger：Use the /campaign-challenger skill. Challenge campaign "{name}" ({label} {value}%, below the {floor}% floor, likely {cause}): rewrite the current copy of the flagged step. If the /campaign-challenger skill is not installed, download it from https://github.com/LaGrowthMachine/gtm-system first, then run it.
• sales-nav-search-builder：... Rebuild the targeting for campaign "{name}" ({label} {value}%, below the {floor}% floor): draft a tighter Sales Navigator search and connection note. ...
• won-deal-icp-finder：... Clean the audience for campaign "{name}" ({label} {value}%, below the {floor}% floor): rebuild it from a verified ICP list. ...

接着是 fix1 区块（Fix #1 标签、KPI 标签、{conf} confidence、{value}% now · target ≥{good}% · floor {floor}% · {gap} pt(s) under target、Likely cause: {cause}）、可选的渠道提示 reco 框和 watch/leg 标签、可选的 diag-out 诊断行 + focus“要改写的当前文案” 区块（原样呈现步骤文案、渠道 + 步骤类型），以及包含完整漏斗仪表盘的 <details>。使用 模板 CSS 中的确切类名。

片段 PANO / LOW — 全景行

每个评分活动都包含可点击的 prow 行 + 隐藏的 drow 详情：列为 Campaign、Contacted、Accept、 LI reply、Email open、Email reply、状态徽章、Fix #1。缺失 KPI → —；样本不足/无互动 → n/a（类名 zi）。低样本区块：lowhead 行 Below sample floor - listed for completeness, not scored，接着每个低样本活动各有一行 prow low，其详情写明 {contacted} contacted · ... - not scored (below the 20-contact floor; rates on so few sends aren't reliable).

---

快照持久化（在当前项目中）

在技能运行的项目中创建 ./.lgm-wpa/，并写入当前 ISO 周的 ./.lgm-wpa/snapshot-<YYYY>-W<ww>.json。存储：

{
  "week": "2026-W28",
  "identities": ["<id>", ...],
  "counts": { "posReplies": N, "totalReplies": N },
  "positiveReplyIds": ["<conversationId>", ...],   // this-week ids classified interested (for the union)
  "weekReplyIds": ["<conversationId>", ...],        // this-week ids that received a lead reply
  "gauges": { "linkedin_acceptance": %, "linkedin_reply": %, "email_bounce": %, "email_open": %, "email_reply": % },
  "campaigns": [ { "id", "name", "contacted", "status", "fix1": {...}|null, "kpis": {...} } ],
  "classifiedReplyIds": ["<conversationId>", ...]   // every id already classified (skip-list, incremental)
}

• **首次运行 = 基线：**没有先前快照 → 所有变化量显示为 —，并显示基线说明。
• 覆盖前，加载最新的先前快照，以计算 WoW + 30-day 变化量，并跳过 已分类的回复 id。保留 ≥5 周（清理更早的快照），以便计算约 4 周平均值。
• **每个 ISO 周仅保留一个快照。**在同一周重新运行时，更新该周的文件：将新拉取的数据与 positiveReplyIds / weekReplyIds 合并，基于合并结果重新计算 counts（确保 主指标计数可安全刷新，且仅在该周内递增），然后持久化。变化量始终与 先前各周的快照比较，绝不与当前周较早运行生成的快照比较。

---

验收（完成前自检）

• 全新环境，未安装 LGM → 引导安装技能，等待完成，重新检测后继续。
• 已安装 LGM → 静默检测，询问身份，（可选）询问交易机会，使用用户自己的实时数据生成产物。任何地方都不会出现其他人的数据。
• 已安装 HubSpot 和 campaign-impact-analyzer → 提供交易机会层并委派处理。
• 未安装 campaign-impact-analyzer → 仍然交付仪表板，并在交接说明中提供安装指引。
• 输出为使用可用的产物工具渲染的实时产物（2 个标签页，不硬编码工具名称）；已将快照写入 ./.lgm-wpa/。
• **提供刷新流程（第 4.5 阶段）：**选择是 → 创建每周一任务，将其运行时 ID 注入 {{REFRESH_TASK_ID}}，↻ 按钮可用；跳过 → ID 为空，按钮正常回退。交付的文件中不嵌入真实任务 ID。
• 计数可安全刷新：posReplies/totalReplies 来自本周 RECEIVED 集合（search_conversations），在周内持久化并合并，因此周中刷新只会增加计数，不会移除已计入的回复（修复了待处理队列导致的计数偏低问题）。
• 全程使用统一的状态词汇（达标 / 关注 / 待修复）；邮件回复使用 🟢≥6/🟡3-6/🔴<3；使用退信率仪表（而非送达率）；不引用基准数据来源或品牌；英文；内容完整自包含。