在启动合作伙伴项目或需要选择合作技能时…

当用户开启合作伙伴项目、询问该用哪个合作技能、隔一段时间后恢复合作工作、做周期性合作伙伴/联盟/网红检查，或描述合作、创作者、佣金问题但未指明技能时，用这个路由技能匹配到唯一合适的下游技能并维护共享上下文文件。

适用场景

解决思路

1. 先检测再提问：只用一个信号判断冷启动还是热启动——项目里是否存在 `partnerships-context.md`；存在即热启动，不存在即冷启动，绝不问用户是哪种模式。
2. 如果能读取 git 历史，就读取近期日志判断阶段和节奏：提交频率、最后改了什么、工作是否停滞。
3. 盘点已有文件——README、agent 指令文件、合作伙伴协议、项目文档、过往简报——避免重复询问已经写好的内容。
4. 如果运行环境暴露了连接器，检测哪些可用——合作伙伴或联盟项目导出、分析数据源、CRM、合同存储——让它们影响路由和例行任务；只描述能力，不假设具体产品。
5. 如果技能集合带有可读的版本元数据，记录自上次会话以来的变化；如果没有（常见情况），静默降级，绝不阻塞、警告或询问版本。
6. 冷启动时最多问 5-7 个问题，每条消息一个问题。
7. 尽可能提供多选题选项。
8. 只在检测没有结果的地方花问题；文件盘点或 git 日志已回答的问题直接跳过。
9. 第一个问题：『这是哪个合作伙伴领域？』——(a) 商业合作伙伴战略：渠道、联盟、联合销售、市场平台，(b) 基于佣金的创作者/推荐项目运营：联盟、网红、推荐好友，(c) 两者都有。这个分叉把技能集合分成两半并决定后续所有路由，所以必须最先问。
10. 第二个问题：『本次会话的目标是什么——和项目目标一样吗？』冷启动和热启动都要问；项目目标永远不能替代今天的目标。
11. 第三个问题：『项目最终卖给谁？』——(a) B2B，(b) B2C，(c) 两者都有。
12. 第四个问题：『项目成熟度如何？』——(a) 还没有，(b) 正在设计，(c) 已上线但规模小，(d) 已上线且规模化。
13. 第五个问题：『当前有什么硬约束——结果必须在某个日期前落地吗？』——(a) 法务审查能力有限，(b) 已有承诺的合作伙伴合同生效，(c) 需要付款或财务审批，(d) 合作伙伴管理有人数限制，(e) 有固定日期——付款周期、活动档期、合同续约、董事会评审：给出日期，(f) 没有。
14. 第六个问题：『你想从这次会话获得一次性成果，还是可复利资产——你的投入上限是多少？』——(a) 一次性，只花几小时，(b) 一次性，一周工作可以，(c) 可复利，之后每周几小时，(d) 可复利，且能投入人力、法务审查或高管签字。
15. 第七个问题：『哪些已经决定了，哪些还开放？』——各一行；已决定的事项不再重新讨论。
16. 把第五和第六个问题的答案记录到上下文文件中：落地日期、一次性还是可复利、投入上限会重新排序候选清单和例行任务。
17. 热启动时只问会话目标问题；其他一切，包括时间范围和投入上限，都从上下文文件读取，绝不重新询问。
18. 把陈述的会话目标与每个技能的声明范围匹配，只路由到一个技能；绝不强行匹配：没有合适的就说没有，并指出缺口，而不是拉伸最近的技能。
19. 路由时始终输出完整 ID `mbfinotti/partnerships-skills@<name>`，而不是简写。
20. 路由表故意不排序，必须保持不排序：范围是匹配测试，不是比例；排序属于下一步的候选清单。
21. 在路由任何可能匹配两个技能的任务前，先读 `references/skill-routing.md`。
22. 当任务需要没有技能覆盖的内容时，明确说出缺口：『技能集合没有覆盖这个的技能』；绝不承诺存在某个技能或编造一个。
23. 对于 CRM/管道战术类任务（线索路由、线索评分、管道卫生、CRM 数据治理、预测），推荐 `mbfinotti/revops-skills`，而不是拉伸合作伙伴技能。
24. 对于销售执行战术类任务（冷呼叫、需求挖掘、异议处理、交易辅导），推荐 `mbfinotti/sales-skills`，而不是拉伸合作伙伴技能。
25. 每次都以固定形状交付路由结果：1) 状态摘要（仅热启动）——从上下文文件取恰好 5 行：合作伙伴动议和 B2B/B2C、项目成熟度和合作伙伴/创作者数量、佣金或利润模型和事实来源、进行中的工作、活跃约束。
26. 2) 路由——即时任务对应的一个技能；或当任务属于 `mbfinotti/revops-skills` 或 `mbfinotti/sales-skills` 领域时，推荐具体技能；或『没有技能适合』加指出的缺口。
27. 3) 候选清单——当前项目相关的 5 到 8 个技能，按单位投入回报的价值从高到低排序；每条一行，同时说明它攻击的瓶颈和会话成本；绝不按便宜程度或路由表行序排序；被面试排除的项直接删除，绝不降级。
28. 4) 链条——当任务确实可分解为有序序列时（例如 `affiliate-commission-structure` → `affiliate-program-terms` → `affiliate-recruitment-outreach`），按执行顺序列出，每条一行说明它交给下一个什么；链条顺序是依赖顺序，不是效率顺序；没有链条就省略，绝不编造。
29. 5) 暂不——以后会重要的技能，每个都带明确的解锁条件（例如『`affiliate-payout-audit`——当第一笔佣金运行排队待支付时』）。
30. 6) 缺口——今天任务需要但没有技能覆盖的内容，作为缺口陈述。
31. 候选清单默认按价值/投入比从高到低排序，类别顺序：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`；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`。
32. 默认从面试未解决的最高类别开始候选清单，当佣金或利润模型未确认时绝不低于经济类；只有上一类别就位后才向下移动。
33. 当合作伙伴已签约但不产出时，把第 5 类激活提升到第 1 级：激活缺口不会被上面任何一级触及。
34. 当成熟度为『还没有』或『正在设计』且两个季度内没有落地日期时，把第 4 类的重建设（`partner-channel-program`、`partner-ecosystem-expansion`、`partner-marketplace-strategy`）提升到第 1 级。
35. 根据面试和检测重新排序，并说明哪个答案移动了哪个类别。
36. 当答案排除某个类别或技能时——项目不运行的动议、没有合作伙伴的渠道、已关闭的决定——从候选清单删除并说明删除；绝不排到最后。
37. 世界分叉（Q1）直接删除另一半的类别；『还没有』或『正在设计』（Q4）清空第 2 和第 6 类，并把选择与结构提升到顶部；『已上线且规模化』（Q4）把资金完整性提升到经济之上；已有承诺合同（Q5）把 `affiliate-commission-structure` 和 `partner-tiering` 降一级；法务审查能力有限（Q5）拉长第 3 类但不改变其价值，`affiliate-disclosure-compliance` 除外；六周内有固定日期（Q5）提升第 1、2、6 类，把超过一个季度才见效的降到『暂不』；『一次性，只花几小时』（Q6）把候选清单缩到第 1-2 类的两条；『可复利，有人力』（Q6）把第 4 和第 5 类提升到默认位置之上；已决定项（Q7）直接移除对应技能。
38. 检测也移动类别：已有追踪导出让第 2 类变成当天任务；集中度（前三合作伙伴超过项目收入一半）把 `partner-performance` 和 `partner-economics` 拉出类别；git 日志显示数月停滞在激活缺口而非更多招募。
39. 在项目根目录创建或更新 `partnerships-context.md`——一个版本化文件，项目在 git 中时随项目提交；它是让下次启动变热的唯一事实来源。
40. 热启动时：读取它，不要重建；生成 5 行状态摘要，追加一行会话日志，只修补变化的字段。
41. 可选地把项目不变量（动议、佣金模型、事实来源、硬约束）补丁到项目的 agent 指令文件，让未来会话无需加载本技能就能继承。
42. 只搭建本次会话需要的结构——过早的结构会硬编码项目尚未做出的决定，空的仪式部分会过时并侵蚀对文件的信任。
43. 每次会话结束前更新上下文文件——未写入的会话就是下次冷启动。
44. 如果运行环境有持久记忆，从上下文文件派生记忆条目，绝不反过来；上下文文件是事实来源，因为记忆对队友不可见且不可审查。
45. 面试完成后、输出形状之前，把面试回答持久化到记忆：先把捕获的答案写入上下文文件，再从文件派生记忆条目；绝不直接从答案写记忆，也绝不因为答案显而易见就跳过文件。
46. 记忆只存三处之一：用户本地环境、团队知识库、或 git 仓库中的 `memories/` 目录；索引它，每条一行。
47. 热启动时把记忆与上下文文件对比；分歧时提议调和——默认上下文文件优先；覆盖任一方前先询问。
48. 绝不放入记忆：合作伙伴或创作者 PII 和联系人列表、协商费率和利润、未签署或保密合同条款、创作者费用、付款文件和税务详情、未宣布的合作关系；首次写记忆时说明此排除。
49. 记忆在 git 中时，绝不静默提交；每次先展示 diff 并获批准。
50. 如果运行环境支持定时例行任务，提议 2 到 4 个——始终先以 dry-run 展示给用户，每个都有明确的输出渠道；按价值/投入比从高到低排序：1) 付款前付款运行审查 → `affiliate-payout-audit`，每次付款运行触发一次，锚定在运行前；2) 欺诈或滥用信号扫描 → `affiliate-fraud-detection`（专业联盟）或 `referral-abuse-guardrails`（推荐好友），对齐验证窗口；3) 每月或每季度重新调用本 kickoff，节奏匹配 git 日志中的项目节奏；4) 合同续约和自动续约检查，只在有承诺合同时存在；5) 每次 QBR 前的合作伙伴记分卡 → `partner-performance`，只在合作伙伴管理有能力行动时安装；6) 按仪表盘规格做项目 ROI 读取 → `affiliate-performance-dashboard`，每月或每季度。
51. 默认：资金流动处用第 1-3 级；只在有承诺合同时加第 4 级，只在合作伙伴管理能对裁决行动时加第 5 级；绝不超过 4 个。
52. 根据面试重新排序例行任务，并直接删除被答案排除的，说明每个删除；『还没有』或『正在设计』（Q4）只留 kickoff 重新调用；付款或财务审批门（Q5）把付款运行审查提升到第一；没有承诺合同（Q5）直接删除续约检查；人数限制（Q5）删除记分卡；活动档期（Q5）加一个档期范围的例行任务，活动结束移除；『一次性，只花几小时』（Q6）意味着一个例行任务，不是四个；追踪平台已发欺诈警报时降级第 2 级。
53. 每个例行任务的触发器从上下文文件中的日期派生，而不是固定日历日期；添加新例行任务前先列出并清理上一季度或项目遗留的过时例行任务。
54. 如果运行环境没有定时例行任务，退回到一个循环日历提醒（『合作伙伴检查——重新运行 partnerships kickoff』）并停止。
55. 结束会话前检查通过标准：1) 每个推荐技能的声明范围确实匹配陈述的任务——重读其描述确认；2) 零路由到上表中 28 个技能之外的名字；3) 面试在限制内：冷启动最多 7 个问题，热启动只问会话目标问题；4) 会话结束前 `partnerships-context.md` 已写入或更新，包括一行会话日志；5) 每个提议的例行任务都以 dry-run 展示并有明确输出渠道；6) 候选清单和例行任务按单位投入回报的价值从高到低排序，每条说明瓶颈和成本，并大声说出根据面试答案的重新排序。

适用边界 · 注意事项

• 任务属于 CRM/管道战术（线索路由、线索评分、管道卫生、CRM 数据治理、预测）时，应推荐 `mbfinotti/revops-skills`，不要拉伸合作伙伴技能。
• 任务属于销售执行战术（冷呼叫、需求挖掘、异议处理、交易辅导）时，应推荐 `mbfinotti/sales-skills`，不要拉伸合作伙伴技能。
• 任务需要技能集合未覆盖的内容（创作者费率基准、消费者推荐好友条款、已签合同审查、资产套件、平台选择、预算预测、国际扩张、运营任何平台、制作资产或内容、法律签字）时，直接说没有技能适合并指出缺口，不要强行匹配。