executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
go-to-market为任何产品或功能制作上市(GTM)物料。当被要求做 GTM 计划、定位陈述、产品发布计划、核心信息支柱、使用场景或功能与利益清单时使用。产出完整的 GTM 物料包:定位陈述、信息支柱、功能到利益的对应,以及按角色划分的使用场景。需要跨部门协作的分级发布计划请使用 go-to-market-planner。
Independent GitHub snapshot · Automated classification · Original documentation governs
go-to-market 的简体中文翻译,英文版本为规范版本。
这个技能为一个产品、功能或计划制作完整的上市物料包。它遵循 Geoffrey Moore 的定位框架,所有产出都整理成可直接用于销售演示、落地页、发布邮件和内部对齐文档的结构。
你常常会拿到一份简短的说明,缺少一些细节。无论如何都要交付完整的 GTM 物料包:不要停下来提问,也不要留下 [ADD PROOF POINT] 或 [Technical capability] 这样的方括号占位符。缺少细节时(差异点、证明点、功能),根据产品描述和目标客户推断具体、现实的内容,并把任何推断的内容标注为 (假设,待确认)。具体且标注清楚的假设,永远好过空白。
如果存在 professional-brain(brain/),先用它再提问:
context.md(产品、理想客户画像、语气)、knowledge/market.md 和 knowledge/strategy.md,以及对应的要发布的 entities/ 功能。entities/,把定位或渠道决策记入 decisions/,都标注来源。总是按顺序产出下面四个部分。
严格使用 Geoffrey Moore 的格式:
对于 [目标客户],他们 [有这个问题或需要],[产品名称] 是一款 [产品品类],能够 [关键利益或结果]。不同于 [主要替代方案或竞品],我们的产品 [关键差异点]。
写一条主定位陈述,再给一个更短的口号版本(不超过 10 个英文词或约 15 个汉字),适合做首屏标题。
生成 3 到 5 个信息支柱。每个支柱必须包含:
支柱之间要有区别,避免重叠。每个支柱都要能在主要竞品面前站得住。
给出两列表格:
| 功能 / 能力 | 买家利益(对用户意味着什么) |
|---|---|
| [技术能力] | [用通俗语言写的结果,以动词开头:"减少……"、"让……成为可能"、"消除……"] |
规则:
生成 3 到 5 个按角色划分的使用场景。每个场景按以下格式:
场景 [N]:[角色],[场景标题]
如果可能,场景要覆盖不同的买家角色(例如最终用户、经理、管理员)。
这个技能附带支持文件,可用时请使用:
references/messaging-hierarchy.md:信息层级:先一个主张,再说其他。在产出时应用它;它包含上面方法摘要压缩掉的校准和判断。templates/gtm-pack.md:可填写的成果模板,质量关卡写在里面。当用户想自己完成文档而不是生成时提供。交付前给这个技能的任何产出打分;32 分以上才算可以交付。
| 维度 | 0 | 5 | 10 |
|---|---|---|---|
| 定位精准度 | 笼统的价值陈述,没有目标客户或替代方案 | 遵循了 Moore 格式,但"不同于"一句很弱 | Moore 格式,目标细分市场清晰,"不同于"点出了买家真正在比较的替代方案 |
| 信息与证明的一致性 | 支柱是没有支撑的主张 | 有证明点,但有些只是换个说法重复主张 | 每个支柱都有至少 2 个真正的证明点(或诚实标注的占位符),层级以一个主张开头 |
| 功能到利益的转化 | 只有功能清单,没有利益 | 有利益,但被动或仍是功能的样子 | 每个功能都配一个以动词开头、买家会转述给老板的利益 |
| 发布可用性 | 一篇定位文章,而不是物料包 | 物料包齐全,但各部分之间不一致 | 口号、支柱、场景和利益清单讲的是同一个故事,可以直接用于发布页 |
交付前确认: