---

name: matter-plan-builder-scott-margetts description: "将商定的范围转化为结构化的事项计划 — 阶段、工作流、里程碑、依赖关系、责任人分配和事项设置决策。在规划新事项、进行启动会、构建工作流计划、构建阶段结构、设置任务代码，或产出驱动状态报告的计划时使用。触发方式：'build a plan'、'matter plan'、'project plan'、'what are the phases'、'workstream plan'、'how do we sequence this'、'who owns what'、'task codes'、'matter setup'、'workstream plan'、'matter plan'、'rolling wave'、'plan the next phase'、'what comes first'、'kickoff agenda'。" metadata: author: Scott Margetts license: Apache-2.0 version: 2026.03.17

事项计划构建器（Matter Plan Builder）

目的

将商定的范围转化为团队可以据以执行的结构化事项计划。只存在于合伙人脑海中的计划不是计划 — 它是意图。本技能的功能是让计划显性化、分配归属、排定工作顺序，并产出一个每一项其他 LPM 纪律都可以引用的产出。

本技能接收 matter-intake-scoping 的产出（或等效的范围描述），并产出规划层。scope-change-controller 在整个事项中将该计划作为基线进行管理。status-report-drafter 对照它报告进度。timeline-generator 为其增加依赖逻辑和关键路径可视化。

事项设置决策是本技能的一部分。 事项在计费系统中的配置方式 — 单一事项 vs 分阶段结构、任务代码、事项编号 — 直接决定收集到的数据是否对报告、计费和对未来的范围界定有用。设置时出错会让整个项目在整个生命周期内付出代价。这不是计费管理的行政任务。它是一项必须在时间开始被记录之前作出的战略规划决策。

---

运行模式

模式 1 — 完整计划（大多数事项）

从范围到完整计划。事项计划（阶段、工作流、里程碑、关键依赖、责任人）加每个工作流的工作流计划。与计划一并产出事项设置建议。具有明确团队的中等复杂度事项的默认模式。

模式 1 无条件地为每个工作流产出工作流计划。 如果有五个工作流，就产出五份工作流计划。不要只产出第一个工作流并注明其余"遵循相同格式" — 全部都要产出。当需要不带工作流细节的事项计划时，模式 2 才是正确的模式。如果用户在拥有许多工作流的事项上调用模式 1，而完整工作流计划会不成比例，请在继续之前询问模式 2 是否更合适。

模式 2 — 仅事项计划（大型项目）

仅阶段、工作流、高层级里程碑和责任人。工作流计划是工作流负责人的职责 — 本技能产出事项计划及工作流负责人应遵循的模板。产出带依赖标记的计划供 timeline-generator 使用。

模式 3 — 工作流计划（工作流细节）

以细节构建的单一工作流或辖区计划。输入：事项计划（或等效物）加工作流范围。产出：带排序、依赖、时长和责任人的任务层面计划。专为工作流负责人持有和维护而设计。

模式 4 — 滚动波（Rolling wave）

适用于完整范围尚未定义的事项。以完整细节规划当前阶段。为后续阶段产出桩计划（stub plan）— 仅里程碑，无任务细节。标记需要详细规划下一阶段的触发点。桩是占位符，而非承诺 — 如此标记。

模式 5 — 依据往来函件更新计划

实践中使用最频繁的模式。接受电子邮件、通话记录或会议记录，并针对现有计划提出更新建议 — 状态变更、进度备注、截止日期修订、新障碍、已完成任务。LPM 审核并确认；他们不手动创建更新。

该模式之所以存在，是因为替代方案 — 请律师直接更新计划 — 行不通。律师不会更新计划。信息存在于他们的电子邮件和他们的脑海中。LPM 的工作是从这些来源提取信息，而不制造比事项本身耗时更长的人工数据录入负担。

输入：现有计划（作为文件上传或粘贴）+ 自上次更新以来的往来函件。产出：拟议的计划变更，以确认清单呈现。LPM 逐项确认、驳回或编辑每项拟议变更。确认后，更新后的计划作为新版本（.docx 和结构化导出）产出。

在连接模式下，该模式可以自动触发 — Claude 监控事项往来函件并在无需等待 LPM 发起的情况下浮现拟议更新。

---

分步流程

步骤 1：确认范围基线

阅读所有提供的材料。识别是否存在结构化范围摘要（来自 matter-intake-scoping 模式 2/3），还是必须从输入重构范围。如要重构：识别事项类型、客户目标、关键交付物、涉及的辖区和已知约束。在继续之前标记范围缺口 — 建立在不完整范围上的计划将需要重建。

如果范围单薄，浮现缺口：在构建此计划之前我们需要知道什么？明确列出。不要产出埋没假设却不加标记的计划。

在产出任何计划输出之前，确认责任人姓名。 一份在启动时分发、通篇带"[SA name]"占位符的计划不是可用的计划 — 它是草稿。如果输入中未提供责任人姓名，停下来并在产出任何输出之前询问："为正确分配归属，我需要每个工作流负责人的姓名。请确认：[列出从范围识别出的工作流]。如果姓名尚未确认，请说明，我将以 [TBC — confirm before distributing] 占位符产出计划并将其标记为 DRAFT。"

在用户回复之前 — 无论提供姓名，还是明确指示以 TBC 占位符继续 — 都不要推进到计划输出。不要因为用户说他们不知道谁负责什么，就静默推断占位符可以接受。用户必须明确作出这一决定。

消费 matter-intake-scoping 模式 2 的产出： 当提供了来自 matter-intake-scoping 的模式 2 范围摘要时，将其字段直接映射到计划输入 — 不要将其视为需要重新解读的通用叙述：

matter-intake-scoping 字段	映射到计划输入
纳入项（Inclusions）	工作流范围和交付物 — 每个工作流必须产出什么
排除项（Exclusions）	明确的范围外项目 — 在计划备注中标记以防漂移
假设（Assumptions）	事项启动时 RAID 日志的 A 条目；假设属于信息依赖的也填充依赖登记册
约束（Constraints）	阶段时长限制、资源约束、固定外部日期
里程碑（Milestones）	事项计划里程碑清单的起点 — 在定稿前对照阶段模式验证
费用基础（Fee basis）	事项设置建议 — 分阶段 vs 单一事项、费用结构是否需要阶段层面跟踪
LPM 参与定义	沟通日程表和计划维护职责

如果范围摘要中缺少这些字段中的任何一个，在产出计划之前标记该缺口。

步骤 2：识别阶段和工作流

将事项分解为阶段（带定义好的进入/退出标准的顺序阶段）和工作流（跨阶段运行的平行工作线）。它们是同一计划的两个不同维度。

阶段基于时间且顺序进行。阶段之间的移动应是一个审慎的决定 — 一个阶段门禁（phase gate）— 而非仅仅是时间流逝。阶段门禁是合伙人（有时还有客户）确认的时刻：前一阶段的工作已达到要求的标准完成、下一阶段的条件已满足、团队被授权继续。按事项类型的常见阶段模式见下文领域知识部分。

工作流基于职能且往往平行：公司、税务、雇佣、房地产、监管、金融。在多辖区事项上，工作流可以按辖区复制（德国公司、荷兰公司），或构建为一个跨辖区工作流，其下辖各辖区负责人。正确的结构取决于各辖区是并行执行相同工作，还是执行最终汇合的不同工作。

事项计划是两者的交集：哪些工作流在哪些阶段活跃、每个产出什么、由谁负责。

步骤 3：识别里程碑和依赖关系

里程碑是二元的 — 已完成或未完成。不是"75% 完成"。不是"进展顺利"。里程碑标记某件重要事情的完成：监管申报已提交、尽调报告已出具、交易文件已商定、执行已完成。每个里程碑必须有具名责任人和目标日期。

明确标记依赖关系。法律工作中有三种类型重要：

前置依赖 — Y 完成之前 X 无法开始。这些是关键路径候选。按类型为 timeline-generator 标记：FS（完成—开始）、FF（完成—完成）、SS（开始—开始）、SF（开始—完成）。法律工作中最常见的是 FS — 一件事必须先完成，下一件事才能开始。FF 和 SS 最常见于多辖区事项，其中平行工作流必须共同到达一个里程碑后才能汇合。

共享资源依赖 — X 和 Y 在同一时间需要同一个人。在规划阶段浮现这些。resource-planner 处理详细分析；本技能标记冲突。

信息依赖 — 未经外部方确认 X 无法推进：监管机构、相对方、税务机关、客户内部团队。这些最危险，因为它们的时长在律所控制之外。对每项信息依赖：谁提供、预期提前期是多少，以及若延迟两周/四周的下游影响。

步骤 4：分配责任人

每个工作流需要一个单一的具名负责人。不是"伦敦团队" — 是一个人。不是"当地律师" — 是具名律所，以及在已知时，具名的个人。没有问责制的归属是一个会漂移的工作流。

在工作流负责人之下：识别每个工作流是否在正确层级拥有足够资源。齿轮比（gearing）很重要 — 只配备资深律师的工作流在例行任务上会既昂贵又缓慢；没有资深资源的工作流会把一切升级。标记齿轮比问题；resource-planner 处理详细分析。

步骤 5：构建事项设置建议

在计划定稿之前记录事项配置。这在设置时最容易做对，在事项运行后最难修复。

单一事项还是分阶段结构？ 对直截了当的工作，单一事项单代码简化计费。分阶段事项允许阶段层面的财务跟踪和阶段门禁成本控制 — 在需要客户批准才能继续，或费用安排在阶段之间变化时必不可少。

任务代码设计： 任务代码决定您可以提取什么数据。设计它们以匹配事项将需要的报告：

• 如果状态报告每工作流一行，每个工作流需要一个代码
• 如果预算是按辖区构建的，每个辖区需要一个代码
• 如果将与客户进行阶段门禁成本讨论，每个阶段需要一个代码
• 如果结案时会进行当地律师成本比较，每个外部律所需要代码

最常见的失败：当事项有可识别的子工作流时使用通用代码（如"Corporate"、"Tax"）。数据变得过于聚合，除了总额之外对任何事都无用。

计费指令： 任务代码商定后，产出一段计费指令，指明哪个代码覆盖哪项工作。在启动时分发。没有它，每个计时员各自猜测，数据质量在第一个计费周期内就会下降。

步骤 6：产出计划

按顺序产出：先事项计划，然后每个工作流的工作流计划，然后是事项设置建议。每份都是针对相关受众的独立产出。

事项计划格式：

• 阶段摘要：阶段名称、进入标准、退出标准、时长估算、责任人、关键里程碑
• 工作流摘要：工作流、责任人、活跃阶段、关键交付物、按类型标记的依赖
• 依赖登记册：依赖、类型（前置/资源/信息）、被依赖任务、阻塞任务、责任人、延迟影响

工作流计划格式（每个工作流）：

任务表 — 必需列按此顺序。即使某字段为空，也不要省略任何列：

| 唯一 ID | 任务 ID | 任务摘要 | 任务描述 | 责任人 | 截止日期 | 时长（天）| 前置任务 | 依赖类型 | 里程碑 | 状态 | 进度备注 | 任务代码 |

• 唯一 ID： [MatterCode]-T-[顺序号，事项范围内，绝不重用] — 如 88234-T-001、88234-T-002。跨所有工作流连续 — 公司任务可能是 88234-T-001 至 88234-T-012，雇佣为 88234-T-013 至 88234-T-019。不要按工作流重新开始编号。
• 任务 ID： 计划内人类可读引用（如 WS1-T01）— 用于文档中的可读性和前置引用。
• 截止日期： 具体的日历日期。不是阶段引用。不是"第 3 周"。是一个日期。
• 前置任务： 任务 ID（人类可读）或"None" — 绝不空白。
• 进度备注： 未开始时留空 — 但列必须存在。

里程碑清单：唯一 ID | 里程碑 ID | 里程碑描述 | 责任人 | 目标日期 | 前置任务 | 阶段门禁？| RAG

未决事项：假设、未决的信息请求、需要的外部确认。

启动会议程（应要求产出）： 根据事项计划起草：范围确认、工作流介绍、里程碑走查、依赖标记、事项设置简报（任务代码和计费指令）、升级路径、下次评审日期。

---

领域知识 — 事项类型阶段模式

起点，而非处方。价值在于记录本事项的阶段与标准模式有何不同以及为什么。

公司交易（并购、分拆、处置）： 准备 → 尽职调查 → 谈判 → 签署 → 监管 / 先决条件 → 交割 → 交割后

阶段门禁：谈判开始前 DD 报告签核；签署前董事会/客户批准；安排交割前先决条件满足确认。交割后行动（备案、登记、通知）经常规划不足 — 它们不附收入并被降级。明确规划它们。

公司重组（多辖区）： 范围界定 / 结构设计 → 排序 → 辖区层面执行 → 交割 / 登记确认 → 交割后（除名、注销、最终备案）

关键依赖模式：必须先完成、其他辖区才能开始的辖区构成结构性关键路径。这不是日程安排偏好 — 这是法律排序要求。尽早识别依赖链并将其作为硬 FS 依赖传给 timeline-generator。LPM for M&A 插件中的 reorg-step-plan-builder 技能为该事项类型提供详细方法论。

阶段门禁：执行开始前结构设计签核；从属辖区开始前先决辖区完成；交割后行动开始前最终登记确认。

诉讼 / 仲裁： 诉状 → 披露 / 证据开示 → 证据 → 听证 → 听证后 / 执行

信息依赖模式：第三方披露、专家可用性和听证日期都在律所控制之外。详细规划律所控制范围内的事项；明确标记外部依赖并给出时长区间。

阶段门禁：诉状提交前策略确认；文件审阅开始前披露策略商定；证人陈述准备前证据策略确认。

监管（牌照、授权）： 评估 → 申请准备 → 提交 → 监管审查期 → 决定 → 实施

监管审查期是一个时长未知的信息依赖。它完全阻止某些下游活动，仅部分阻止其他。在规划阶段：识别审查期间可以并行运行什么、什么被阻止直到决定作出，以及最低 / 预期 / 最高时长区间。

金融 / 资本市场： 委任 / 结构设计 → 文件 → 尽职调查 → 营销 / 路演 → 签署 → 结算 / 交割

阶段门禁：营销开始前文件商定；最终条款确定前 DD 确认。时间压缩是资本市场工作的主导压力 — 计划必须构建为能够容纳加速，同时不丢失已被跳过或推迟事项的记录。

---

领域知识 — 常见规划失败

计划已构建但从未分发。 合伙人批准它，LPM 归档它，团队从未看到它。无人知晓的计划对行为没有影响。在启动时分发。在每次状态电话中引用。在范围变化时更新。

里程碑与活动混淆。 "起草 SPA" 是一项活动。"SPA 已商定且可执行" 是一个里程碑。对照活动的状态报告产生噪音；对照里程碑则产生信号。每个工作流应在每个报告期内至少有一个里程碑。如果没有，该工作流就没有有意义的状态可报告。

依赖被识别但未被管理。 一个不被审阅的依赖登记册是文档，而非管理。在每次状态电话中审阅：哪些前置任务有风险、哪些信息请求未决、哪些外部确认尚未到达。悄悄滑期而无人注意的前置任务，就是那个改变关键路径的任务。

滚动波规划被视为失败。 它不是。在复杂事项上，超出当前阶段的详细规划往往是草率的。滚动波方法是自律的：详细规划当前阶段、为下一阶段立桩、为下一阶段何时被规划设定触发里程碑。桩不是失败 — 它是承认过早规划与没有规划一样危险。

事项设置被委托给计费管理。 配置决策必须由 LPM 或合伙人在事项开启前作出。一旦时间开始被记录，重新配置代码会让历史数据搁浅。计费团队执行配置。LPM 设计它。

工作流责任人是组织，而非人。 "当地律师 — 德国" 不是责任人。当工作流滑期且需要升级时，需要一个名字。

范围变化时计划未更新。 scope-change-controller 管理范围变更。但未流入计划的变更会产出一份不再反映团队实际工作的计划。当 scope-change-controller 记录一项已批准的变更时，评估计划是否需要更新 — 并更新它。

工作流计划被提交但从未相互对照审阅。 在大型项目上，中央 LPM 收到工作流计划但从未跨工作流审阅。关键路径跨越工作流边界；没有单个工作流负责人能看到它。中央 LPM 持有跨工作流视角 — 识别工作流里程碑在何处制造项目级依赖是首要的规划增值。

计划维护完全落到 LPM 头上。 这是实践中的主导失败模式。律师不更新任务计划 — 不是因为疏忽，而是因为更新 SharePoint List 或 Excel 跟踪器不是法律工作被传达的方式。法律工作通过电子邮件传达。保持计划最新所需的信息存在于往来函件中；提取它并将其录入结构化格式是一项人工翻译任务，LPM 为整个事项执行。在一个有 40 多个活跃工作流的 12 个月跨境重组中，这是数百小时不增加任何分析价值的工作 — 它是转录。

后果是数据退化。任务连续数周显示"In progress"，因为没人把它们更新为"Complete"。截止日期漂移，因为 LPM 没有捕捉到埋在辖区电子邮件中的日期变更。进度备注变得陈旧。计划停止反映现实。基于计划构建的状态报告变得不可靠。合伙人对报告失去信心。对规划的投入被回溯性地判定为浪费的努力。

解决方案不是要求律师更勤勉地更新计划。而是完全消除人工提取步骤。模式 5 为此而存在：Claude 读取往来函件、提出更新建议，LPM 确认。LPM 的角色从数据录入转变为判断 — 这正是他们价值真正所在之处。在连接模式下，这连续运作：计划总是距离最新状态一次确认之遥。

---

标准计划字段

这些是每个计划组成部分的最低必需字段。缺少其中任何字段的计划条目都无法用于驱动执行、状态报告或升级 — 它是清单，而非计划。

工作流页眉（每个工作流一个）

字段	用途
唯一 ID	创建时分配且绝不变更的稳定事项范围标识符 — 如 [MatterCode]-WS-001。其他技能在 RAID 条目、范围变更通知和状态报告中引用此工作流时使用
工作流名称	在所有计划文档和状态报告中一致使用的标签
责任人（具名个人）	对工作流交付负责 — 一个人，而非团队或律所
活跃阶段	该工作流在哪些阶段运作
任务代码	此工作流中所有时间据以记录的计费代码
升级联系人	当工作流问题无法在责任人层面解决时，责任人向谁升级

任务条目（每个任务一个）

字段	用途
唯一 ID	创建时分配且绝不变更的稳定事项范围标识符 — 如 [MatterCode]-T-001。其他技能在 RAID 条目、范围变更通知和状态更新中引用此任务时使用。即使任务被移动、重命名或重构也绝不重新分配。
任务 ID	供计划文档内使用的人类可读引用代码（如 WS1-T01）
任务摘要	单行标签 — 动词 + 名词（"Prepare tax opinion"、"Submit regulatory filing"）
任务描述	多行细节 — 正在做什么、产出是什么、任何约束或指示
工作流	此任务属于哪个工作流 — 必须与工作流页眉标签完全一致
阶段	此任务落在哪个阶段 — 必须与事项计划中的阶段名称一致
里程碑	此任务对哪个里程碑有贡献 — 将任务层面执行与里程碑层面报告连接
责任人	负责完成的具名个人
截止日期	目标完成日期 — 具体日期，而非阶段引用
时长估算	工作日 — 除非明确说明，非日历日。即使粗略估算也能浮现规划缺口。
前置任务	在此任务开始前必须完成的任务 ID — 关键路径计算所需
依赖类型	FS / FF / SS / SF — 供 timeline-generator 使用
状态	未开始 / 进行中 / 已完成 / 受阻
进度备注	自由文本 — 当前位置、障碍、下一步行动。在每次状态评审时更新。
任务代码	针对此任务记录时间的计费代码

里程碑条目（每个里程碑一个）

字段	用途
唯一 ID	创建时分配且绝不变更的稳定事项范围标识符 — 如 [MatterCode]-M-001。其他技能在 timeline-generator、状态报告和阶段门禁记录中引用此里程碑时使用
里程碑 ID	供计划文档内使用的人类可读引用代码（如 WS1-M01）
里程碑描述	完成状态的二元陈述 — "X 已提交"、"Y 已商定"、"Z 已登记"
责任人	负责确认完成的具名个人
目标日期	具体日期，而非阶段引用
前置任务	达到此里程碑必须完成的任务 ID
RAG 状态	绿 / 黄 / 红 — 在每次状态评审时评估
阶段门禁？	是 / 否 — 此里程碑的完成是否触发阶段门禁决策

依赖条目（每个被标记的依赖一个）

字段	用途
依赖 ID	简短引用代码
类型	前置 / 资源 / 信息
阻塞事项	必须完成或被收到的内容
被依赖事项	在阻塞事项解决前无法推进的内容
阻塞事项责任人	对阻塞事项负责的人（可能是外部的）
预期解决日期	阻塞事项解决的目标日期
延迟 2 周的影响	项目级影响 — 哪些里程碑移动、移动多少
延迟 4 周的影响	更大延迟下的项目级影响

没有"延迟影响"列的依赖登记册不是风险管理工具。它是一份"可能出问题的事情"清单，却不评估问题有多严重。

---

沟通节奏

计划必须包含会议和报告节奏 — 不是作为 stakeholder-comms-planner 的产出，而是作为计划基础设施。没有内置评审节奏的计划会立即变得陈旧，且永远不会被正式维护。

每份计划都应包含的标准节奏要素：

状态电话（内部）： 频率（每周 / 每两周）、出席者（至少工作流负责人）、目的（对照计划的里程碑进度、依赖评审、升级分诊）。计划在此电话中被评审 — 而不仅仅是讨论。如果计划不在屏幕上，它就没有被管理。

客户报告： 频率（每周 / 每月 / 里程碑触发）、格式（来自 status-report-drafter 的状态报告）、报告编制责任人。

阶段门禁评审： 在每阶段开始时为当前阶段结束时排定。责任人：合伙人和 LPM。目的：确认阶段完成标准已满足、授权推进。不是状态电话 — 是决策点。

计划评审： 频率（大多数事项每月，快节奏事项每两周）。目的：评估计划是否仍反映范围、标记已偏离计划的任务、更新估算。责任人：LPM。计划评审的产出要么是确认的计划，要么是更新的计划 — 不是"一切顺利"的口头保证。

计费评审： 频率（每月，与计费周期对齐）。目的：对照任务代码评审在办工作（WIP）、识别记录到错误代码的时间、确认为即将开展的工作分配的任务代码。责任人：LPM 与 billing-cycle-manager。

在事项计划文档中添加摘要沟通日程表：会议类型、频率、责任人、关联的计划产出。

---

输出格式

除非用户明确要求，所有产出均以 .docx 生成。这些是事项记录 — 它们属于事项文件夹。

每份产出都包含标识块：

Client: [Name]          Client number: [Number]
Matter: [Name]          Matter number: [Number]
Plan version: [v1.0]    Prepared by: [LPM name]    Date: [Date]

清楚标记滚动波桩：[ROLLING WAVE — [phase name] to be planned in detail at: [trigger milestone]]

结构化数据导出： 每份计划产出都附有一份结构化数据导出（CSV 或 JSON），包含所有任务和里程碑条目及其完整字段集。这是 SharePoint List 或等效记录系统的输入格式。.docx 用于人工分发和参考。结构化导出用于机器可读跟踪 — 它正是使模式 5 更新、连接模式监控和跨技能数据交换成为可能的机制。

只以 Word 文档形式存在的计划无法由 Claude 更新。以 SharePoint List 形式存在的计划可以。本技能定义的标准字段就是 SharePoint List 模式。部署本技能的律所应在事项设置时，使用初始计划构建的结构化导出来配置 List。

计划版本化：每份产出都盖有版本号（v1.0、v1.1 等）和日期。先前版本被保留。绝不覆盖计划版本 — 版本历史是事项如何演变的审计轨迹。

每份计划产出必须包含以下全部内容。不要产出缺少这些要素的计划：

1. 标识块（Client、Matter、版本、LPM、日期）
2. 事项计划（阶段、工作流摘要、里程碑登记册、依赖登记册）
3. 沟通日程表
4. 事项设置建议（任务代码、计费指令）
5. 每个工作流的工作流计划 — 所有必需列均在（参见步骤 6）
6. RAID 日志开账条目
7. 跨技能交接提示（参见"跨技能交接"部分）— 在每份计划产出的末尾以具名部分产出："Next Steps — Cross-Skill Handoffs"
8. 结构化数据导出（CSV）— 带所有字段的任务和里程碑条目。如果无法附加文件，则内联产出为带标签的部分。

第 7 和第 8 项不是可选附加。没有交接提示的计划，让 LPM 靠记忆记住需要触发哪些其他技能。没有结构化导出的计划无法由 Claude 更新。

---

跨技能交接

• 来自 matter-intake-scoping： 范围摘要（模式 2/3 产出）是主要输入。范围已设定；本技能将其操作化。使用步骤 1 中的字段映射消费。
• 来自 scope-change-controller： 当传入已批准的范围变更时，将其视为模式 5 触发源。阅读变更通知，识别哪些计划组件受影响（任务、里程碑、责任人、依赖、阶段），以确认清单的形式提出更新建议，并在确认后产出更新的计划版本。未流入计划的范围变更会产生漂移 — 计划停止反映团队实际在做的事。给产出定版：如果当前计划是 v1.2，变更后的计划是 v1.3。
• 至 timeline-generator： 带依赖标记的任务清单和带依赖类型标签（FS/FF/SS/SF）的里程碑清单。随附："Build a dependency network and critical path from this plan."
• 至 scope-change-controller： 完成的计划是范围基线。随附："Set up scope baseline — here is the agreed matter plan."
• 至 status-report-drafter： 里程碑清单和工作流结构是报告基线。status-report-drafter 对照里程碑报告进度，而非任务完成百分比。
• 至 stakeholder-comms-planner： 工作流责任人、阶段节奏和里程碑日程为沟通节奏设计提供信息。
• 至 resource-planner： 计划中标记的工作流资源需求和齿轮比问题。
• 至 billing-cycle-manager： 事项设置建议 — 任务代码、阶段结构、计费指令。
• 至 risk-and-issues-manager： 信息依赖和计划假设是 RAID 日志的输入。在事项启动时作为 A 条目（假设）和 R 条目（风险）传入。

---

具名律所归因规则： 绝不在技能输出的任何位置引用具名律所 — 无论是在文档、表格还是对话文本中。这包括将费率、政策、实践或组织结构归因于任何具名律师事务所。本技能不知道任何律所的实际结构、费率或政策。使用"confirm with Pricing"、"confirm with Finance"或"firm policy — confirm before applying"。该规则适用于本技能产出的一切内容，而不仅仅是正式文档。

---

M365 连接模式（可选）

连接模式调用规则： 在这样做能增加价值时搜索连接系统（Outlook、SharePoint、Teams）— 而不是在提示词中已有充分输入时将其作为默认第一步。

• 输入已充分提供： 用户粘贴了带完整上下文的电子邮件、文档或数据。基于已有内容工作。不要先搜索 — 它只增加摩擦而不增加信息。
• 输入不完整或应主动浮现： 用户提到了应被检索的内容（"Outlook 里有一份发票"、"现在是月底"），或连接模式正在后台/定时模式运行。主动搜索 — 这是反向调用模型，是价值最高的连接模式行为。

区别在于用户是否已提供所需内容。如果是，就基于它工作。如果不是，或主动浮现服务 LPM，就搜索。

当 M365 MCP 连接器启用时（Claude Team/Enterprise），本技能可以：

• 搜索 SharePoint 获取同类型事项的先前计划，用作规划先例
• 从 SharePoint 提取范围摘要和聘用函，为会话提供信息
• 在 Outlook 中搜索启动往来函件，识别已作出的规划决策
• 在 Outlook 中创建带启动会议程的日历邀请，议程根据事项计划起草
• 在启动后，将已批准的任务和里程碑推送到 Planner 或 Teams 进行实时跟踪

无连接器时：通过粘贴文本或直接上传文件提供范围摘要、先前计划和相关往来函件。