growovo-gtm

Growovo GTM 操作协议（growovo-gtm）

本 skill 是 Growovo 执行内核的 agent 操作协议（05 产品方案 §5.3）： agent 当参谋（出方案）、内核当执行（守门禁）、人当闸门（审计划）。动作落到 CLI（python3 mkt.py …）或 MCP（mkt-server），本协议不发明新动作。

仓库位置：github.com/roy-tong/Growovo（克隆到本机的目录；MCP 配置里用其绝对路径）

入口是一个 GTM 目标，不是单个渠道动作

用户说"这是我的产品/GitHub 仓库，帮我找到最可能需要它的用户并完成增长闭环"时， 按四引擎拆解（Growovo = 定 → 造 → 跑 → 量）：

对增长结果负责的是四引擎整体；单渠道动作只是「跑」层的原语。

何时使用

• 用户给出"产品/仓库 + 增长目标"（试用、注册、激活、付费），要方案或直接执行
• 需要为目标产品寻找/扩展目标客群并入线索库
• 已有计划要执行（发帖/私信/邮件波次）或复盘（回复率/退信/转化）
• 要判断哪条渠道真正有效（预注册实验 + 归因台账，不是拍脑袋）

七步流程

① 立场与约束确认

先三行立场（同意/保留/反对）再动手。确认：业务目标一句话、可用渠道、节奏约束、 已有资产（内容/线索）。缺目标不动笔。

② 目标拆解

假设 → ICP（组织+persona）→ 单一 beachhead（不铺多线）。写清假设的可证伪点。

③ 客群证据

• 发现：mkt.py x/reddit/linkedin/hn search（只读）+ 既有研究资产（leads 库/触达数据库）
• 资格：证据分级 A=公开自证 / B=强信号 / C=推断；低于 B 不入队
• 公司账号必须富化到具体员工（部门+权责+persona）——走 [[b2b-account-mapping]] 协议
• 入库 data/contacts.jsonl（hooks/title/verification 字段是触达弹药，也是漏斗身份归一的基础）

④ 计划落盘（plan.json）

mkt plan new --id <plan_id> --goal '…' --beachhead '…' --hypothesis '…' \
  --channel email --wave-action message --size 10
mkt plan lint --id <plan_id>

• 渠道优先级用实测数据（求评邮件 5.3% > GitHub 站内 > X 冷触达 1.5-2.4%），不平均用力
• 每波：channel×action×size（≤内核日预算）×content_policy（千人千面）
• 成功判据预注册（metric+target+stop）
• review.human_approved 留 false——人审不是礼节，是执行前置条件

⑤ 人审门禁（审批是事件，不是布尔值）

mkt plan approve <plan_id> --by <审批人> [--days 7]

把 plan 呈给用户（波次/规模/内容方针/停止条件），获批后用署名审批：内核写 data/approvals.jsonl 事件 + 计划指纹 plan_sha256。批准后计划被改 → 指纹失配， 实跑拒跑；过期同样拒跑。 --go 实跑必须绑定已人审 plan：无 plan 管辖的 campaign 内核默认拒跑，仅 CLI 人工通道 --adhoc 显式放行（账本记 adhoc=true）；MCP 不开放 adhoc——agent 不得 自我授权。全局暂停（mkt pause）期间一切写操作拒跑。

⑥ 执行

cd <仓库>
./launch.command                       # 首次：启动 CDP 会话
mkt queue build --campaign <campaign> --channel email --wave-action message \
  --template assets/outreach.md --targets data/targets.csv   # 模板+CSV 生成队列
mkt queue lint data/queues/<campaign>.json                   # 编辑期门禁
mkt review <campaign>                                        # 逐条预检 + 留证
python3 mkt.py email message --queue data/queues/<campaign>.json          # dry-run
python3 mkt.py email message --queue data/queues/<campaign>.json --go     # 实跑（须已人审 plan）

• 内容由人审产出（写作走 [[warm-email-outreach]] / [[expert-review-outreach]]）； 队列正文千人千面，占位符残留会被门禁直接拒绝
• 写操作永远先 dry-run 看截图，再 --go
• UNVERIFIED 渠道（reddit/linkedin/hn）首跑必须用户在场
• 失败即停，不重试轰炸

⑦ 复盘（量引擎 + 记账自动化）

mkt collect serve --port 8787                     # 本地 collector：/t/<link> 点击归因 + /events webhook
mkt collect import --source plausible --csv plausible.csv
mkt collect import --source posthog --csv posthog.csv --event-map user_signed_up=signup
mkt outcome sync --campaign <campaign>            # 账本 → 触达计数快照（幂等）
mkt link create --campaign <campaign> --channel hn --url <落地页>
mkt outcome import data/events.csv --campaign <campaign>   # CSV 导入（幂等）
mkt experiment obs --id <exp> --from-outcomes      # 事件 → 观察值（不再手抄）
mkt campaign report <campaign>                     # 一页纸：计划/执行/结果/下一步

• 账本 committed 是「发出去了」，不是「转化了」；事件与触达分栏，不合成转化率
• activation/paid 必须带 source_ref 与核验状态，漏斗主体经 contacts 归一
• 渠道有效性判断走 mkt experiment（判据预注册，机器只聚合不判定）
• mkt ledger resolve <ref> 处置 indeterminate（署名 + 依据，原账本行不改）
• 对照预注册判据：达标→加深该渠道；不达标→回 ② 修假设
• 账本对不上平台实际状态 = 停该渠道查账。

红线（内核已硬编码，agent 也不得绕过）

• 只驱动本人拥有/运营的账号；不群发、不买量、不模板批发
• 实跑必须绑定已人审 plan；adhoc 仅 CLI 人工通道显式放行且账本留痕
• 上限是内核属性：计划写多大都会被日预算/单次上限拒绝
• 回读校验不一致绝不发送（449 空正文事故固化）
• 不做对抗：不绕验证码、不伪造指纹、不用代理池
• LinkedIn 全自动默认锁死（半自动=终端人工确认）；Reddit 日 ≤3 帖；HN 日 ≤1 帖（Show HN 限自有项目，提交后 1h 内发首条作者评论）
• 结果事件不得编造或近似：activation/paid 必须真实发生并带核验状态；实验观察只在 running 期接受

与其他 skill 的分工