在启动或继续 RevOps/Sales Ops 项目时…

任何 RevOps/Sales Ops 任务开始前或持续项目每次新会话开始时，用来冷/热启动项目上下文、路由到 revops-skills 集合中的单项技能，并规划后续技能与例程。

适用场景

解决思路

1. 1. 在每个 RevOps 项目开始时、持续项目每个会话开始时先运行此 kickoff；即使集合其他技能已日常使用也不要跳过，因为新项目就是新上下文。
2. 2. 仅凭项目根目录是否存在 `revops-context.md` 判断冷/热启动：存在→热启动；不存在→冷启动；绝不问用户是哪种。
3. 3. 当仓库历史可读时，读取最近 git log，从提交频率、最后变更内容、工作是否停滞推断项目阶段和节奏。
4. 4. 盘点已有文件：README、agent-instruction 文件、数据字典、阶段文档、`.github/`，避免重复询问已写内容。
5. 5. 如果 harness 暴露 connectors/integrations，检测哪些可用：CRM 导出、分析源、工单系统、会议纪要；用其存在影响路由和例程；只描述能力，不假设具体产品。
6. 6. 如果技能集合提供可读版本元数据，记录自上次会话的变化；如果没有，静默降级；绝不因版本阻塞、警告或询问。
7. 7. 冷启动时访谈最多 5-7 个问题，每条消息只问一个问题，尽量提供多选题，只在检测空白处花问题，跳过文件清单或 git log 已回答的问题。
8. 8. 问收入运动：B2B sales-led、B2B PLG/self-serve、B2C/transactional、mixed。
9. 9. 冷启动和热启动都问本次会话目标，以及是否与项目目标相同；项目目标不能替代今日目标。
10. 10. 问 CRM 日常负责人和 CRM 变更签字人；记录两者姓名/角色；两者很少重合。
11. 11. 问硬约束及结果必须落地日期：release/change freeze、quarter close 或 month-end close（给日期）、limited admin capacity、compliance/audit window、none。
12. 12. 问想要一次性修复还是常设系统，以及 effort ceiling：one-off hours only、one-off a week of work is fine、standing a few hours every week、standing 且可获 admin access 和 cross-team sign-off。
13. 13. 问哪些已决定、哪些仍开放，各一行；已决定项不再重新讨论。
14. 14. 将问题 4 和 5 的答案记录到 artifact：落地日期、one-off-versus-standing、effort ceiling；它们用于重排 short-list 和 routines，热启动无需再问。
15. 15. 热启动只问 session-goal 问题；其他信息包括日期、horizon、effort ceiling 从 artifact 读取。
16. 16. 按声明的 session goal 对技能声明范围做匹配；立即任务只路由到恰好一个技能；绝不强行匹配；无合适技能时明确说 no skill fits 并命名 gap，不要拉伸最近技能。
17. 17. 路由表故意不排序并保持不排序；范围是匹配测试，不是比例；排序只在 short-list 中进行。
18. 18. 当任务可能合理匹配两个技能时，先读 `references/skill-routing.md`，按每个技能声明范围消歧；绝不凭猜测消歧，错误消歧比不消歧更糟。
19. 19. 路由项：任务为设计 funnel 模型本身（哪些阶段存在、什么单位移动、计划转化假设、每个 handoff 谁拥有）→ `mbfinotti/revops-skills@revenue-funnel`；没有 agreed stage set 或模型错误而非措辞错误也走这里。
20. 20. 任务为设计、验证或修复 lead scoring 模型、MQL/PQL 阈值、sales rejects our MQLs → `mbfinotti/revops-skills@lead-scoring`。
21. 21. 任务为把 inbound leads 分配给 reps：规则优先级、round-robin、territory assignment rules、routing SLAs（score 已存在）→ `mbfinotti/revops-skills@lead-routing`。
22. 22. 任务为按 buyer-verifiable exit criteria 审计 stage definitions；阶段以 rep activity 命名 → `mbfinotti/revops-skills@pipeline-stage-definition-audit`。
23. 23. 任务为对 active pipeline snapshot 做周期性审计：stale deals、close-date pushes、缺失字段 → `mbfinotti/revops-skills@sales-pipeline-hygiene`。
24. 24. 任务为诊断现有 forecast 为何 miss：stage inflation、sandbagging、roll-up overrides → `mbfinotti/revops-skills@sales-forecast-diagnostic`。
25. 25. 任务为追踪记录在某个具体 funnel 中静默退出的位置并估算可恢复损失 → `mbfinotti/revops-skills@revenue-leakage`。
26. 26. 任务为组织级数据权威：每类对象哪个系统是 source of truth、跨团队数据合同、指标定义放在哪里、谁仲裁 we have two ARR numbers → `mbfinotti/revops-skills@revenue-data-governance-strategy`。
27. 27. 任务为字段所有权、每个字段的 system of record、freshness SLAs、字段生命周期和执行规则 → `mbfinotti/revops-skills@crm-data-governance`。
28. 28. 任务为非标准交易的折扣/让步审批矩阵和例外处理 → `mbfinotti/revops-skills@deal-desk-approval`。
29. 29. 任务为发现、验证并排序 leading churn indicators 成 signal register → `mbfinotti/revops-skills@customer-churn-signals`。
30. 30. 任务为把已有信号组合成一个 composite、weighted、banded account health score → `mbfinotti/revops-skills@customer-health-score`。
31. 31. 任务为设计 sales-to-CS post-close handoff 流程、packet 和 acceptance step → `mbfinotti/revops-skills@sales-to-cs-handoff`。
32. 32. 任务为设计组织级 metric tree：每层拥有哪些指标、如何向上 reconciliation、每个 owned number 搭配哪个 guardrail counter-metric → `mbfinotti/revops-skills@revenue-kpi-framework`。
33. 33. 任务为 board/exec revenue report、QBR section 或 investor update 的 metric spine 和 narrative → `mbfinotti/revops-skills@revenue-reporting`。
34. 34. 任务为对整个 GTM tool stack 做周期性组合审查：逐工具 keep、consolidate、replace、cut，并与 renewals 对齐 → `mbfinotti/revops-skills@revops-stack-rationalization`。
35. 35. 任务为 hiring-manager 侧：RevOps hire 的 scorecard、interview loop、work sample、30-60-90 → `mbfinotti/revops-skills@revops-hiring`。
36. 36. 任务为 candidate 侧：RevOps career ladder、interview prep、invisible ops work 的证据 → `mbfinotti/revops-skills@revops-career`。
37. 37. 任务为保持最新：RevOps sources、newsletters、communities、people to follow 的 watch list → `mbfinotti/revops-skills@revops-radar`。
38. 38. 任务为项目启动、周期性 check-in、which skill do I need、re-routing → `mbfinotti/revops-skills@revops-kickoff`。
39. 39. 对四组 altitude 冲突按 macro vs tactical 路由：模型/权威图/指标集缺失或错误→macro；模型存在且工作发生在其中→tactical sibling。
40. 40. 冲突组 1：`revenue-funnel` 设计 stage model，`pipeline-stage-definition-audit` 审计它。
41. 41. 冲突组 2：`revenue-data-governance-strategy` 指定每类对象哪个系统胜出，`crm-data-governance` 治理胜出系统内的字段。
42. 42. 冲突组 3：`revenue-kpi-framework` 设计 metric tree，`revenue-reporting` 叙述它。
43. 43. 冲突组 4：`revops-stack-rationalization` 裁定哪些工具存在。
44. 44. 当任务需要无技能覆盖时明确命名 gap；collection v1 无专门技能覆盖：record deduplication、attribution modeling、territory design、single-tool pre-purchase evaluation、BI dashboard building。
45. 45. 命名 gap 前检查任务是否属于兄弟 `mbfinotti` 集合：sales-execution-tactical 或 sales-leadership planning→建议安装 `mbfinotti/sales-skills`；macro channel/partner strategy→建议安装 `mbfinotti/partnerships-skills`；框架为推荐而非依赖；读 `references/skill-routing.md` § Sibling-repo recommendations 确认 hand-off 信号。
46. 46. 每次交付路由结果：热启动时先给 state summary，恰好 5 行来自 artifact：motion、system of record、in-flight work、top open decision、active constraint。
47. 47. 交付 Route：立即任务的一个技能，或 no skill fits 加 named gap。
48. 48. 交付 Short-list：5-8 个当前项目相关技能，按 value returned per unit of effort 从高到低排序；每条一行同时命名瓶颈和会话成本；绝不按便宜或路由表行序排序。
49. 49. 交付 Chain：当任务确实分解为有序序列时，按执行顺序列出，每个链接一行说明传给下一个什么；链序是依赖顺序不是效率顺序；没有链时省略，绝不虚构序列。
50. 50. 交付 Not now：以后才重要的技能，每条带明确 unblocking condition，例如 `customer-health-score` 在 `customer-churn-signals` 交付 validated register 之后。
51. 51. 交付 Gap：今天任务需要但无技能覆盖的内容，作为 gap 陈述；若 gap 实际属于 sales-execution-tactical 或 macro channel/partner-strategy，推荐匹配兄弟 repo 而非裸 gap。
52. 52. Short-list 默认类顺序按 value per unit effort 从高到低：1 Diagnosis：`revenue-leakage`、`sales-forecast-diagnostic`、`pipeline-stage-definition-audit`；它买到一个有名有据的答案说明下方哪个类才是问题，成本是一个会话基于已导出记录，无需 admin access、无需签字、不改变任何需回滚的东西。
53. 53. 2 Funnel plumbing：`lead-scoring`、`lead-routing`；买到 speed-to-lead 并阻止 qualified leads 在队列中未被处理；成本是设计会话加 CRM 配置变更（由 admin 持有者执行）、分阶段 rollout 和回滚路径；只适用于它上线后到达的 leads。
54. 54. 3 Standing rules：`crm-data-governance`、`deal-desk-approval`、`sales-to-cs-handoff`；买到后续每次 sweep 和例外所依据的规则：字段归谁、谁可批准让步、CS 团队必须收到什么；成本是起草会话加 RevOps 外跨团队签字；规则只能通过另一次谈判反转。
55. 55. 4 Stack rationalization：`revops-stack-rationalization`；买回重复支出和每个工具一个已决定 verdict，基于 finance 已保留的合同列表；成本是跨 finance、procurement、SSO 和 expense records 的 inventory pass 加每个 verdict 一个 tool owner；整个比率取决于 renewal calendar：verdict 落在 auto-renewal 日期之后对另一个合同年无价值。
56. 56. 5 Recurring sweeps：`sales-pipeline-hygiene`；买到本季度能 hold 的 pipeline 数字而非只在 close 时成立；成本是每次 sweep 一个会话加每个 disposition 由 rep 推进；永不结束，是 standing job 不是 fix。
57. 57. 6 Account health：`customer-churn-signals`、`customer-health-score`；买到在仍可行动时 account 有风险的排序、验证过的原因；成本是战术类中最长 lead time：足够 renewal history 做 backtest、任何人信任输出前的 validation window、然后 recalibration。
58. 58. 7 Reporting：`revenue-reporting`；买到 exec 或 board 可行动的 number 及其为真的 sign-off；成本是 finance 和 sales 间 definition-locking negotiation；当 feeding metrics 尚未被上方类修复时买得很少。
59. 59. 8 Macro design：`revenue-funnel`、`revenue-data-governance-strategy`、`revenue-kpi-framework`；买到上方每个类所运行其中的模型：计划建立的 stage set、每类对象胜出的系统、每个 org level 拥有的 metric tree；成本是集合中最高：与 finance、marketing、CS 的跨职能谈判、全公司随后读取的决策、回报在规划周期后到达；这里没有 RevOps 单独可逆的东西。
60. 60. `revops-hiring`、`revops-career`、`revops-radar` 位于 ladder 外而非底部；它们回答人员或 stay-current 问题而非 revenue-system 问题；当那正是 session goal 时，它们按定义是 rung 1，否则完全不进 short-list。
61. 61. 使用 axes 比较并说明冲突：efficiency 顺序为 `diagnosis > funnel plumbing > standing rules > stack rationalization > recurring sweeps > account health > reporting > macro design`。
62. 62. value 顺序为 `macro design > funnel plumbing > account health > standing rules > stack rationalization > recurring sweeps > reporting > diagnosis`。
63. 63. effort 顺序为 `macro design > account health > stack rationalization > standing rules > funnel plumbing > recurring sweeps == reporting > diagnosis`。
64. 64. compliance cost 顺序为 `macro design > stack rationalization > reporting > standing rules > account health > funnel plumbing > diagnosis == recurring sweeps (none)`；解释：source-of-truth 指定和签署 metric taxonomy 设定组织级 retention、residency、read-access 条款，由 finance 和 legal 共同拥有；cut a tool 触发合同终止通知和数据删除/导出义务，按 vendor 时钟失效；board/investor number 带 finance sign-off，一旦发出不能收回；field-ownership 和 discount-authority 规则编码谁可读客户数据、谁可批准让步，需 data-protection 和 delegation-of-authority review；churn model 对具名账户按行为历史画像，retention basis 需有人拥有；routing rules 在 owners 和 regions 间移动客户记录，在多区域 CRM 中跨越 data-residency 线。
65. 65. recurring sweeps 和 reporting 在 effort 上真平局：都是基于已有记录和定义的周期性会话，无需配置、无需 admin access、无需回滚；一个每次 sweep 跑，一个每个 reporting cycle 跑。Diagnosis 和 recurring sweeps 在 compliance cost 上同为 0，因为都读取已依现有合法基础持有的记录且不在团队外发布。
66. 66. Macro design 在 value 领先、在 efficiency 最后：两个轴差距最大，因为回报在规划周期后到达。Account health 形状低一档：在任何 renewal-heavy 业务中战术类 value 领先，但 efficiency 第六，因为输出在 validation window 过去前不能行动。
67. 67. 效率顺序会饿死 foundational work：macro design 每轮 ratio 都输；`crm-data-governance` 上一级同形，规模更小，战术类中协调成本最高且落地当周无可见输出。若只按 ratio，会永远重跑便宜诊断，下方每次 sweep 反复对无人同意的模型重审同一例外。
68. 68. 当项目是在设计而非调优时，将 macro design 直接提升到 rung 1，standing rules 也提升：finance 和 sales 报两个不同 ARR 数字，或无人能说每类对象哪个系统胜出 → `revenue-data-governance-strategy`。
69. 69. 无 agreed stage set、多个 motions 共用一个 stage list，或 stage audit 留下少于两个可用 anchors → `revenue-funnel`。
70. 70. 每个 org level 跟踪自己的未对账数字，或 planning cycle/board reset 开启 → `revenue-kpi-framework`。
71. 71. 无人能说出谁拥有字段或哪个系统胜出（Q3 为空）、同一例外 sweep 接 sweep 重现、或 compliance/audit window（Q4d）打开 → standing rules。
72. 72. 默认从 class 1 开 short-list 并停留，直到 diagnosis 命名其下方某类；一次只下移一个 class；绝不越过 diagnosis 标记缺失的 class。
73. 73. 从 short-list 删除被排除的 class；绝不降到最后，因为被排除技能停在底部会悄悄作为 scope 重现；有 stated unblocking condition 时移到 Not now 并带条件；没有时完全不提。
74. 74. 排序是默认非法律；根据 motion 和执行者重新排序，并说出哪个答案移动了哪个 class。
75. 75. B2B PLG/self-serve：将 `lead-scoring` 在 funnel plumbing 中提升为 product-qualified scoring；将 `deal-desk-approval` 重写为 promo 和 discount policy 而非面向 rep 的 approval matrix；让 `revenue-funnel` 的 unit-of-analysis 决策（lead、buying group、workspace）成为 macro design 第一件要解决的事。
76. 76. B2C/transactional：除非存在命名的 account-management motion 可交接，否则从 short-list 删除 `sales-to-cs-handoff` 和 `deal-desk-approval`。
77. 77. 无人能命名日常 CRM owner 或 sign-off（Q3）：将 standing rules 提升到 rung 1，无论 session 想要什么；当模糊跨系统而非字段时同时提升 `revenue-data-governance-strategy`；因为下方每个 class 都写入无 agreed owner 的系统。
78. 78. change freeze 或 limited admin capacity（Q4a/c）：从本次 short-list 删除 funnel plumbing；移到 not now，unblocked by admin capacity，diagnosis 吸收会话；macro design 不受影响，因为它不改配置。
79. 79. close date 两周内（Q4b）：提升 `sales-forecast-diagnostic` 和 recurring sweeps，它们都在该窗口内行动；将任何季度后才回本的事项（account health、governance rewrite、所有 macro design）降为 not now，以 close date 为 unblocking condition。
80. 80. renewal cluster 或 budget cycle 在本季度内：将 stack rationalization 提升到 rung 1；所有 renewal 超过两个季度时降到 recurring sweeps 以下，因为 verdict 在此之前无法执行。
81. 81. compliance/audit window（Q4d）：提升 standing rules、reporting 和 `revenue-data-governance-strategy`；延长 account health 但不改变它买什么。
82. 82. one-off hours only（Q5a）：将 short-list 砍到 diagnosis 的两条并直接删除 macro design；standing, admin and sign-off available（Q5d）：将 standing rules、account health 和 macro design 提升到默认位置以上。
83. 83. 已决定项（Q6）：将其技能从 short-list 直接删除；不要排序已 off the table 的内容。
84. 84. Detection 也移动 classes：git log 显示 build 前诊断停滞数月；磁盘上已有 data dictionary 或书面 stage definitions 时删除其 diagnosis 和 standing-rules 条目并降低 `revenue-funnel` urgency；无可读 CRM export 时删除 diagnosis 的数据依赖条目并保留 `pipeline-stage-definition-audit`（读定义而非记录）；磁盘上已有 contract inventory 或 expense export 时移除 stack rationalization 大部分成本。
85. 85. 创建或更新项目根目录 `revops-context.md`，一个 versioned 文件；项目在 git 中时随项目提交；它是让下一次 warm start 的单一 source of truth。
86. 86. Artifact 字段包括：Revenue motion；CRM 和 system-of-record facts；Stage set；In-flight work；Decided vs open；Constraints 包括结果必须落地日期；one-off-versus-standing horizon 和 effort ceiling；Stakeholders 及 decision role；session log。
87. 87. Artifact 最后三个字段使 warm start 无需重问问题 4 和 5 即可重排 short-list 和 routines；模板、worked example、negative example 见 `references/context-artifact.md`。
88. 88. Warm start 时读取 artifact，不重建；生成 5 行 state summary，追加 session-log 行，只 patch 发生变化的字段。
89. 89. 可选：将项目 invariants（motion、system of record、hard constraints）patch 到项目 agent-instruction 文件，使未来每个会话无需加载此技能即可继承。
90. 90. 不要 scaffold 项目尚未挣来的 working tree；只 scaffold 本次会话所需；过早结构会硬编码项目尚未做的决策。
91. 91. 仅当项目实际积累 contested decisions 时保留 decision log；否则 `decided vs open` 字段足够；空仪式日志会 stale 并侵蚀对 artifact 的信任。
92. 92. 每次会话结束前更新 artifact；未写的会话下一次就是 cold start。
93. 93. 如果 harness 有 persistent memory，从 context artifact 派生 memory entries，绝不反过来；artifact 保持 source of truth，因为 memory 对队友不可见不可审；memory-first 会按用户分叉项目状态。
94. 94. 访谈完成后、§4 Output shape 之前，将访谈回答持久化到 memory：先把捕获答案写入 context artifact，再从 artifact 派生 memory entry；绝不直接从答案写 memory，绝不因答案显然而跳过 artifact。
95. 95. Memory 只存在于以下三处之一，且三处都需要相同 index 文件列出每条 entry 和一行 hook；按每单位 setup effort 价值从高到低选择：1 项目 git repo 中的 `memories/` 目录；2 team knowledge base；3 用户本地环境。
96. 96. `memories/` 目录：setup 是一个目录和 index 文件，队友在已读项目处阅读，每次变更以可审阅 diff 到达；成本是 commit approval 步骤；历史中持久，移除错误需重写。
97. 97. team knowledge base：触达从不打开 repo 的人，并在任何单机外存活；成本是 RevOps 外 access-and-permissions setup；会与 artifact 漂移，因为没有东西把 page 绑定到 commit。
98. 98. 用户本地环境：近零 setup，无人可读；仅用于 solo 项目或必须不离开机器的 notes；第二人加入时 per-user store 会分叉项目状态。
99. 99. Memory 地点比较：efficiency 为 `git repository > team knowledge base > local environment`；reach 为 `team knowledge base > git repository > local environment`；setup effort 为 `team knowledge base > git repository > local environment`。
100. 100. 项目已在 git 中时默认 git repository；需要 memory 的人不在 repo 工作时选择 knowledge base。
101. 101. Warm start 时 diff memory 与 artifact；分歧时提议 reconciliation；默认 artifact 胜出；覆盖任一方前询问。
102. 102. 绝不放入 memory：具名个人 personal data、CRM 记录中的 customer names 或 PII、contract pricing 和 discount floors、compensation figures；第一次 memory write 时说明此排除。
103. 103. 当 memory 在 git repository 中，绝不静默提交；每次先展示 diff 并获批准。
104. 104. 如果 harness 支持 scheduled routines，提议 2-4 个，始终先作为 dry-run 展示给用户再创建任何东西，每个都有明确 output channel；没有 output channel 的 routine 是用户一周内静音的噪音。
105. 105. Routine 成本不是 setup，而是每次触发注意力 × 触发频率；价值是在决策仍开放时把决策推到某人面前；按该 ratio 从高到低排序候选并自上而下提议。
106. 106. Routine 候选排序 1：Pre-close forecast diagnostic → `mbfinotti/revops-skills@sales-forecast-diagnostic`；一年触发几次，基于团队本来要为 call 组装的 commit list，是唯一能在数字向上承诺前修正的 routine；锚定 close 前一周，绝不 close 后。
107. 107. 2：每月或每季度重新调用此 kickoff；每次触发近零成本，保持 artifact 和 routing table 最新，阻止其他 routine 对不再存在的工作触发；按 git log 的项目节奏匹配 cadence。
108. 108. 3：Renewal-window stack review → `mbfinotti/revops-skills@revops-stack-rationalization`；一年几次针对下一 renewal cluster，基于 finance 本已保留的合同列表，是唯一输出必须在 vendor 设定日期前而非团队选日期前落地的 routine；锚定每个 cluster 前整整一个 notice period，绝不在 renewal 当下。
109. 109. 4：Weekly pipeline hygiene pass → `mbfinotti/revops-skills@sales-pipeline-hygiene`；买到每周而非只 close 时成立 numbers，承担集合中最高 standing cost：sweep 是一次会话，每个 disposition 需 rep 行动；仅当有人负责追 exception list 时安装。
110. 110. 5：Monthly CRM field-governance review → `mbfinotti/revops-skills@crm-data-governance`；成本是每月 pass over field requests 和 freshness violations，field owners 在场；无 schema churn 的月份买不到什么，有人添加九个无人拥有的字段的月份买回一个 quarter。
111. 111. 6：Quarterly source refresh → `mbfinotti/revops-skills@revops-radar`；一年四次近零触发，买 currency 而非 outcome。
112. 112. Routine axes：efficiency 为 `forecast diagnostic > kickoff re-invocation > renewal stack review > hygiene pass > governance review > source refresh`。
113. 113. Routine axes：value 为 `hygiene pass > forecast diagnostic > renewal stack review > governance review > kickoff re-invocation > source refresh`。
114. 114. Routine axes：effort 为 `hygiene pass > renewal stack review > governance review > forecast diagnostic > kickoff re-invocation == source refresh`。
115. 115. Routine axes：compliance cost 为 `renewal stack review > governance review > hygiene pass == forecast diagnostic > kickoff re-invocation == source refresh (none)`；解释：cut tool 触发合同终止通知和数据删除/导出义务，均由 RevOps 外签字且合同失效后不可逆；governance decision 改变谁可读写客户字段，需 data-protection owner 签字且只能由另一决策反转；hygiene 和 forecast 输出都是 deal-level exception list，命名客户和金额，需团队数据政策已覆盖的 output channel，且都不触发审批。
116. 116. kickoff re-invocation 和 source refresh 在两轴上打平，因为都是一次近零读取，按月或季度触发，不需要阅读者之外的任何人，且各自输出内部状态或公共来源，不命名客户。
117. 117. source refresh 是最便宜候选且最后安装，清楚证明 cheap 和 efficient 是不同排序；hygiene pass 在 value 领先但 efficiency 第三，因为成本是每周会话加 rep 追每个 disposition。
118. 118. 默认 rungs 1-2，即两个 routines；contract inventory 存在后加 renewal stack review；有人负责 exception follow-through 后加 hygiene pass；schema churn 真实后加 governance review；绝不超过 4 个——上限保护重要 routines 免于 firing into void。
119. 119. Routine 排序是默认非法律；根据访谈重排：close date 两周内→只安装 forecast diagnostic，直到季度关闭；renewal cluster 或 budget cycle 本季度内→renewal stack review 提升 rung 1，所有 renewal 两季度外→降到 hygiene pass 以下；limited admin capacity→governance review 降为季度；未命名 CRM owner 或 sign-off→governance review 提升到 hygiene pass 以上，因为 sweep 无规则可 sweep；compliance/audit window→governance review 提升 rung 1；one-off hours only→只安装一个 routine，即 kickoff re-invocation，不是四个；团队已有 weekly pipeline review→hygiene pass 重复，降级而不是 sweep 同一批 deals 两次。
120. 120. 尽量将触发锚定到 revenue calendar（quarter close、month end、board meeting date）而非任意日期；添加新 routines 前列出并清理上一季度遗留的过时 routines。
121. 121. 如果 harness 没有 scheduled routines，回退为一个循环日历提醒（`RevOps check-in - re-run the revops kickoff`）并停止；dry-run 格式、触发锚定、事件触发偏好、清理清单见 `references/routines.md`。
122. 122. 失败模式避免：强行匹配——把最近技能拉伸到不覆盖的任务会浪费会话并隐藏 gap；应说 none fits 并命名 gap，或指向 `mbfinotti/sales-skills`/`mbfinotti/partnerships-skills`。
123. 123. 失败模式避免：warm start 重复访谈——artifact 存在就是为了不重复问题；只问 session goal。
124. 124. 失败模式避免：从猜测范围路由——只按 `references/skill-routing.md` 中声明范围路由；听起来合理的猜测会自信地错误路由。
125. 125. 失败模式避免：路由 altitude 而非 subject——四个 macro 技能各与一个 tactical sibling 共享 subject keywords；把 our stages are meaningless 送给 `revenue-funnel`，或把 we have two ARR numbers 送给 `crm-data-governance`，会给出错误 altitude 的会话，答案正确但无用。
126. 126. 失败模式避免：无上限访谈——超过 7 个问题 kickoff 变成用户放弃的表单；用检测而非问题填补空白。
127. 127. 失败模式避免：routines 无 output channel——它们 fire into void 后被静音，埋没唯一重要的 routine。
128. 128. 失败模式避免：扁平 short-list——六个等看选项会靠品味或排第一被选；按 value per unit effort 排序并在每行命名两侧，否则用户无法选择。
129. 129. 失败模式避免：以最便宜选项领先——cheap 和 efficient 是不同排序，只有后者回答 what first；一个近零但买近零的 routine 是 rounding error，不是 quick win。
130. 130. 失败模式避免：排序 routing table 或 chain——scope 是匹配测试，chain 是依赖顺序；对二者施加 ratio 会发明不存在的偏好。
131. 131. 失败模式避免：降级被排除技能而非删除——被访谈 off the table 的技能停在 short-list 底部，两个会话后作为 scope 重现；删除，或移到 not now 并带 unblocking condition。
132. 132. 失败模式避免：静默提交 memory——队友无法审阅没看到落地的内容；永远 diff 和 approval。
133. 133. 失败模式避免：stale routing table——集合变化时更新此技能：表格、`references/skill-routing.md`、boundary pairs、chains、gap list；技能新增、重命名、移除或重划范围时尤其；stale router 会把用户送到不存在的技能，比没有 router 更糟。
134. 134. Pass bar 结束前检查每项，若任一失败则修复并重查，不得在失败 bar 上关闭会话：1 每个推荐技能的声明范围确实匹配 stated task——重读 description 确认。
135. 135. Pass bar 2：零路由到上表 20 个技能之外的名字。
136. 136. Pass bar 3：访谈在 cap 内：cold start 最多 7 个问题，warm start 只问 session-goal 问题。
137. 137. Pass bar 4：`revops-context.md` 在会话结束前已写入或更新，包括 session-log 行。
138. 138. Pass bar 5：每个提议 routine 都作为 dry-run 展示且有明确 output channel。
139. 139. Pass bar 6：short-list 和 routine set 都按 value per unit effort 排序，每条命名攻击的瓶颈和成本；当访谈答案把某物移出默认位置时，重新排序要大声说明。
140. 140. Pass bar 7：访谈排除的每个 class 完全离开 short-list，而不是停在底部。
141. 141. Pass bar 8：routing table 和任何提议 chain 保持未排序——分别是匹配测试和依赖顺序。

适用边界 · 注意事项

• 不用于带配额的销售执行战术（cold calling、discovery calls、objection handling、negotiation concessions、deal-specific call coaching）或销售领导规划（quota setting、compensation plan design、sales org structure、ICP definition、market sizing、coverage modeling）；这些应推荐 `mbfinotti/sales-skills`。
• 不用于宏观渠道/伙伴策略（partner programs、co-selling、alliances、affiliate/influencer/referral operations）；这些应推荐 `mbfinotti/partnerships-skills`。
• 不用于 collection v1 未覆盖的任务：record deduplication、attribution modeling、territory design、single-tool pre-purchase evaluation、BI dashboard building；应明确说 collection 无对应技能，不要强行匹配。