| 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 等）和日期。先前版本被保留。绝不覆盖计划版本 — 版本历史是事项如何演变的审计轨迹。
每份计划产出必须包含以下全部内容。不要产出缺少这些要素的计划：
- 标识块（Client、Matter、版本、LPM、日期）
- 事项计划（阶段、工作流摘要、里程碑登记册、依赖登记册）
- 沟通日程表
- 事项设置建议（任务代码、计费指令）
- 每个工作流的工作流计划 — 所有必需列均在（参见步骤 6）
- RAID 日志开账条目
- 跨技能交接提示（参见"跨技能交接"部分）— 在每份计划产出的末尾以具名部分产出："Next Steps — Cross-Skill Handoffs"
- 结构化数据导出（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 进行实时跟踪
无连接器时：通过粘贴文本或直接上传文件提供范围摘要、先前计划和相关往来函件。
