matter-intake-scoping-scott-margetts覆盖完整执行前弧线的事项范围界定——将客户数据整理为结构化简报、捕获约定基线，或中途重建范围。当在报价方案之前理解客户信息、界定新事项、进行启动、定义范围、映射利益相关方、或中途接手事项时使用。触发词：‘make sense of this’（梳理这个）、‘structure this for the proposal’（为报价方案整理这个）、‘scope this matter’（界定此事项范围）、‘new matter’（新事项）、‘kickoff’（启动）、‘what are we doing’（我们在做什么）、‘who are the stakeholders’（利益相关方是谁）、‘what does success look like’（成功长什么样）、‘matter setup’（事项设置）、‘i…
Independent GitHub snapshot · Automated classification · Original documentation governs
在完整执行前弧线中支持 LPM：从非结构化客户数据到合伙人可以据此撰写报价方案的结构化简报，再到其他所有 LPM 学科都引用的约定基线。
LPM 的角色是结构性的，而非决定性的。在委托前阶段，工作在于移除痛苦的数据拼装阶段——接收客户抛给法律团队的任意内容并加以组织，使合伙人和资深律师能够开始做法律和商业决策，而非在邮件里翻找。律所提议做什么、以什么价格，属于合伙人。LPM 让这项工作变快。
本技能以四种模式运作：
本技能的所有输出默认以 .docx 文件生成，除非用户明确要求其他格式。这些是事项记录——它们属于事项文件夹，而非聊天窗口。内联文本不可作为任何模式主要输出的可接受替代。若用户未要求特定格式，默认 .docx 且不询问。
本技能引用两类支持文件：
技能参考（本文件旁的 references/ 中）：
standing-assumptions.md——按事项类型划分的假设表现登记册，由律所维护matter-type-profiles/[type].md——每种事项类型相关的知识领域；路由到 shared-knowledge 文件共享知识文件（插件根目录的 shared-knowledge/ 中，由部署律所填充）：
路由机制是本技能的职责。知识文件的内容属于部署它的律所——由其自身实务专长填充，而非来自本技能。
客户发出委托。它以六封邮件、两份组织结构图、一份先前交易文件、一个资料室链接和一次发现通话的笔记到达。合伙人需要发出报价方案。在他们写出提议范围的任何一行之前，必须有人将该材料组织成连贯的东西。
那个任务——数据汇编、冲突检测、缺口识别——痛苦、耗时，且不需要法律判断。它浪费合伙人和资深律师的时间。LPM 干净利落地做一次，使法律团队从简报而非一堆材料开始。
主要输出： 委托前客户简报（docx）。为合伙人组织好的、带来源、带冲突标记的原材料。不包含提议范围、方法、团队或费用——那些需要属于合伙人的判断。
次要输出： 待解决问题清单。需要合伙人输入（LPM 没有的关系和商业背景）或客户输入（缺失信息）的优先级排序事项。
在处理输入之前，识别事项类型并从 references/matter-type-profiles/[type].md 加载对应画像。
事项类型画像识别通常相关的知识领域、标准标记引用哪些 shared-knowledge 文件、常见哪些假设、以及该事项类型上通常出现哪些差距和冲突。
若该事项类型不存在画像，无画像继续并注明差距——我会建议律所根据本次委托的产出创建画像。
接收提供的所有内容。为每个输入分配来源引用（[S1]、[S2] 等）。常见来源及提取内容：
对每个输入：它确认了什么、它暗示了什么、它与另一来源矛盾了什么？
为每个提取的数据点标注四种置信度等级之一。一致应用——一切看起来同样坚实的简报会给合伙人虚假图景。
已确认（Confirmed）——在客户往来函件或文件中明确陈述。引用来源。合伙人可直接依赖。
推断（来自输入）——输入暗示此点但未确认。标记给合伙人或客户在报价方案承诺立场前确认。
推断（来自一般知识）——不在任何客户输入中；通过将标准法律、运营或市场知识应用于事项类型和法域来识别。始终引用依据。始终清晰标记为外部推断。格式：[推断自一般知识：（陈述依据）。建议在报价方案处理此问题前经专家确认。]
未知（Unknown）——与范围相关但任何可用输入均未涉及。直接进入待解决问题清单。
推断（来自输入）与推断（来自一般知识）之间的区别很重要。合伙人需要知道标记来自客户说过的话，还是来自 LPM 关于此类工作如何运作的认知。两者都有用；它们具有不同的认识论地位，并对合伙人下一步需要做什么有不同的影响。
当输入相互矛盾时，显式浮出并引用两个来源。不解决冲突——解决需要合伙人和客户输入。
为每个冲突评级：关键（不解决则无法发出报价方案）/ 高（重大范围或关系影响）/ 中（相关但不阻止报价方案）/ 低（值得注意）。
查阅事项类型画像（第 1 步），识别哪些 shared-knowledge 文件与该事项类型和法域组合相关。对每个相关知识领域，检查客户输入是否涉及它。若未涉及，使用推断（来自一般知识）标签将其作为外部知识标记浮出。
简报中外部知识标记的格式：
[标记——[知识领域]] [问题描述和依据]。这在客户输入中未被涉及。我建议合伙人考虑是否将其纳入报价方案，或在范围定稿前与专家顾问确认。
当相关领域不存在 shared-knowledge 文件时，注明差距并建议律所创建。
在起草假设候选清单之前，查阅该事项类型的 references/standing-assumptions.md。
常设假设文件包含律所关于哪些假设在哪些事项类型上成立、哪些被打破、后果如何的积累记录。目标是经校准的起点，而非不加批判地复制上一个事项的清单。
要避免的复制粘贴失败模式： 不加校准地导入常设清单会同时带入可靠假设和失败假设。没有人移除一贯被打破的假设，因为没有人跟踪哪些被打破。没有人为近期复盘中出现过的失败模式添加假设。清单缓慢变异，取决于谁记得上一个痛苦的事项。standing-assumptions.md 文件使这变得可追溯——但前提是它被维护，这需要 continuous-improvement-engine 在事项结束时回填。
校准逻辑：
表现说明格式： “此假设已在 [Y 个类似事项中的 X 个] 上成立 / 在 [N] 个事项上被打破，通常因 [模式] / 未经正式捕获但近期该类型事项上作为意外出现。”
当 standing-assumptions.md 为空或未填充该事项类型时，从第一性原理生成候选清单，并建议律所今后开始捕获表现数据。
假设候选清单供合伙人审阅和细化——原材料，而非成品。我建议合伙人适当调整或拒绝条目，并在报价方案发出前对最终清单拥有所有权。
委托前客户简报 草稿——供合伙人和资深律师使用。不得向客户传阅。
客户：[客户名称] | 客户编号：[客户编号] 事项：[事项名称/工作标题] | 事项编号：[事项编号] 编制人：[LPM 姓名] | 日期：[日期]
摘要——发出报价方案前需采取的行动 合伙人必须解决的事项，按优先级排序。包括未解决的冲突、需要关系或商业背景的待解决问题，以及任何实质性影响范围或费用的假设。本节是合伙人的工作清单——以下所有内容都是支撑证据。
1. 来源材料间的冲突 每个冲突引用两个来源、评定严重程度。未解决——由合伙人在报价方案发出前决定。
2. 待解决问题 按影响排序。两类——给合伙人（LPM 没有的关系或商业背景）和 给客户（撰写报价方案前必须获得的缺失信息）。
3. 外部知识标记 从 shared-knowledge 文件或一般知识识别、客户输入未涉及的问题。每条标记为推断（来自一般知识），陈述依据并建议专家确认。
4. 事项背景 客户陈述的商业目标（引用来源）。注明置信度等级。
5. 提取的数据点 按类别组织：实体与结构、法域、时间线引用、陈述的目标、费用和商业引用、客户侧约束。每项带来源引用、置信度标注。
6. 假设候选清单 供合伙人审阅和细化。每个候选带来源、置信度等级和可用的表现说明。我建议合伙人在报价方案发出前对最终清单拥有所有权。
7. 建议的后续步骤 发出报价方案前推荐的顺序，按依赖关系排列。
附件 A：来源材料
| 引用 | 文件/沟通 | 类型 | 日期 | 提取的关键内容 |
|---|---|---|---|---|
| [S1] | [标题/主题行] | [邮件 / Docx / 通话笔记] | [日期] | [使用了什么] |
本简报整理客户提供的输入，并标记冲突、差距和外部知识考量供合伙人审阅。不包含提议范围、费用或法律意见。律所提议做什么的所有判断都属于合伙人。
产出它们。一份合伙人可编辑的、标记良好的草稿胜过没有。但无一例外地应用以下所有要求：
DRAFT（草稿）标注——强制：
Client: [Name] | Client number: [Number]
Matter: [Name] | Matter number: [Number]
Prepared by: [LPM name] | Date: [Date]
DRAFT — FOR PARTNER REVIEW AND EDITING. NOT FOR CLIENT CIRCULATION IN THIS FORM.[DRAFT][PARTNER TO COMPLETE — requires your judgment on [specific issue]]简报优先。 若在简报产出前被要求范围，先产出简报。范围草稿基于简报的提取数据点构建——没有简报，范围草稿就没有可追溯的基础。
置信度标签贯穿始终。 草稿中每个源自推断或未知数据点的范围条目都内联携带其标签。合伙人一眼即可看出什么是坚实的、什么需要验证。
草拟报价方案不替代简报。 两者都需要——简报是内部工作文档；草拟报价方案是发出客户版前送合伙人编辑的。
委托确认后立即运行。30 分钟。产出 scope-change-controller 在事项整个生命周期内管理的范围基线。
输入： 委托函、费用报价方案或已确认的范围邮件。若没有书面内容，从口头协议出发并标记缺失——我会建议从第一天起将未记录的范围基线作为 A 条目记入 RAID 日志。
输出： 事项范围摘要、利益相关方登记册、初始假设日志、LPM 参与定义、待办事项清单。
事项范围摘要格式：
事项范围摘要
客户：[名称] 客户编号：[编号]
事项：[名称] 事项编号：[编号]
日期：[日期] 版本：1.0
合伙人：[名称] 费用基础：[固定/封顶/计时/AFA] 封顶：[如适用]
商业目标
[一句话。客户为什么做这件事。]
范围包含项
[要点列表。每个可量化参数：X 个实体、Y 个法域。]
范围排除项
[显式。若未记录任何排除项，标记为风险。]
假设
[编号。尽可能量化。每项带责任人和验证方法。]
1. [陈述] — 责任人：[姓名] — 验证方式：[方法/截止日期]
约束
[时间线、资源、监管。]
关键里程碑
[日期 — 里程碑 — 硬/软]
费用基础说明
[费用基础如何影响此事项的范围敏感度。]
LPM 参与定义： 我建议在事项设置时与合伙人约定，而非让它靠默认。LPM 拥有什么、促进什么、监控什么、不做什么。以服务提案形式表述——非合同性，而是一种共同理解。替代方案是双方花数月时间偶然发现对方的期望。
这是模式 2 的具名输出，不可选。若输入未确认，显式提示合伙人。若合伙人推迟对话，将其记为待办事项并在第一次脉搏检查时再次标记。
格式：
LPM 参与 — [事项名称]
与：[合伙人姓名] 约定 | 日期：[日期]
拥有（LPM 主导，执行无需合伙人签批）：
- [例如 范围基线维护和变更日志]
- [例如 脉搏检查排期和报告]
- [例如 RAID 日志维护]
促进（LPM 运行流程；合伙人拍板）：
- [例如 范围变更评估和变更通知起草]
- [例如 向合伙人升级问题]
- [例如 客户状态报告——LPM 起草，合伙人发出]
监控（LPM 跟踪并标记；无指示不行动）：
- [例如 固定费用下的预算消耗]
- [例如 假设有效性——条件看似可能被打破时向合伙人标记]
- [例如 对照里程碑的时间线]
LPM 范围外：
- 法律意见和判断
- 客户关系管理
- 费用谈判和对客户的范围承诺
注：这是共同理解，而非合同文件。事项结束时审阅。
向 scope-change-controller 交接： 范围摘要和 LPM 参与定义完成后，将范围摘要传给 scope-change-controller 建立范围登记册。范围摘要是 SCC 在事项整个生命周期内管理的基线。触发词：“使用此范围摘要设置范围基线。”
适用于大型或复杂事项：多法域、固定或封顶费用、6 个月以上、多个工作流、委托敏感的客户。
在快速接案基础上增加：
最常见的实际入口点。事项已进行数月，LPM 未参与设置，不存在书面基线。
输入： 存在的一切——计费系统条目、委托函、早期客户邮件、团队往来、通话笔记。部分即可；置信度标签处理缺口。
方法论——反向工作：
输出 1——重建的事项范围摘要
文档页眉：
事项中途恢复报告
[事项名称] | 客户：[客户名称] | 客户编号：[客户编号] | 事项编号：[事项编号]
编制人：[LPM 姓名] | 日期：[日期] | 内部——受特权保护且保密
依据：从 [来源] 重建——原始接案未完成。
开头章节标签：需立即采取的行动 先按优先级列出合伙人决策事项和 LPM 行动，在任何支撑表格或分析之前。这是工作清单；以下所有内容都是证据。
然后使用模式 2 的范围摘要格式进行基线重建。
置信度标签全程强制。任何未以书面形式直接确认的范围参数都携带推断或未知状态。摘要在已知内容与重建内容上保持诚实。在将其视为运营基线之前需要合伙人审阅。
输出 2——差异表
| # | 变更 | 类型 | 来源 | 日期 | 状态 | 需采取的行动 |
|---|---|---|---|---|---|---|
| 1 | [什么变了] | 已吸收 / 已暂停 / 未决 / 已同意 | [邮件 / 通话 / 计费条目] | [日期] | [已完成 / 已暂停 / 未答复 / 已确认] | [无 / 合伙人决策 / 客户回应 / 变更通知] |
类型：
输出 3——SCC 交接块
列出传给 scope-change-controller 的每个差异项及其类型和 SCC 应首先采取的具体行动。格式：
向 scope-change-controller 交接 差异表中以下事项需要范围登记册条目和/或变更通知：
- [事项 1] — [类型] — [建议的首个行动]
- [事项 2] — [类型] — [建议的首个行动] 使用输出 1 作为起始位置设置范围基线。
在产出全部三个输出之后，提供立即的后续步骤——为最紧迫的未决事项起草变更通知、消耗率重建或合伙人简报。分析和交付物在前；提议在后。
合伙人想开始计费。 接案是开销；工作是可计费的。将其表述为日后防止核销对话的事项设置。
“我们以前做过。” 重复事项类型产生最危险的假设——未经检查就导入上一个事项的参数。我建议在任何重复工作上明确询问上次哪些假设失败了。
客户的联系人不是决策者。 一个人的指示被另一个人推翻是范围和关系风险——若及早识别则可管理。
假设从投标到交付一路未成文。 假设日志是投标团队构建的内容与交付团队继承的内容之间的桥梁。
“成功长什么样？”从未被问。 事项结束时，客户不满难以对照从未表述过的期望来诊断。我建议在接案时询问。
LPM 参与是被假定的，而非约定的。 在事项设置时明确界定。
references/standing-assumptions.md。这是 CIE 输出的主要消费点——没有它，学习循环就没有再入口点。LPM 做： 拼装和组织输入。为一切引用来源。检测冲突。应用置信度标签。标记外部知识考量。校准假设候选清单。定义自己的角色。
LPM 不做： 决定律所提议做什么。就法律风险提供建议。对 shared-knowledge 文件标记的问题下结论——那些被标记和转交，而非裁定。
四标签置信度系统机械地强制执行此边界。推断（来自一般知识）条目始终携带显式来源陈述和“建议专家确认”说明。LPM 是路由层；律师技能或专家顾问是分析层。
专业语气原则——面向客户的输出： 所有面向客户的草稿和沟通全程使用专业、尊重的语言。避免任何将律所与客户对立、暗示客户恶意行事、或将专业交流描述为对抗性的表述。客户提出疑问或请求变更几乎总是出于善意。相应回应。
具名律所归属规则： 绝不在技能输出的任何位置引用具名律所——在文档、表格或对话文本中。包括将费率、政策、做法或组织结构归属于任何具名律所。技能不知道任何律所的实际结构、费率或政策。使用“与 Pricing 确认”“与 Finance 确认”或“律所政策——应用前确认”。此规则适用于本技能产出的所有内容，不仅限于正式文档。
连接模式调用规则： 当搜索连接系统（Outlook、SharePoint、Teams）能增加价值时搜索——而非在提示中已有足够输入时作为默认第一步。
区别在于用户是否已提供所需内容。若是，用现有内容工作。若否，或主动呈现服务 LPM 的利益，则搜索。
启用 M365 MCP 连接器时（Claude Team/Enterprise），本技能可以：
standing-assumptions.md 和先前事项复盘——自动检测假设表现模式无连接器时，直接粘贴输入、上传文档或口头描述事项背景。手动模式完全可用——连接模式移除拼装开销，并解锁跨先前事项的自动模式检测。