| name | scope-change-controller-scott-margetts |
| description | 法律事项的范围管理 — 基线捕获、进行中的变更控制、OOS 文档化和范围回顾。当被要求审查范围界定假设、评估工作是否在范围内或范围外、起草范围变更通知、跟踪范围变更、准备 OOS 理由、运行 OOS 报告、准备范围电话议程，或审查事项上发生了什么变化时使用。触发方式：'scope change'、'out of scope'、'OOS'、'scope creep'、'is this in scope'、'the client wants us to also'、'additional work'、'scope review'、'what changed from the original scope'、'we need to revisit the quote'、'the budget assumed'、'OOS report'、'scope call with the client'、'run a scope report'。 |
| metadata | {"author":"Scott Margetts","license":"Apache-2.0","version":"2026.03.17"} |
范围变更控制器（Scope Change Controller）
目的
管理法律事项整个生命周期中的范围。范围是其他一切引用的基线 — 状态是对照范围的进展、风险是对范围交付的威胁、预算是范围的价格。当范围未被管理时，每一项其他纪律都在对照一个不可靠的目标工作，客户会被意外。
根本问题：法律团队持续无法管理范围，因为它感觉像是对抗性的、被视为合伙人的工作，且没有人在事项设置时建立管理变更的简单机制。结果是预算超支、本可以成为受管理变更对话的核销对话，以及得出"外部律师从不遵守预算"结论的客户。
良好的范围管理是对客户的服务，而非对抗。客户更愿意在事项中途就额外成本进行受管理的对话，而非在结束时收到意外发票。将范围变更框定为专业且不带情绪 — 双方交付各自承诺之事的契机 — 与机制本身同样重要。
核心设计理念：自动化捕获，浮现供确认
LPM 和律师知道记录范围变更有价值。他们不会持续这样做，因为在需要做的时刻，捕获开销超过了感知价值。"又一项工作"和"报告"是常见的搪塞 — 错过了重大的解锁：同时代数据使学习成为可能，而学习使迭代改进成为可能。但前提是我们让捕获尽可能接近零努力。
贯穿本技能的原则：不要要求人类创建记录 — 创建记录并要求人类确认它。 在手动模式下，这意味着技能根据提供的输入产出 OOS 条目草稿、沟通草稿和范围登记册更新草稿。在连接模式下，这意味着 Claude 检测范围信号、带自动链接的来源证据起草条目，并将其浮现供确认。"记录这个"（15 分钟，不会发生）与"我发现这个了 — 确认还是驳回？"（30 秒，会发生）之间的区别。
两个层级 — 随事项缩放
范围管理必须成比例。一个无人维护的过度工程化流程，比一个有人遵循的简单流程更糟。
标准（每个事项）
三份交付物，每份都足够轻量，让周四晚上 7 点疲惫的 LPM 真的会去做：
-
一页式范围摘要 — 聘用函中的 3-5 项关键假设，平实陈述，每项附可量化参数。在事项设置时产出。耗时 15 分钟。与交付团队共享并附一条指令："如果这些有任何变化，告诉我。"
-
简单 OOS 清单 — 当出现范围外事项时记录它：它是什么、何时被识别、是否已向客户提出、结果如何。每项一行。可以是邮件中的表格、电子表格中的几行，或事项档案上的便条。
-
客户沟通草稿 — 当 OOS 事项需要向客户提出时，技能为合伙人起草邮件。这是技能增值最大的地方 — LPM 不必从零起草尴尬的对话。
Sibelius 案 160 万欧元的 OOS 追回就是用基本工具和纪律实现的。发现它、标记它、跟踪它、开票它。
扩展（大型或复杂事项）
当事项的经济规模证明投入合理时使用：£100 万以上费用、12 个月以上时间线、多个辖区、范围敏感度高的固定或封顶费用基础。潜在的 OOS 追回需要超过维护系统的开销。
扩展增加：
-
完整范围登记册 — 10-15 项，带结构化字段。在 Excel 工作簿中维护。
-
每两周范围脉搏检查 — 一封简短、具体的消息，指名提及 3-4 项风险最高的假设。
-
范围回顾 — 在事项结案时，分析原始范围与实际范围之间的差量。
-
OOS 电话议程 — 合伙人带着走进客户范围电话的结构化文档。
触发扩展的不是雄心 — 是事项经济规模。 如果上限是 £120 万且潜在 OOS 追回是 £10 万以上，工作簿就物有所值。如果 3 个月事项的上限是 £5 万，标准模式就是您需要的全部。
分步流程
步骤 1：确定需要什么
本技能在实践中如何被调用：
当范围管理被定位为独立活动时，它就会失败。实际上，当它嵌入 LPM 已经在做的工作流中时才有效：
- 事项设置时： 作为事项设置流程一部分的基线捕获。唯一一次计划好的、审慎的调用。
- 批量邮件审阅期间： "这是本周 Redwood 的邮件 — 标记任何范围问题。"LPM 已经为状态报告批量处理邮件。在同一次处理中加入范围审阅是低摩擦的。
- 起草状态报告之前： "在我起草状态报告之前，对这些邮件运行范围检查。"使范围审阅成为一项已经在发生的活动的前置步骤。
- 计费之前： "我们即将对 Atlas 计费。有没有需要先提出的 OOS 事项？"计费周期是自然的触发点。
- 当另一个技能标记时： status-report-drafter 或 risk-and-issues-manager 浮现范围信号。LPM 跟随交接。
- 当合伙人询问时： "帮我为这次超支提供理由。"回顾模式 — 总是被动的，但仍然有价值。
在连接模式下，调用模型反转：Claude 对照范围登记册监控事项邮件，并为 LPM 浮现信号供确认或驳回。不是 LPM 调用技能 — 是技能调用 LPM。
常见触发：
- "这是聘用函 — 范围界定假设是什么？" → 范围摘要（标准）或完整登记册（扩展）
- "这在范围内吗？" / "客户还要我们处理 X" → 范围评估
- "我们预算爆了 — 追溯回范围" → 回顾性评估
- "为客户电话运行 OOS 报告" → OOS 电话议程（扩展）
- "事项即将结案 — 什么变了？" → 范围回顾（扩展）
如果用户未指明事项规模，询问："这是一个简单范围摘要就够的事项，还是大到需要完整范围登记册？"
步骤 2：建立基线
每次范围评估都需要基线。询问：
- "您有聘用函、范围界定邮件或费用提案吗？"
- "报价中的关键范围界定假设是什么？"
如果不存在基线文档，标记："没有文档化的范围基线，很难评估什么在范围内、什么在范围外。建议建立一个 — 即使是一封确认关键假设的简短邮件。"
步骤 3：提取范围基线
阅读聘用文件。提取：
- 可量化参数： 实体数量、文件数量、辖区清单、证人数量、员工人数、租约数量。最可能破裂，最容易跟踪。
- 范围纳入项： 聘用明确覆盖的内容。
- 范围排除项： 聘用明确不覆盖的内容。这些定义了 OOS 从何处开始。
- 隐含边界： 未提及、可作任一解读的事项。歧义是范围风险。
- 费用基础： 固定、封顶、计时、混合、分阶段。影响范围变更在商业上如何处理。
- 条件和附带条件： "基于迄今提供的信息" / "以无重大变化为前提" — 伪装的范围界定假设。
标准：提取 3-5 项。扩展：提取 10-15 项。 每项都应是团队在其变化时真正需要重新考虑价格的事项。不是穷尽的避险清单 — 是一组聚焦的重大假设。
在捕获时浮现历史范围知识
为新的事项创建范围假设时，技能应提示历史背景："您以前做过类似事项吗？这类工作上哪些范围假设通常不成立？"
这是将模式 4（回顾）连接回模式 1（基线捕获）的学习循环。没有它，回顾的教训困在文档里，相同的假设在下个事项上以相同的方式被违反。
在手动模式下： 问这个问题。LPM 从经验中知道实体数量总会增长、数据室总是迟到、员工人数总是漏掉承包商。让问题成为例行程序，会浮现原本留在 LPM 脑海中的默会知识。
带模式库（扩展）： 维护一份简单的参考文档 — "按事项类型的常见范围假设违反" — 从过去的回顾和 LPM 的经验构建。当技能在基线捕获期间识别事项类型时，它检查模式库并浮现相关警告：
"这是一个收购事项。在类似事项上，以下假设历史上曾被违反：实体数量（平均比范围界定多 +25%）、数据室就绪度（平均晚 2 周）、员工人数（初始数字经常排除承包商）。考虑为这些参数建立缓冲或单价机制。"
模式库不需要复杂 — 每个事项类型 3-5 条常见违反的 markdown 文件就足够。每次范围回顾完成时它都会增长。
在连接模式下： Claude 搜索 SharePoint 获取类似事项类型的范围回顾、提取违反模式，并在基线捕获期间自动浮现它们。是历史数据做提示，而非 LPM 的记忆。
这是递归改进循环：事项产生回顾、回顾产生模式、模式为下个事项的假设提供信息、更好的假设产生更少的违反。每个循环使范围界定更准确。
保护与可信度之间的平衡很重要。 太多排除项发出低信心或推销意图的信号。测试：LPM 是否愿意在开始时向客户解释每一项范围假设？如果不愿意，那就太激进了。
注意"买工作"模式。 定价激进地低、范围界定激进地紧，然后在每次偏离时强制执行 OOS。本技能不是为助长这一点而设计的。合法的范围管理保护双方。如果范围登记册读起来像陷阱，它就是被错误使用了。
步骤 4：评估范围变更（进行中）
当出现新工作或请求时，对照基线评估：
- 明确在范围内？ 无需行动。
- 明确被排除？ 明确的 OOS。记录并提出。
- 商定范围的合理延伸？ 灰色地带。要浮现给合伙人的问题：一个合理的客户会期望这包含在价格中吗？LPM 呈现证据 — 聘用说了什么、请求涉及什么、它与商定工作的关联有多密切。合伙人基于对客户的了解回答该问题。LPM 不作出最终定性。
- 未预见到的新工作？ 明确的 OOS。
- 范围相同，数量更多？ 范围假设违反。商业回应可能不同 — 单价调整，而非新的范围通知。
重大性测试： 如果客户问起，这会改变费用估算吗？多打一个电话是变化。多出 15 个实体是重大。LPM 基于费用基础和事项经济规模作出这一判断。
两种模式：
主动（目标）：在工作期间或之前识别分歧。客户以受管理的变更听到它。
回顾（现实）：预算爆了，需要追溯根本原因。哪些假设被违反、产生了什么额外工作、能否量化？产出是证据轨迹 — 足以用于客户费用对话或内部核销讨论的事实性记录。
步骤 5：产出输出
先摘要 — 存在哪些范围变更、估算影响、需要哪些决定。在输出中把此部分标记为"Summary"，而非"BLUF"。BLUF 是内部设计原则；读者看到的是"Summary"。
建议语气 — "建议向客户提出"而非"您必须通知"。浮现信号，不定夺回应。这延伸到给合伙人的谈话要点和辅导说明 — 使用协作性表述（"我建议我们以事实领起"而非"以事实领起"；"我们应小心别让这个主导电话"而非"别让这个主导电话"）。LPM 是在向同侪建议，而非指示下属。
标准：一页式范围摘要
| # | 假设 | 参数 | 违反时的费用影响 |
|---|
| 1 | 目标集团结构 | ≤5 个实体 | 每个额外实体 +£X |
| 2 | 交割时间线 | 4 个月 | 超出后每月 +£50-80k |
| 3 | ... | ... | ... |
另加："如果这些假设有任何变化，立即告诉我。"
标准：简单 OOS 清单
| OOS # | 什么变了 | 标记日期 | 来源 | 已向客户提出？ | 结果 |
|---|
| 1 | 3 个额外实体 | 3 月 10 日 | R. Tan 致 S. Margetts 邮件，3 月 10 日，"Atlas DD — entity structure issue" | 是 — 3 月 12 日 | 已批准，+£40-70k |
| 2 | 上海代表处 | 3 月 5 日 | M. Li 致 S. Margetts 邮件，3 月 5 日，"Shanghai — scope question" | 待定 | 等待合伙人决定 |
每项一行。来源列至关重要 — 在识别范围变更的那一刻捕获邮件引用（发件人、日期、主题行），而非事后追溯。当时记二十秒；六个月后构建 OOS 追回案时则需要数小时重建。这是范围管理中价值最高的单一习惯。没有来源引用，OOS 清单是断言；有了它们，它就是证据。
标准：客户沟通草稿
不是： "这是范围外的，我们需要向您收取更多费用。"
而是： "在工作过程中，我们识别了 [X]，这在原始范围中未预见到。我们乐意处理它 — 它涉及 [brief description]。估算的额外成本是 [range]。我们希望透明地标记这一点，而不是不经讨论就把它放进下一张发票。您希望我们如何继续？"
关键原则：
- 以发现的内容领起，而非费用
- 引用原始范围界定假设（"我们的报价假定 100 个实体"）
- 在可能时提供选项
- 框定为透明度，而非计费练习
- 不要道歉 — 范围变更是复杂法律工作的事实
- 在可能时先取得同意再开展工作
扩展：完整范围登记册
| 字段 | 内容 |
|---|
| ID | SC-[顺序号] |
| 假设 | 清晰陈述，尽可能量化 |
| 来源 | 聘用函条款、费用提案段落、邮件引用 |
| 参数 | 可量化的衡量标准 |
| 信心 | 低 / 中 / 高 |
| 状态 | 未测试 / 维持中 / 承压 / 已违反 |
| 偏差 | 如承压或已违反：实际 vs 假设 |
| 财务敏感度 | 该假设如何影响费用 |
| 责任人 | 谁监控该假设 |
扩展：OOS 登记册条目
| 字段 | 内容 |
|---|
| OOS-ID | OOS-[顺序号] |
| 描述 | 什么变了 |
| 类型 | 范围扩大 / 范围缩小 / 假设违反 / 歧义 |
| 相关 SC-ID | 受影响的哪个范围登记册条目 |
| 识别日期 | 何时发现变更 |
| 识别者 | 谁标记的 |
| 估算影响 | 小时数、成本、时间线 — 不确定时给区间 |
| 费用基础影响 | 这与费用安排如何互动 |
| 已向客户提出？ | 通知日期，或"尚未"并附建议方式 |
| 批准状态 | 已识别 / 已评估 / 已通知 / 客户回应（批准/拒绝/部分批准/讨论中）/ 费用已商定 / 已吸收 |
一旦费用商定，OOS 事项进入正常计费。不要重复计费系统的跟踪。
扩展：OOS 电话议程
当用户说"为客户电话运行 OOS 报告"时，产出一份结构化文档：
- 摘要：OOS 事项数量、估算的额外费用总额、需要客户决定的数量
- 未决 OOS 事项摘要表
- 逐项讨论要点（每项 3-5 分钟）：什么变了、为什么、影响、建议、所需决定
- 电话期间记录笔记/结果的空白
- 下一步
扩展：范围回顾
在事项结案时，分析差量：
- 原始假设 vs 实际，逐项偏差
- 财务影响：识别的 OOS 总额 vs 批准的 vs 吸收的 vs 争议的
- 时机：对每个被违反的假设，违规检测时间 vs 发生时间？差距就是迟检测的成本。
- 教训：为未来范围界定提供的具体、可操作建议
扩展：Excel 工作簿结构
四个工作表：
工作表 1：README。 工作簿是什么、每个工作表如何工作、状态字段意味着什么、谁维护它。
工作表 2：范围登记册。 所有 SC 条目的当前状态。按状态筛选需要关注的事项。
工作表 3：变更历史。 只追加的状态变更日志。列：SC-ID、日期、先前状态、新状态、原因、更新者。绝不覆盖 — 这是回顾数据。
工作表 4：OOS 登记册。 每个 OOS 条目及其生命周期。按批准状态筛选以查看已提出的内容及其所处位置。
范围管理 — 操作性知识
范围管理为何失败
- 范围文档消失。 归档进 DMS，再不被引用。
- 助理律师不发现或不报告蔓延。 他们专注于法律工作。解决办法：在启动时向他们简述 3-5 项假设，一条指令 — "如果任何有变化，告诉我。"
- "不能说不行。" Sibelius 的教训。被视为对抗性。实际上，客户尊重这种纪律。
- 蔓延是渐进的。 二十个琐碎的小请求。"顺便一提……"只有 LPM 看到模式。
- 回顾从不发生。 相同的假设在下个事项上失败。
- 来源证据没有当时捕获。 范围变更被发现，甚至可能在口头上被标记，但没人记下邮件引用。六个月后合伙人需要为超支提供理由时，LPM（或更糟，合伙人）花数小时在 Outlook 中搜索同时代证据。这是死时间 — 发生在 LPM 身上时很昂贵，发生在合伙人身上时不可接受。在记录 OOS 事项时捕获邮件引用（发件人、日期、主题行）。这是 OOS 清单与 OOS 证据文件之间的区别。
范围蔓延 vs 范围变更
蔓延： 渐进的、非故意的。"顺便一提"模式。检测模式、量化累积影响、提出它。
变更： 明确的、可识别的。"您能也处理上海吗。"评估、记录、商定。
费用基础如何影响范围纪律
固定费用： 敏感度最高。每件额外工作都被吸收，除非商定为 OOS。
封顶： 变更计入上限。额外工作减少剩余预算。
计时： 商业敏感度较低，但意外账单破坏关系。
范围脉搏检查（扩展 — 每两周）
简短、具体、指名提及 3-4 项假设。示例：
"Atlas 快速范围检查：(1) 实体数量 — 还是 5 个，还是数据室里有更多？(2) 裁员 — 还是没有计划？(3) 数据室 — 完整且可用？如果一切维持，一句话确认即可。"
发送快，回答快。无回应是信号。没有可检查的内容就不要发送。不要把它变成检查清单。
未来增强：Outlook Actionable Messages 可以在每项假设旁嵌入回应按钮。并非普遍可用 — 仅作为可能性提及。
输入处理
聘用函、费用提案、范围界定邮件、事项往来函件。来自 risk-and-issues-manager 和 status-report-drafter 的范围信号。
寻找：可量化参数、纳入项/排除项、条件/附带条件、"顺便一提"模式、对未范围界定工作的引用、暗示未管理范围的成本投诉。
文件输入：聘用函（主要基线）、范围登记册（如存在）、预算跟踪器（超支可能暗示范围问题）、RAID 日志（假设违反可能暗示未记录的范围变更）。
跨技能交接点
- 来自 risk-and-issues-manager： 从决定提取得到的范围信号。假设违反。
- 来自 status-report-drafter： 暗示范围问题的预算偏差。
- 至 budget-and-fee-manager： 范围变更已评估 — 需要财务影响分析。
- 至 timeline-generator： 范围变更影响时间线。
- 至 continuous-improvement-engine： 回顾发现为未来范围界定提供输入。
- 至 risk-and-issues-manager： 新的范围界定假设应作为 A 条目记录。
LPM 与律师的边界
本技能评估工作是否属于商定范围 — 运营和商业判断，而非法律判断。
浮现信号，不定夺回应。 如果尽调揭示未披露的责任，LPM 将其标记为可能重大。LPM 不说"这是保证问题"或"这需要写进 SPA" — 那些是法律定性。LPM 说："已识别未披露的责任。建议法律团队评估其影响。"
本技能不解释聘用函条款、不就可执行性提供意见、不确定发现应如何在交易文件中处理，也不评估客户请求在法律上是否必要。
专业语气原则 — 面向客户输出： 所有面向客户的草稿和沟通通篇使用专业、尊重的语言。避免任何将律所与客户对立、暗示客户恶意行事，或将专业交流定性为对抗性的表述。客户提出疑问或要求变更几乎总是出于善意。相应回应。
具名律所归因规则： 绝不在技能输出的任何位置引用具名律所 — 无论是在文档、表格还是对话文本中。这包括将费率、政策、实践或组织结构归因于任何具名律师事务所。本技能不知道任何律所的实际结构、费率或政策。使用"confirm with Pricing"、"confirm with Finance"或"firm policy — confirm before applying。"该规则适用于本技能产出的一切内容，而不仅仅是正式文档。
M365 连接模式 — 自动捕获的解锁
连接模式调用规则： 在这样做能增加价值时搜索连接系统（Outlook、SharePoint、Teams）— 而不是在提示词中已有充分输入时将其作为默认第一步。
- 输入已充分提供： 用户粘贴了带完整上下文的电子邮件、文档或数据。基于已有内容工作。不要先搜索 — 它只增加摩擦而不增加信息。
- 输入不完整或应主动浮现： 用户提到了应被检索的内容（"Outlook 里有一份发票"、"现在是月底"），或连接模式正在后台/定时模式运行。主动搜索 — 这是反向调用模型，是价值最高的连接模式行为。
区别在于用户是否已提供所需内容。如果是，就基于它工作。如果不是，或主动浮现服务 LPM，就搜索。
在手动模式下，LPM 做所有事：监控邮件、发现范围信号、记录它们、捕获来源引用、起草沟通。开销就是范围管理在大多数事项上被放弃的原因。
连接模式从根本上改变模型：Claude 检测并起草，LPM 审阅并决定。 LPM 的时间从行政捕获转移到商业判断 — 这正是他们价值真正所在之处。
Claude 可以用 M365 自动化的内容：
- 扫描事项邮件中的范围相关语言。 诸如"can you also"、"while you're at it"、"the client wants us to"、"we've found additional"之类的模式，或任何与范围登记册基线不同的数量引用（SC-005 说 5 个时出现"8 entities"）。这连续运行，而不仅仅在 LPM 记得检查时。
- 自动捕获来源引用。 当 Claude 识别到范围信号时，它已经拥有消息 ID、发件人、日期和主题行。OOS 清单中的来源列自动填充。LPM 零努力。
- 将传入信息与范围登记册比较。 如果范围登记册存在于 SharePoint，Claude 将每封事项邮件与登记的假设交叉对照并标记不一致。
- 起草预填充的 OOS 条目。 所有字段都从邮件填充 — 什么变了、何时、谁说的、来源链接、从范围登记册的财务敏感度数据估算的影响。LPM 审阅并确认，而非从零创建。
- 起草合伙人通知和客户沟通。 可供审阅和发送。
- 维护 OOS 清单。 添加条目、链接来源、在回应到来时更新状态。
仍需要 LPM 判断的内容：
- 这真的是 OOS，还是商定范围的合理延伸？
- 它足够重大值得提出吗？
- 现在是商业上的适当时机吗？
- 方式是什么 — 追回、吸收、谈判？
实际影响： 范围管理被放弃的原因不是无知 — 是开销。每个 LPM 都想过"那可能算 OOS，但我以后处理"。以后永远不会来。有了自动捕获，"以后"变成"现在 — 这是一份带来源链接的 OOS 条目草稿。确认还是驳回？"门槛从 15 分钟降到 30 秒。
无连接器时，粘贴文档、上传文件或口头描述范围。手动模式可以工作 — 只是更慢，且取决于 LPM 持续捕获的纪律。
