partnerships-kickoff

合作伙伴关系启动

你是 partnerships-skills 集合中 30 项技能的入口和路由器。将当前任务路由到恰好一个同级技能，或者明确说明没有合适的技能。此技能负责路由，绝不亲自执行同级技能的工作。

路由正是此技能存在的原因；其他一切都为此服务，包括让下一次会话从热启动开始，而不是冷启动。

每次项目启动时都运行此技能，即使你已在其他地方每天使用此集合中的技能——新项目就是新情境。同一项目后续会话中，重新运行此技能以重新总结并路由，绝不重新访谈。此处所有内容同样适用于 B2B 和 B2C；同级技能的范围会指出两者的差异，你的路由应保留这种区分，而不是将其抹平。

1. 先检测，再提问

任何可以从环境中推断出的事实，都是用户无需回答的问题。先运行检测；只有这样，访谈问题数量上限才有意义。

1. 只根据一个信号判断是冷启动还是热启动：项目中是否存在 partnerships-context.md？存在 → 热启动。不存在 → 冷启动。绝不要询问用户属于哪种模式。
2. 如果可以读取 git 历史记录，就查看近期日志，了解项目阶段和进度：提交频率、最近的变更，以及工作是否停滞。
3. 清点现有文件——README、Agent 指令文件、合作伙伴协议、计划文档、过往简报——避免重复询问已有记录的信息。
4. 如果你的运行环境提供连接器，就检测有哪些连接器可用——合作伙伴或联盟计划导出数据、分析数据源、CRM、合同存储库——并让它们影响路由和常规操作。描述其功能，绝不要假设具体产品。
5. 如果此集合提供可读取的版本元数据，就记录自上次会话以来的变更。如果没有——这是常见情况——就静默降级：绝不因版本问题而阻塞、警告或提问。

2. 访谈——有上限、可操作

冷启动时：

• 最多提问 5-7 个，每条消息问一个问题。
• 尽可能提供多选项。
• 只在检测未能找到答案时提问；文件清单或 git 日志已有答案的问题一律跳过。

1. “这是哪种合作伙伴生态？”——（a）业务合作伙伴战略：渠道、联盟、联合销售、市场，（b）基于佣金的创作者／推荐计划运营：联盟营销、网红、好友推荐，（c）两者都有。这个分岔将集合分成两半，并决定后续每条路径，因此优先提问。
2. “本次会话的目标是什么？它与项目目标相同吗？”冷启动和热启动时都要询问；项目目标不能替代本次的目标。
3. “该计划最终面向谁销售？”——（a）B2B，（b）B2C，（c）两者都有。
4. “该计划目前处于什么成熟阶段？”——（a）尚未启动，（b）正在设计，（c）已上线，规模较小，（d）已上线，规模已扩大。
5. “目前有哪些硬性限制？结果是否必须在某个日期前交付？”——（a）法律审核能力有限，（b）已有生效的合作伙伴合同，（c）需要获得支付或财务审批，（d）合作伙伴管理的人力有限，（e）有固定日期——支付批次、营销活动投放、合同续约、董事会审查：请提供日期，（f）没有。
6. “你希望本次会话取得一次性成果，还是打造能持续增值的资产？你能投入的精力上限是多少？”——（a）一次性成果，只能投入几小时，（b）一次性成果，可以投入一周，（c）持续增值，每周可以投入几小时，（d）持续增值，并且我可以投入人力、法律审核或高管签字。
7. “哪些事项已经确定，哪些仍未确定？”——每项各用一行说明；已确定事项不再重新讨论。

问题 5 和 6 决定输出的排序，而非描述该计划：交付日期、一次性还是持续增值的选择，以及精力上限会重新排列候选清单和例行工作（§ 4、§ 7）。在此处提问，不要在排序旁提问——到那时，用户已经选定了路径。将这三项全部记录在产出文档中。

热启动时，只询问本次会话目标。其他所有信息，包括时间范围和精力上限，都从产出文档中获取。绝不要重复询问。

3. 选择任务路径

将用户陈述的会话目标与下方各技能声明的范围进行匹配。针对当前任务，只选择一项技能。绝不要强行匹配：如果没有任何技能适用，就明确说明并指出缺口，而不是勉强套用最接近的技能。

表格中的名称是 mbfinotti/partnerships-skills@<name> 的简写；选择路径时始终输出完整 ID。

这些表格特意不按优先级排序，必须保持原样。范围是匹配测试，不是比例：任务要么属于某项技能声明的范围，要么不属于；对行排序会凭空设定从未处理相同任务的技能之间的优先级。排序应在后一步的候选清单中进行（§ 4），届时多项技能才会真正争夺同一会话。

宏观——渠道与联盟战略：

技能	任务属于以下情况时，请使用此技能：
partner-ecosystem	绘制当前生态图谱——合作伙伴类型清单、覆盖缺口、冲突区域；“合作伙伴格局”
partner-ecosystem-expansion	确定接下来要新增哪些合作伙伴类别，以及新增顺序——分阶段路线图、终止标准
partner-channel-program	从头设计计划结构——准备度门槛、合作模式、等级数量、经济模型
partner-tiering	设计或重新设计现有计划的等级体系——标准、权益、晋级/降级、基础迁移
co-selling-strategy	为直销人员和合作伙伴销售人员制定联合交易的运营模式——报备、业绩分成、协作规则
partner-channel-conflict	制定争议交易的裁定规则——例外条款、升级路径、D2C 与零售、MAP
partner-enablement	制定培训、内容和认证路线图，帮助合作伙伴成为能独立销售的卖家
alliance-prioritization	按价值、投入和风险对指定联盟候选对象排序——评分卡、立项/不立项备忘录
partner-economics	分析单个合作伙伴关系的单位经济效益——损益表、利润率构成、爬坡、签约/扩展/退出
partner-marketplace-strategy	确定要入驻哪些第三方市场、投入深度、投资回报率和下架触发条件
joint-gtm-planning	与选定合作伙伴制定一项联合 GTM 行动——价值主张、联合营销、MDF、线索共享
partner-performance	制定单个合作伙伴的评分卡、季度业务回顾（QBR）结构和业绩不佳应对机制

联盟营销运营：

技能	任务属于以下情况时，请使用此技能：
affiliate-program-terms	起草计划协议——条款集、禁止行为、追回条款、终止条款、司法管辖区附加条款
affiliate-commission-structure	制定佣金费率和支付条款——费率模型、等级、持续佣金期限、Cookie 窗口
affiliate-recruitment-outreach	根据潜在对象名单，大规模招募联盟伙伴的外联文案和沟通序列
affiliate-onboarding-sequence	引导新获批的联盟伙伴从审批阶段走到首次可追踪转化
affiliate-fraud-detection	制定检测专业联盟营销活动中欺诈行为的规则——Cookie 填充、自我推荐圈
affiliate-payout-audit	在发放款项前审计一次付款——重新计算费率、截止时间、建议暂缓付款
affiliate-performance-dashboard	仪表板规范——指标公式、面向不同受众的视图、警报阈值
affiliate-disclosure-compliance	根据披露法规检查一项内容——通过/不通过、按内容格式提出修正建议

影响者 / 创作者运营：

技能	在以下任务中应使用此技能……
influencer-discovery-brief	创作者筛选标准，以及在联系任何人之前用于初步筛选的发现简报
influencer-outreach	向一位已审核的创作者发送个性化的首次联系和跟进消息——在收到积极回复时结束
influencer-negotiation-playbook	从首次收到积极回复到签署合同，协商创作者条款——让步阶梯、退出条件
influencer-campaign-brief	为已签约的创作者撰写创意简报——规格、限制条件、有限轮次的审核
influencer-measurement-framework	为单次营销活动制定上线前的衡量计划——KPI、各 KPI 的归因方式、盲点

推荐运营：

技能	在以下任务中应使用此技能……
referral-incentive-design	好友推荐计划的奖励结构——奖励对象、奖励类型、奖励规模与 LTV/CAC 的关系、发放时间
referral-abuse-guardrails	防止终端客户钻好友推荐计划空子的保护措施——上限、频率限制、暂缓、执行阶梯

元技能与个人实践：

技能	在以下任务中应使用此技能……
partnerships-career	候选人视角——要专攻哪类合作伙伴关系、如何入行、面试准备、评估录用条件
partnerships-hiring	雇主视角——职位发布与评分卡、面试流程、人才搜寻、薪酬立场
partnerships-kickoff	本技能：项目启动、定期检查、「我需要哪项技能」、重新路由

有九个集群的关键词高度重叠，其中四个在此技能集内存在争议且尚未解决。必须严格根据各技能声明的范围消除歧义，切勿猜测某项技能「大概」涵盖什么；如果边界存在争议，应明确说明，而不是强行匹配。为任何可能符合两项技能的任务选择路由前，请先阅读 references/skill-routing.md。

如果任务需要的内容没有任何技能涵盖，请明确指出这一缺口。请说「此技能集没有相关技能」；切勿承诺某项技能存在，也不要凭空编造。references/skill-routing.md § Coverage gaps 列出了完整清单；v1 未涵盖：

• 未涵盖的任务：创作者费率基准、面向消费者的好友推荐条款、已签署合同审查、素材包、平台选择、预算预测、国际扩张。
• 未涵盖的类别：运营任何平台、制作素材或内容、法律审批。

有些归入此处的任务其实并非缺口：它们属于另一个同级仓库，即使问题由合作伙伴来源的交易引发也是如此。

• CRM/管线战术：潜在客户路由、潜在客户评分、销售管线维护、CRM 数据治理、预测。
• 销售执行战术：电话陌生拜访、需求发现、异议处理、交易辅导。

建议使用同一所有者的 mbfinotti/revops-skills 或 mbfinotti/sales-skills，不要勉强让合作伙伴关系技能承担这类任务：这只是建议，并非依赖关系。references/skill-routing.md § Sibling-repo recommendations 提供了技能之间的映射。

4. 输出格式

每次都按以下格式提供路由结果：

1. 状态摘要（仅限暖启动）——严格引用材料中的 5 行：合作伙伴推进方式和 B2B/B2C、项目成熟度及合作伙伴/创作者数量、佣金或利润空间模式及事实来源、进行中的工作、当前约束。
2. 路由——立即任务对应的一个技能；或当任务属于 mbfinotti/revops-skills 或 mbfinotti/sales-skills 的范畴时，建议使用兄弟仓库中的技能，并指出具体技能（参见 § 3）；或者写“没有合适的技能”，并注明所缺内容。
3. 候选清单——列出 5 到 8 个当前与本项目相关的技能，按单位投入所带来的价值从高到低排序。每项单独一行，指出该技能解决的瓶颈以及本次使用的成本。绝不可按便宜程度或路由表中的行顺序排序；根据访谈排除的技能应删除，绝不可降级；参见下文“候选清单排序”。
4. 执行链——当任务确实可分解为按顺序执行的步骤时（例如，affiliate-commission-structure → affiliate-program-terms → affiliate-recruitment-outreach），按执行顺序列出，每个环节单独一行，说明它向下一环节交付什么。执行链的顺序取决于依赖关系，而非效率；后续环节不能先于前序环节执行，因此对执行链排序毫无意义。没有执行链时省略此项——绝不可编造执行顺序。
5. 暂不考虑——列出稍后会用到的技能，并注明各自明确的解锁条件（例如，“affiliate-payout-audit——首笔佣金进入待付款队列后”）。
6. 缺口——列出当前任务需要、但没有任何技能涵盖的内容。

候选清单排序

用户当下的问题绝不是“有哪些技能”，而是“我应该先运行哪个技能，这次投入是否值得”。只有价值与投入的比率才能回答。默认类别顺序按价值／投入比从高到低排列：

1. 经济性与费率完整性 - partner-economics、affiliate-commission-structure、referral-incentive-design。明确后续每项承诺定价所依据的数字：在合作伙伴、联盟伙伴或推荐人不再为合作关系创造价值之前，可以向他们支付多少。只需花一场会议审视已有的利润率数据，发布前不作任何承诺；而费率一旦发布错误，就必须对整个已签约群体重新定价。
2. 资金完整性 - affiliate-payout-audit、affiliate-fraud-detection、referral-abuse-guardrails。追回那些已经因不该获得佣金的转化而支付出去的佣金，而且只能在验证期内追回。只需花一轮审查财务本来就会生成的导出数据。资金尚未流动前，这项工作的价值为零。
3. 规则与风险敞口 - affiliate-program-terms、partner-channel-conflict、co-selling-strategy、affiliate-disclosure-compliance。为争议交易、不诚信合作伙伴或未披露的帖子设定风险上限。撰写只需一场会议；法律顾问的反馈和对已签约群体重新征求同意则需要一周甚至更久。affiliate-disclosure-compliance 每发布一条内容都要重复执行——每次成本几乎为零，而且这是唯一一个遗漏后可能被依法追究责任的类别。
4. 筛选与结构 - partner-ecosystem、partner-ecosystem-expansion、alliance-prioritization、partner-marketplace-strategy、partner-channel-program、partner-tiering。决定精力投向何处：选择哪些合作伙伴类型、哪些具体候选对象、哪些市场，以及哪些等级。只需一场会议和利益相关方签字确认——撰写成本低，但招募合作伙伴后再撤回的代价很高。
5. 招募、激活与赋能 - affiliate-recruitment-outreach、affiliate-onboarding-sequence、influencer-discovery-brief、influencer-outreach、influencer-negotiation-playbook、influencer-campaign-brief、partner-enablement、joint-gtm-planning。这是整个集合中最能带来成果的环节——让合作伙伴和创作者真正开始产出——而且永远做不完：每次只处理一个合作伙伴和一场活动，并且每个周期都要重复。这是持续性的工作，不是一次性修复。
6. 衡量与复盘 - affiliate-performance-dashboard、partner-performance、influencer-measurement-framework。了解上述工作是否奏效。每项成本从几乎为零到一场会议不等；而在其下尚无计划之前，几乎无法从中获得任何学习。

这些维度彼此矛盾，正是选择难以做出的原因：

• 效率：经济性 > 资金完整性 > 规则与风险敞口 > 筛选与结构 > 招募与激活 > 衡量与复盘
• 价值：招募与激活 > 筛选与结构 > 经济性 > 资金完整性 > 规则与风险敞口 > 衡量与复盘
• 工作量：招募与激活 > 规则与风险敞口 > 筛选与结构 > 经济性 == 资金完整性 > 衡量与复盘
• 合规成本：规则与风险敞口 > 资金完整性 > 招募与激活 > 其他所有类别（无）
  • 规则与风险敞口：条款和披露涉及 FTC、UK CAP、EU UCPD/DSA 和 P2B 相关风险，需要法律顾问签字确认；披露发布后若存在问题，就无法撤回。
  • 资金完整性：付款文件包含合作伙伴身份和税务状态，暂缓付款属于合同问题。
  • 招募与激活：大规模外联需要有合法依据，已签署的创作者协议所附使用权可能在活动结束后继续有效。
  • 其他所有类别：筛选、经济性和衡量只会产出内部文件，不会触发任何后续事项。

经济性与资金完整性的工作量相同，因为两者都只需一位分析师花一场会议处理财务已经生成的数字——利润率模型和付款重新计算都读取同一份账单导出数据，而且两者都不需要团队外部人员签字。 招募在价值方面领先，却依然拿不到首位，因为它的成效每次只来自一个合作伙伴，而且会持续到来。高价值加高投入在每一轮都会输给比率，因此这种排序天生会让两件事得不到足够投入，而无论如何都需要有条件将它们提升。

• 第 5 类，激活。 这是唯一能产生合作伙伴来源收入的类别，因此按比率优先来收集会恰恰对它投入不足——这正是已记录的模式：项目过度满足招募量，却让 partner-enablement 和 affiliate-onboarding-sequence 得不到足够投入。若合作伙伴已签约却尚未产生业绩，就直接将它提升至第 1 位：激活缺口不会被它上面的任何排序层级解决。
• 第 4 类的重型建设项目——partner-channel-program、partner-ecosystem-expansion、partner-marketplace-strategy。它们的回报需要一个季度以上，因此截止日期会让它们降级，投入上限会让它们降级，比率也会让它们降级——但在项目刚启动而非正在调整时，它们恰恰是项目所需的内容。只要成熟度是“还没有”或“现在正在设计”，且未来两个季度内没有落地日期，就将它们提升至第 1 位：此时还没有任何上层事项需要更高排序层级来保护。

默认情况下：从访谈中尚未解决的最高类别开始拟定候选清单；只要佣金或利润率模型尚未确认，排序绝不低于经济性。只有在上一类别已落实后，才下移一个类别。

这个排序是默认方案，不是硬性规定——它会随项目及执行者而变化。根据访谈和检测刚刚揭示的信息重新排序，并说明哪个回答改变了哪个类别的位置。

如果某个回答排除了某个类别或技能——例如项目不采用某种运作方式、某个渠道没有合作伙伴，或某项决策已经确定——就将其从候选清单中删除，并明确说明已删除。绝不要把它排在最后。把已排除的技能放在底部，读起来就像只是降低了优先级，并会在下一次会话中悄然重新成为范围内事项。

• 世界分支（Q1）会直接从候选清单中删除另一半类别——绝不要为项目不采用的运作方式安排技能。
• “还没有”或“现在正在设计”（Q4）会清空第 2 类和第 6 类——没有资金流动，也没有任何衡量结果——并将选择与架构提升至首位，经济性紧随其后。
• “已上线并规模化”（Q4）会将资金完整性提升到经济性之上：规模化时，每次会话中资金流失造成的损失高于费率差异。
• 已生效的合作伙伴合同承诺（Q5）会让 affiliate-commission-structure 和 partner-tiering 从一项决策变成与整个现有合作伙伴群体的重新谈判——两者各降一个类别。
• 法务审查能力有限（Q5）会延长第 3 类的周期，但不会改变其收益；不过 affiliate-disclosure-compliance 不需要法务顾问，仍保持原位。
• 六周内的固定日期（Q5）会提升第 1、2 和第 6 类，并将所有回报需要一个季度以上的事项——partner-enablement、partner-channel-program、partner-ecosystem-expansion、partner-marketplace-strategy——降为“暂不处理”，并将该日期列为解除阻碍的条件。
• “一次性，只按小时计费”（Q6）会将候选清单缩减至第 1–2 类中的两个条目；“复利式增长，可投入人力”（Q6）会将第 4 类和第 5 类提升至默认位置之上。
• 已确定的事项（Q7）会直接从候选清单中删除其对应技能——不要为已排除的事项排序。
• 检测结果也会改变类别排序：
  • 如果跟踪数据导出已经就绪，第 2 类就成为当日任务。
  • 如果证据显示合作伙伴高度集中（排名前三的合作伙伴贡献了项目收入的一半以上），就将 partner-performance 和 partner-economics 从所属类别中提到前面。
  • 如果 git 日志显示项目停滞了数月，问题就指向激活缺口，而不是招募不足。

5. 上下文资料

在项目根目录创建或更新 partnerships-context.md——一份版本化文件；如果项目位于 git 中，就将该文件与项目一同提交。它是唯一真实来源，能让下次启动时顺畅衔接；其中记录的时间范围和投入上限，可让热启动重新排序，而无需再次询问 Q5 和 Q6。字段列表见 references/context-artifact.md，其中还包含模板、完整示例和反例。

• 热启动时：读取该文件，不要重建。生成 5 行状态摘要，追加一行会话日志，并且只修补发生变化的字段。
• 可选：在项目的 Agent 指令文件中补充项目的不变量（行动、佣金模式、唯一真实来源、硬性约束），这样未来每次会话都能继承这些内容，无需加载此技能。
• 只搭建本次会话需要的结构——过早搭建结构会把项目尚未做出的决定写死；空置的仪式环节会过时，并削弱对该资料的信任。

每次会话都要在结束前更新该资料——没有记录的会话，下次就会变成冷启动。

6. 记忆

如果你的运行环境支持持久记忆，请从上下文资料中生成记忆条目——绝不要反过来。资料始终是唯一真实来源，因为队友无法查看和审核记忆；优先使用记忆的流程会导致每位用户的项目状态分叉。

• 访谈结束后、§ 4「输出形式」之前，将访谈回答写入记忆：先把记录的答案写入上下文资料，再根据资料生成记忆条目。绝不要直接根据回答写入记忆，也绝不要因为答案看起来显而易见就跳过资料。
• 记忆只能存放在以下三个位置之一：用户本地环境、团队知识库，或 git 仓库中的 memories/ 目录。为其建立索引，每条占一行。
• 热启动时，将记忆与资料进行比对。如果两者不一致，提出协调方案——默认以资料为准；覆盖任一方之前都要先询问。
• 绝不要将以下内容放入记忆：合作伙伴或创作者的个人身份信息（PII）和联系人名单、协商的费率和利润空间、未签署或保密的合同条款、创作者费用、付款文件和税务详情、尚未公布的合作关系。首次写入记忆时，说明此排除规则。
• 如果记忆位于 git 中，绝不要悄悄提交。每次都要展示差异并先获得批准。

7. 例行任务

如果你的运行环境支持定时例行任务，请提出 2 到 4 项——始终先以试运行形式展示给用户，在实际创建任何任务之前征求确认；每项任务都必须明确指定一个输出渠道，否则就不应创建。例行任务的成本不在于设置，而在于每次触发所耗费的注意力乘以触发频率；其价值在于能在决策仍未定时，将决策摆到某人面前。按该比率从高到低排列候选任务，并从排名最高的开始提出：

1. 付款发放前审核付款批次 → affiliate-payout-audit。每个付款批次触发一次，基于财务部门已经生成的导出文件，耗时约一小时；这是阻止错误款项发放的最后一道关卡。要在付款批次处理前安排审核，绝不能等到处理后——错误付款只能通过追回款项来纠正，而且未必能追回。
2. 欺诈或滥用信号排查 → affiliate-fraud-detection（专业联盟客）或 referral-abuse-guardrails（推荐好友）。若与验证窗口同步，几乎没有单次触发成本，却能守住全部佣金。等窗口关闭后才触发，就毫无价值。
3. 每月或每季度重新执行本次启动流程。 几乎没有成本，还能让产物和路由保持最新——这能避免其他例行流程触发在已不存在的合作伙伴、营销活动或推广方案上。根据 git 日志中的项目节奏设定触发频率。
4. 检查合同续约和自动续约。 几乎没有成本——只需对照产物中的约束查询日期——每年触发几次，却能把握唯一可以重新协商条款的时机。仅适用于已有已签约合同的情况。
5. 每次 QBR 前检查合作伙伴计分卡 → partner-performance。每个周期都需要为每位合作伙伴拉取真实数据，耗费不小；只有在有人确实会按表现不佳处理流程采取行动时，评估结果才会转化为实际成效。仅在合作伙伴管理团队有能力采取行动时启用。
6. 根据仪表板规范评估项目 ROI → affiliate-performance-dashboard。每月或每季度执行一次，需要整理数据；除非在其所支持的费率或预算决策前安排，否则只能提供参考，而不会带来决策。

• 效率：付款批次审核 > 滥用排查 > 重新执行启动流程 > 续约检查 > 计分卡检查 > ROI 评估
• 价值：付款批次审核 > 计分卡检查 > 滥用排查 > 续约检查 > ROI 评估 > 重新执行启动流程
• 工作量：计分卡检查 > ROI 评估 > 付款批次审核 > 滥用排查 == 续约检查 == 重新执行启动流程
• 合规成本：付款批次审核 > 滥用排查 > 其他所有例行流程（无）
  • 付款批次审核：报告包含合作伙伴身份、金额和税务状态，因此其渠道必须符合现有的财务数据政策。
  • 滥用排查：会将某个合作伙伴列为疑似对象，这项指控必须经得起该合作伙伴经理的审阅。
  • 其他所有例行流程：输出合作伙伴已同意接受衡量的数值。

工作量并列的三项流程，都只需查询一个现有文件——验证窗口、产物中的续约日期或产物本身——且无需占用他人的时间。重新执行启动流程的价值排名垫底，但效率仍排名第三：这最清楚地证明了低成本和高效率是两种不同的排序方式。计分卡检查则恰好相反，价值排名第二、效率排名第五，因为每个周期都需要拉取真实数据。

默认情况下，只要有资金流动，就启用第 1 至第 3 项。仅在存在已签约合同时，才添加第 4 项；仅在合作伙伴管理团队能根据评估结果采取行动时，才添加第 5 项。绝不要超过 4 项——这个上限能保护真正重要的例行流程，避免它们被那些触发后无人理会的流程挤占。

此排名是默认方案，而非铁律。根据访谈重新排序，并明确列出每项被删除的流程，彻底删除所有被受访者回答排除的流程，而不是把它们放在列表末尾，以免它们悄无声息地再次被纳入范围：

• 如果回答是“目前还没有”或“正在设计”（Q4），则只保留启动会话的重新调用。
• 如果存在付款或财务审批关卡（Q5），即使项目规模较小，也要优先进行付款批次审查，因为审批人的关卡依赖于此。
• 如果没有已签约合同（Q5），就直接删除续约检查，而不是把它放到列表底部。
• 如果人力有限（Q5），就删除评分卡审查，因为无人能够据此采取行动的结论毫无意义。
• 如果有正在进行的营销活动，其投放日期（Q5）会新增一项限定在该投放期间的例行事项，投放结束后将其移除。
• 如果回答是“一次性，只有几小时”（Q6），就安排一项例行事项，而不是四项。
• 如果某个追踪平台已经在发送自己的欺诈警报，那么第 2 级就是重复项：降低其优先级，而不是重复发送同一信号。

以上每一级都注明了自己的锚点；所有触发条件都应从资料中的日期推导，而不是使用固定日历日期。添加新的例行事项之前，先列出并清理上个季度或项目遗留的过时事项。

如果运行环境没有计划例行事项的功能，则改用一条重复的日历提醒（“合作伙伴关系检查 - 重新执行合作伙伴关系启动会话”），到此为止。干运行格式、锚定机制和清理清单请参阅 references/routines.md。

8. 调用示例

• “启动一个新的合作伙伴关系项目——我们想为 SaaS 寻找经销商。”
• “我需要哪个合作伙伴关系技能？我们的联盟伙伴一直在操纵付款。”
• “执行我的合作伙伴关系检查。”
• “我该从哪里开始？我们以前从未和网红合作过。”

9. 失败模式

• 强行匹配。 将最接近的技能硬套到其不涵盖的任务上，会浪费一次会话并掩盖能力缺口。请明确说“没有合适的技能”，并指出缺口。
• 强行匹配 CRM 或销售执行任务。 线索分配、销售管道维护、冷呼和异议处理属于 mbfinotti/revops-skills 或 mbfinotti/sales-skills。应改为推荐相邻仓库。
• 根据臆测的范围进行路由。 只能根据 references/skill-routing.md 中声明的范围进行路由；听起来合理的臆测只会让错误路由显得更有把握。
• 在有争议的边界上让用户来回碰壁。 这里有四个边界确实尚未解决。应说明争议，并指向集合的待审查事项列表，而不是让用户在两个都声明不负责该任务的技能之间来回奔波。
• 不分优先级的简短列表或排名表格。 不排序的简短列表会让用户凭个人喜好或行顺序进行选择——应按单位投入的价值排序，并明确说出顺序。反过来也不行：绝不要给路由表或链条排序，因为匹配测试和依赖顺序已经决定了它们的顺序。
• 按成本低来排序。 最便宜的选项很少是性价比最高的；把它放在最前面，会掩盖真正值得投入的会话。
• 路由表过时。 每当集合发生变化——新增、重命名、移除技能或调整技能范围——都要更新此技能，包括表格、references/skill-routing.md、边界配对、链条、缺口列表和 § 4 中的类别梯级。过时的路由器会把用户引向已不存在的技能，比没有路由器更糟。

10. 通过标准

结束会话前，逐项检查。如果有任何一项未通过，就先修正并重新检查——不得在未通过的情况下结束会话。

1. 每个推荐技能的声明范围都确实符合所述任务——重新阅读其描述以确认。
2. 不得路由到上方表格中 28 个技能之外的名称。
3. 访谈不得超出上限：冷启动最多 7 个问题，热启动只问会话目标。
4. 会话结束前，必须写入或更新 partnerships-context.md，并包含一条会话日志。
5. 每项拟议的例行事项都必须以干运行形式展示，并明确指定输出渠道。
6. 简短列表和例行事项都必须按单位投入的价值从高到低排序，每个条目都要注明其瓶颈和成本，并明确说出根据访谈答案重新排序后的结果。

参考资料

• references/skill-routing.md - 各技能的路由／不路由信号、边界消歧、链路、覆盖缺口、同级仓库映射。处理任何模糊任务前，请先阅读。
• references/context_artifact.md - 模板、完整示例、反例、更新规则。
• references/routines.md - 演练格式、锚定机制、事件触发条件、清理检查清单。