| name | timeline-generator-scott-margetts |
| description | 从事项计划构建依赖网络和关键路径。生成交互式甘特图，标记接近关键的任务，并在发生延误时运行假设级联情景——展示项目影响并起草沟通函。为当地律师生成过滤后的工作流或法域视图。触发词：'build a timeline'、'Gantt chart'、'critical path'、'what if X is delayed'、'what moves if'、'schedule impact'、'how does this affect the programme'、'when do we finish'、'can we still close on time'、'if we miss this deadline'、'run a what-if'、'visualise the plan'、'Germany timeline'、'what does the Employment workstream look like'、'timeline for local counsel'、'just show me the [workstream] tasks'。 |
| metadata | {"author":"Scott Margetts","license":"Apache-2.0","version":"2026.03.17"} |
时间线生成器
目的
将带依赖标签的任务列表转换为带关键路径分析的视觉时间线。识别哪些任务必须按时完成，事项才能按计划收官。在延误发生前对其进行建模——或在发生后计算其对项目层面的影响。
假设级联是核心能力。当一个法域延误、监管决定时间过长或相对方陷入沉默时，问题不仅是"这个任务是否晚了"，而是"该任务下游的二十三件事中哪些现在要移动、移动多少、客户需要知道什么？"本技能产生这个答案，连同沟通函草稿。
本技能消费 matter-plan-builder 的结构化输出，并将其结果作为更新的里程碑日期回馈给 status-report-drafter 和 scope-change-controller。它位于 LPM 插件的技术中心：每个其他技能要么产生时间线数据，要么消费时间线数据；本技能拥有计算层。
操作模式
模式 1——基线构建
在事项设立时：从事项计划构建依赖网络，计算关键路径和接近关键的路径，生成甘特图和依赖摘要。这是所有未来报告衡量的时间基线。
输入：matter-plan-builder 结构化导出（CSV）或粘贴的带依赖标签的任务表。最低可行输入：任务 ID、工期（工作日）、前置任务、依赖类型（FS/FF/SS），以及至少一个固定日期锚点。
**正向排程与反向排程：**如果项目开始日期已知但没有固定结束日期，正向排程——从 ES 计算 EF。如果客户完成截止日期是固定的（法律工作中更常见的情景），反向排程——将完成日期视为最终任务的 LF，并沿网络反向推导每个任务所需的开始日期。标记正在使用哪种模式及原因。反向排程的计划立即揭示可用时间是否充足：如果第一个任务的计算开始日期已过去，项目在开始之前就已处于赤字状态。
模式 2——假设分析
在事项期间的任何时间点：提出变更并获得完整的级联影响分析。"德国律师现在说 12 周而非 10 周"→ 本技能计算哪些任务移动、哪些里程碑延误、关键路径是否改变以及新的项目完成日期是什么。生成客户通知草稿和受影响的当地律师沟通函。
输入：现有基线（上传或粘贴）+ 以平实语言描述的拟议变更，或从邮件中提取的变更。
模式 3——基线更新
应用已确认的变更：更新时间线，为其设定版本，生成对比表（所有受影响任务的原定日期与修订日期），并触发向 status-report-drafter 和 scope-change-controller 的跨技能交接。
输入：现有基线 + 已确认的变更。输出：带版本的更新基线、对比表、交接提示。
模式 4——工作流或法域视图
从完整项目基线中为单个工作流或法域生成过滤后的甘特图和时间线摘要。当当地律师需要自己的时间线而不需要完整项目时、当合伙人要求单个工作流更新时、或当为某个不应暴露项目级信息的团队准备沟通时使用。
输入：完整基线（或相关子集）+ 要过滤的工作流或法域。
模式 4 输出中出现三类任务：
-
范围内的任务——属于指定工作流或法域的任务。显示为正常彩色横条（关键路径红色、非关键绿色）。浮动值继承自完整网络——不在子集上重新计算。
-
上游约束——其他工作流中作为范围内任务硬性前置任务的任务。显示为标注"[外部——约束 [任务 ID]]"的灰色横条。接收者需要看到这些才能理解为什么他们的任务有这样的日期，但不应被误导认为这些是他们的责任。
-
下游里程碑——范围内任务所供给的项目里程碑。显示为标注"[项目里程碑——[描述]]"的里程碑菱形。这些让接收者看到他们的工作门控着什么，而无需暴露完整的下游网络。
**浮动值必须继承自完整网络计算，而非在子集上重新计算。**在完整项目中有 0 天浮动的德国注册任务在德国视图中也有 0 天浮动。如果仅对德国子集重新计算浮动，在完整网络中关键的任务会显得有浮动——那是错误的且可能危险。始终先针对完整基线计算，然后过滤。
开始任何模式之前
在运行任何计算之前确认以下事项：
- 项目开始日期——计算工期的起始日期。如果未提供，询问。
- 固定外部日期——任何不能移动的日期：监管申报截止日期、合同完成日期、法院日期、财年末日期、客户董事会批准窗口。这些是约束，不是估算。明确标记它们——关键路径上的固定日期完全改变计算。
- 工期单位——确认工期是工作日（周一至周五，默认）还是日历日。绝不猜测。
- 工作日历例外——标记任何工作周不标准的法域（如中东周五周六周末、节假日密集期）。不考虑当地日历的工期估算从第一天起就是错的。
- 滞后/提前值——前置任务完成后后继任务开始前有等待期（滞后：正天数），或后继任务可以在前置任务完成前开始（提前：负天数）。法律工作中常见："提交监管申报 → 后继任务可以继续前有 6 周决定窗口"是 FS 依赖上的 30 个工作日滞后。
**监管滞后需要澄清和三情景建模：**当滞后代表外部决定窗口时，确认它是 (a) 硬性最低值——无论情况如何主管机构都不可能在此期限前决定，还是 (b) 预期时长——典型的决定期限，可能更短或更长。
对于预期时长，生成三个情景作为命名输出——不要只在散文中注明风险：
- **最佳情况：**最低可信决定期限
- **预期：**所述时长
- **+50%：**预期时长 × 1.5
显示每个情景下的项目完成日期。这是 LPM 在窗口开启前与客户进行截止日期风险对话所需的分析。如果 LPM 无法确认滞后属于哪种类型，按预期时长建模，生成全部三个情景，并明确标记该假设。
如果关键输入缺失，停下来询问。不要针对不完整的网络计算——输出会看起来精确而实际错误。
分步流程
步骤 1：构建依赖网络
按拓扑顺序列出所有任务——前置任务总是出现在后继任务之前。识别：
- **网络开始任务：**没有前置任务（或没有范围内前置任务）的任务
- **网络结束任务：**没有后继任务的任务——其完成日期即项目完成日期的里程碑或任务
- **依赖边：**为每个任务记录其前置任务和依赖类型（FS/FF/SS）以及任何滞后/提前值
**滞后惯例：**滞后从前置任务 EF 后的下一个工作日向前计算。FS 滞后 5 个工作日，从 EF 为 5 月 7 日周三起算 → 后继 ES = 5 月 14 日周三（8、9、12、13、14 = 5 个工作日）。第零天是 EF 后的那一天，而非 EF 本身。一致地应用这一点——滞后惯例的一天错误会传播到同一条路径上的每个下游任务。
立即标记循环依赖——它们是数据错误并阻止计算。循环依赖意味着任务 A 依赖任务 B 且任务 B 依赖任务 A。它们最常见于任务的前置任务被错误地输入为后继任务时。
如果输入包含没有自己任务行的资源或信息依赖（来自 matter-plan-builder 的依赖登记册），将其作为 FS 关系上的显式滞后值添加——不要静默省略。
步骤 2：正向遍历——计算最早开始和最早完成
按拓扑顺序遍历任务。为每个任务计算：
- **ES（最早开始）：**给定其前置任务，任务可以开始的最早日期
- **EF（最早完成）：**ES + 工期（以工作日计，按周末和标记的日历例外调整）
按依赖类型：
- **FF（完成-完成）：**后继 EF ≥ 前置 EF + 滞后。后继在完成前不能结束。两个任务并行运行；约束控制完成端，而非开始端。这是多法域执行工作中的主导依赖类型——两个并行工作流在受控的顺序点汇合。示例：股息决议周一完成；股份转让必须在周四前完成。两者全程并行运行；FF+3d 滞后控制转让何时可以结束。如果股息决议延误，股份转让延误相同量——即使两者同时开始。
- **FS（完成-开始）：**后继 ES = 前置 EF + 滞后。后继在前置完成前不能开始。这是硬性法律顺序要求的依赖类型——德国实体注册必须完成，荷兰解散才能开始；不可能并行执行。也带滞后用于监管窗口：提交申报 → [30 个工作日滞后] → 收到决定 → 后继任务开始。
- **SS（开始-开始）：**后继 ES ≥ 前置 ES + 滞后。后继在前置开始前不能开始。用于两个工作流必须按协调顺序启动但之后可以独立进行时。
当一个任务有多个前置任务时，其 ES 由最晚完成的前置任务决定（对于 FS/SS），或由跨所有依赖类型最具约束性的关系决定。独立应用每个前置约束并取最大值。
显示关键路径任务以及约束不明显任务的的正向遍历计算。透明建立对输出的信任——不要在不显示日期如何推导的情况下呈现日期。
步骤 3：反向遍历——计算最晚开始和最晚完成
从项目结束日期反向工作。结束日期要么是固定约束（如果在设置检查中识别到），要么是网络中最后一个任务的 EF。
为每个任务计算：
- **LF（最晚完成）：**不延误项目的情况下任务可以完成的最晚日期
- **LS（最晚开始）：**LF - 工期
按依赖类型（反向遍历）：
- **FF：**前置 LF = 跨所有后继取 min(后继 LF - 滞后)
- **FS：**前置 LF = 跨所有后继取 min(后继 LS - 滞后)
- **SS：**前置 LS = 跨所有后继取 min(后继 LS - 滞后)
当一个任务供给多个后继时，其 LF 受最早要求的后继约束。取最小值。
步骤 4：计算浮动并识别关键路径
为每个任务：
总浮动 = LS − ES = LF − EF
浮动是一个任务拥有的进度灵活性。有 10 天浮动的任务可以延误最多 10 天而不延误项目完成日期——假设其后继任务尚未消耗该浮动。
**零浮动 = 关键路径。**任务必须在其最早完成日期完成，以避免延误项目。零浮动不意味着任务晚了——意味着它没有缓冲。
**负浮动 = 已经晚了。**即使最早开始，任务也无法在其最晚完成日期前完成。当固定截止约束比网络允许的更紧时发生。负浮动是项目层面需要立即上报的问题——它无法通过更好的排程解决。标记每个有负浮动的任务、指明造成它的约束并量化差距。"T04 有 -8 天浮动：项目要求在 6 月 30 日前完成，但网络产生的 EF 为 7 月 12 日。关键路径上需要压缩 8 个工作日。"
所有任务都在关键路径上在无并行路径的小型线性事项上是有效且预期的结果。这意味着网络任何地方都没有浮动——每个任务都必须按时完成。明确注明这一点："所有任务都位于关键路径上。网络没有可提供浮动的并行路径。该计划没有任何进度灵活性。"
**接近关键路径：**浮动 ≤ 接近关键阈值的任务。默认阈值：5 个工作日。阈值可配置——快速推进的事项可能用 3 天；长期项目可能用 10 天。在生成接近关键报告前请 LPM 确认或接受默认值。表述为："以下任务的浮动在距关键路径 [阈值] 个工作日内，值得主动监控：[带浮动值的列表]。"
如果关键路径穿过工期为信息依赖（监管决定、相对方响应）的任务，明确标记这一点："项目完成取决于 [外部事件]。LPM 对该工期没有控制权。围绕最小/预期/最大区间制定应急计划。"
步骤 5：生成基线输出
见输出格式部分。按顺序生成：甘特图、关键路径叙述、接近关键任务表、依赖摘要、开放式计算假设。
步骤 6：假设级联（仅模式 2）
见假设级联协议部分。
步骤 7：更新和版本化（仅模式 3）
将已确认的变更应用到基线。递增版本号。生成对比表。触发跨技能交接。
步骤 8：生成工作流或法域视图（仅模式 4）
- 先针对完整基线运行完整网络计算（步骤 1-4）。浮动值必须来自此完整计算。
- 识别过滤器：请求了哪个工作流或法域？
- 将每个任务分类为：范围内 / 上游约束 / 下游里程碑（见上文模式 4 定义）。
- 生成显示全部三个类别且视觉处理不同的过滤后甘特图。
- 为接收者生成平实语言摘要："您的工作流有 [X] 个任务。您可以最早在 [日期] 开始 [任务 Y]——这由 [上游约束任务] 门控。您的工作在 [日期] 供给 [项目里程碑]。您的任务在完整项目中有 [Z] 天浮动。"
- 明确注明未显示的内容："本视图仅涵盖 [德国] 工作流。另有 [X] 个工作流并行运行，此处未显示。"
关键路径方法论——核心概念
为什么关键路径在法律工作中很重要：
关键路径不是排程好奇——它是"我实际需要管理什么？"的答案。每个事项都有可以延误而无后果的任务，也有延误一天项目就延误一天的任务。经验丰富的 LPM 会发展出直觉性的关键路径知识。本技能将其显式化，服务两个目的：它在 LPM 离职后仍然存在，并在需要向客户沟通延误时产生可辩护的项目影响评估。
工作量与工期：
工期是完成任务的流逝时间。工作量是投入的人时数。只要有等待，两者就分道扬镳。一个两小时的合伙人审查在收件箱里放了三天才完成，其工期是三天、工作量是两小时。在法律工作中，等待期经常比工作期长——审查周期、审批队列、监管窗口。排程必须基于工期而非工作量。基于工作量的排程通过系统性地忽略等待而低估工期。
滞后与监管窗口模式：
跨境法律工作中最常见的关键路径驱动因素是监管窗口——工作已提交给外部机构而律所在等待决定的时期。这建模为带等于预期决定期限的滞后的 FS 依赖。难点在于这个滞后是不确定的。将其建模为：(a) 预期情况、(b) +2 周、(c) +4 周。假设级联自动处理这一点——这是模式 2 的主要用例。
浮动不是松弛：
浮动属于路径，而非任务。如果任务 A 有 10 天浮动并供给同样有 10 天浮动的任务 B，而任务 A 用完了所有浮动，任务 B 就没有剩余浮动。上游任务消耗的浮动对同一条路径上的所有下游任务消失。这就是为什么"非关键任务"上的延误仍然可以移动项目完成——该任务在计划时不是关键的，但消耗了其他任务依赖的浮动。
接近关键处是监控投入的去处：
关键路径被管理。接近关键的任务是惊喜的来源——看似有缓冲、渐进延误、在无人注意时到达零浮动的任务。在每次状态会上审查的接近关键监控报告，比每月一次只会在损害已造成后才浮出问题的关键路径报告更有价值。
领域知识——法律排程模式
FF 作为并行工作流中的主要执行依赖：
当多个工作流并行运行并必须在受控的顺序点汇合时，FF+滞后是正确的依赖类型——而非 FS。FS 会强制一个任务完全等待另一个完成才能开始，丧失并行执行的好处。FF 允许两者同时运行，同时在完成端强制所需的顺序。
典型示例：股息决议必须在周一通过；相关股份转让必须在周四前完成。两个任务从周初并行运行。依赖不是"转让等待决议完成才开始"（FS）——两者同时进行。依赖是"转让在决议通过 3 个工作日后才能结束"（FF，滞后 = 3 个工作日）。
这种模式在多法域公司工作中反复出现，只要并行工作流必须以定义顺序汇合：并行实体准备在集团级签署汇合；并行监管申报在合并决定汇合；并行尽调工作流在合并报告汇合。在每种情况下，任务一起或接近一起开始——约束在结束端，而非开始端。将这些建模为 FF+滞后，而非 FS。
法域依赖链（公司重组）——FS：
多法域重组有由法律顺序而非资源可用性决定的结构性关键路径。德国必须先于荷兰完成，因为荷兰实体在德国母公司关系注册前不能解散。新加坡必须先于香港完成，因为控股公司顺序。这些是硬性 FS 依赖——不可能并行执行，因为下游步骤的法律有效性取决于上游步骤完成。重组中的关键路径不是最长的任务序列——它是法域链的法律完成顺序。
签署和执行窗口：
实体签署物流施加任务列表中没有的排程约束：湿墨签名要求、公证周转时间（每法域 3-10 个工作日）、快递送达窗口、登记处排队时间。这些不是工期——它们是固定的日历事件。将其建模为带固定日期的里程碑，而非带估算工期的任务。在一个法域错过登记处队列一天的完成，如果下一个登记时段是每月的，可能产生三周影响。
相对方沉默模式：
对相对方的信息依赖行为与监管窗口不同。监管窗口有已知的最小和预期时长。相对方沉默是无界的，且经常先于实质性问题的出现。将相对方响应窗口建模为：预期（约定的审查期）、+50%（现实的延误）和上报触发点（LPM 上报的时刻）。假设级联应始终包含上报触发情景。
赶工和快速推进：
当基线显示的项目结束日期不满足客户截止日期时，有两个压缩杠杆可用：(a) 赶工——增加资源以缩短关键路径任务工期；(b) 快速推进——在不会产生返工的情况下将 FS 依赖转换为 FF 或 SS。快速推进在法律工作中风险很大，因为许多 FS 关系是硬性法律顺序要求，而非排程偏好。将法律顺序 FS 转换为 FF 不会使下游工作在法律上有效——它产生错误而非节省。明确标记哪些依赖可以转换（排程偏好）、哪些不能（法律要求）。
领域知识——常见排程失败
**构建了排程但没有构建网络。**带日期的任务列表不是排程——是愿望清单。本技能的价值在于依赖网络。从依赖逻辑推导的日期是可辩护的；作为偏好输入的日期不是。
**遗漏关键路径上的监管窗口。**监管决定期限经常从任务网络中被省略，因为它们不是"律所工作"——等待期间无事可做。它们必须作为滞后值或占位任务出现在网络中，因为它们决定后继任务何时可以开始。关键路径上未建模的 6 周监管窗口产生的项目计划比现实短 6 周。
**将所有浮动视为可用。**见上文"浮动不是松弛"原则。报告"该任务有 10 天浮动"而不追踪其中多少已被上游延误消耗是不正确且误导的。
**在已确认变更后不重置基线。**延误确认后，基线必须更新并版本化。继续针对过时基线报告会产生虚假差异——任务看起来落后于计划，因为它们落后于旧计划，而旧计划不再反映约定的项目。模式 3 的存在就是为了强制这种纪律。
**不知道关键路径会变化。**在长期事项上，关键路径随任务完成和延误累积而转移。第 1 个月接近关键的任务在第 4 个月可能在关键路径上。关键路径计算必须在每次确认变更后重新运行——而不仅仅在基线时。
**投入的是工作量，产出的是工期。**分配给一个同时在另外四个事项上的合伙人的任务，在客户差旅占掉两天的那个星期，其有效工期与分配给专职全职资源的任务不同。工期估算应反映现实，而非理论生产力。当已知资源是共享的时，标记那些假设全职可用性的工期估算。
假设级联协议
这是本技能产生的最高价值输出。运行良好的假设级联将单个拟议变更转换为平实英语的项目层面影响分析——LPM 管理客户对话所需的沟通资产。
步骤 1：识别拟议变更
什么在变化？哪个任务或依赖受影响？变化多少？表述为："[任务 ID] 工期从 [X] 增加到 [Y] 个工作日"或"[任务 A 和任务 B 之间的依赖] 滞后从 [X] 增加到 [Y] 个工作日。"
步骤 2：从受影响任务开始正向重新计算
将更新的工期或滞后应用到受影响任务。使用依赖类型通过所有后继任务正向重新计算 ES/EF。不要反向重新计算——那是单独的步骤。
步骤 3：识别所有受影响的任务
如果任务的 ES 或 EF 因拟议变更而改变，则该任务受影响。记录：任务 ID、原 EF、修订 EF、移动天数。
步骤 4：识别受影响的里程碑
哪些里程碑的前置任务在受影响集合中？记录：里程碑、原目标日期、修订目标日期、移动天数。里程碑是客户沟通的语言——任务层面的影响不如里程碑层面的影响重要。
步骤 5：关键路径分析
关键路径改变了吗？拟议变更是否将先前非关键的任务带上关键路径？识别任何因变更而浮动降至零或以下的接近关键任务。
步骤 6：项目完成影响
项目结束日期改变了吗？改变多少？表述为："项目完成从 [日期 A] 移动到 [日期 B]——延误 [X] 个工作日 / [Y] 个日历周。"
步骤 7：生成级联影响表——必需输出，非可选
每个模式 2 和模式 3 输出都必须包含此表。不要用散文分析替代结构化表格——两者都生成。表格是交付物；散文是评注。
| 任务 / 里程碑 | 原定日期 | 修订日期 | 移动天数 | CP 状态 | 工作流 |
CP 状态值：新关键 / 仍关键 / 现为接近关键 / 未变化。按移动天数降序排序。用单独的行标记里程碑。此列是主要管理信号——它告诉 LPM 变更后应将监控注意力转向何处，而不仅仅是移动了多少。
版本历史条目（模式 3 必需）：
每次基线更新必须包含版本历史条目："v[X.Y] — [日期]：[变更原因]。影响：[项目完成移动]。来源：[邮件/文档引用、发件人、日期]。"作为命名部分生成："时间线版本历史"。
**版本约定：**进度调整用小幅递增（v1.0 → v1.1 → v1.2）——工期变更、滞后更新、日期修订——计划结构未变时。仅对结构性变更使用大幅递增（v1.0 → v2.0）：添加新阶段、移除工作流、依赖网络重组。德国注册工期变更是 v1.1，而非 v2.0。
对比表（模式 3）：
对比表仅列出变更的任务和里程碑。未变更的任务被省略——显示 40 行"未变化"会掩盖实际变更。按移动天数降序排序。以汇总行结束："[X] 个任务和 [Y] 个里程碑受影响。项目完成移动 [+/- Z 个工作日]。"
按移动天数降序排序。单独标记里程碑。突出显示因变更而变得关键的任务。
步骤 8：起草沟通函
两个输出：
- 客户通知草稿："我们写信向您更新影响 [事项] 的排程进展。[以中性措辞说明延误原因]。以下里程碑现目标为 [修订日期]。我们正在 [为缓解已采取的行动 / 确认无缓解措施可用]。如您希望讨论，请告知。"
- 受影响的当地律师通知草稿（如适用）："请注意影响您工作流的项目时间线变更。[对其任务的具体影响]。请确认 [任何所需响应 / 调整后的截止日期]。"
将两者标记为草稿——任何客户沟通发出前由合伙人审查。
步骤 9：提供恢复选项
呈现级联影响后，提供建模恢复情景。不要静默建模——由 LPM 和合伙人决定是否追求压缩。询问："您希望我建模恢复选项吗？本事项可用的方法：(a) [赶工特定任务——点名任务及资源影响]；(b) [快速推进——在可以真正重叠的情况下将 [特定 FS 依赖] 转换为 SS 或 FF]；(c) [将 [特定下游任务] 推迟到后期阶段——作为范围信号标记给 scope-change-controller]。对于每个选项，我可以计算修订后的项目完成日期及其所需条件。"
标记每个选项是否真正可用：并非所有 FS 依赖都能转换，并非所有任务都能在不产生返工风险的情况下增配资源。不要将赶工或快速推进作为选项提供，如果依赖是法律顺序要求而非排程偏好。
输出格式
所有输出生成为 .docx，除非用户明确要求其他格式。这些是事项记录——它们属于事项文件夹。
每个输出都包含标识块。如果客户名称、事项名称或事项编号尚未提供，在生成输出前停下来询问——不要静默使用占位符继续：
Client: [Name] Client number: [Number]
Matter: [Name] Matter number: [Number]
Timeline version: [v1.0] Calculated by: [LPM name] Date: [Date]
**必需：为每个模式 1、2 和 3 输出生成交互式 HTML 画布甘特图。**这是主要视觉输出——不是可选的、不是按需的。不要生成文本表格作为视觉输出。不要将 Mermaid 作为默认。使用 HTML 画布内联渲染甘特图。如果渲染失败，明确注明失败并生成文本表格作为回退——不要静默替换。
HTML 甘特图必须包括：
- 颜色编码的任务横条：关键路径红色（#E24B4A）、非关键绿色（#1D9E75）、监管/外部等待期虚线灰色横条
- 浮动显示为任务横条之外的淡化延伸，并标注浮动天数数值
- FF 依赖显示为连接两个并行任务完成点的括号，滞后值在胶囊标签中——而非箭头
- FS 依赖显示为横条端和开始之间的方向箭头
- 里程碑菱形位于项目完成点和阶段门禁处
- 带工作周数和日历日期的水平轴
- 甘特图上方摘要指标：开始日期、完成日期、关键路径工期
- 当监管窗口或相对方延误位于关键路径上时提供假设滑块
要导出到状态报告或客户演示文稿：对渲染的甘特图截图。正确渲染的 HTML 甘特图的截图优于任何在 PowerPoint 或 Excel 中原生构建的内容。
回退——Mermaid gantt：
仅在用户明确要求轻量输出以粘贴到文档中，或事项少于 8 个任务时使用。在依赖摘要表中注明 FF/SS 关系——Mermaid 原生只渲染 FS。
gantt
title [Matter Name] — Timeline v[X]
dateFormat YYYY-MM-DD
excludes weekends
section [Workstream Name]
[Task summary] :crit, [id], [start-date], [duration]d
[Milestone] :milestone, [id], [date], 0d
关键路径叙述：
"关键路径为：[任务 A] → [任务 B] → [里程碑 X] → [任务 C] → [项目结束]。项目完成：[日期]。关键路径工期：[X] 个工作日。"
接近关键任务表：
| 任务 ID | 任务摘要 | 工作流 | 浮动（工作日） | 有风险的前置任务 |
级联影响表（模式 2/3）：
| 任务 / 里程碑 | 原定日期 | 修订日期 | 移动天数 | CP 状态 | 工作流 |
CP 状态值：新关键（任务移动到关键路径上）、仍关键、现为接近关键（任务移出关键路径进入接近关键区间）、未变化。状态变化列是管理信号——它告诉 LPM 将监控注意力转向何处，而不仅仅是移动了多少。
工作流视图输出（模式 4）：
过滤后的甘特图使用三种不同的视觉处理：
- 范围内任务：正常彩色横条（红色 = 关键路径、绿色 = 非关键），显示浮动延伸
- 上游约束：灰色横条，标注"[外部约束——门控 [任务 ID]]"
- 下游里程碑：菱形，标注"[项目里程碑——[描述]]"
过滤输出上的页眉："[工作流/法域] 视图——从完整项目基线 v[X.Y] 提取。浮动值反映在完整项目网络中的位置，而非仅此视图。另有 [X] 个工作流未显示。"
不要为工作流视图生成关键路径叙述——关键路径是完整网络的属性，而非过滤子集。改为生成："您的工作流摘要：[X] 个任务、最早开始 [日期]、在 [日期] 供给项目里程碑 [描述]、完整项目中 [Y] 天浮动。"
结构化数据导出：
每个时间线输出附有 CSV 导出，包含所有任务及其计算的 ES、EF、LS、LF、浮动和关键路径标记。这是排程软件或 SharePoint 跟踪的输入格式。如果无法附加文件，作为带标签的内联部分生成。
计算假设（必需）：
每个输出必须以命名部分"计算假设"结束。列出：应用的工作日历、任何标记为不确定的工期估算、任何带假设滞后值的信息依赖、任何覆盖计算的约束（固定日期）。未记录的假设无法被质疑，也无法在情况变化时更新。
跨技能交接
- **来自 matter-plan-builder：**带依赖标签的任务和里程碑列表（模式 2/3 结构化导出）是主要输入。直接消费 13 字段任务模式——不要将其转述为散文。matter-plan-builder 交接提示应为："从该计划构建依赖网络和关键路径。"
- **到 risk-and-issues-manager：**当模式 2 或 3 的变更确认延误时，将其作为问题记录到 RAID 日志中（已确认，而非风险）。另外，如果延误由可能可压缩的假设驱动（如流程假设滞后而非监管要求），将其作为风险记录，以压缩问题作为审查触发。附言："德国注册延误已确认——记录为问题。FF 滞后假设可能可压缩——记录为风险，待律师确认。"
- **到 status-report-drafter：**修订后的里程碑日期和关键路径状态是报告基线。当模式 2 或 3 输出更改里程碑日期时，将更新的里程碑登记册传递给 status-report-drafter，附言："更新里程碑报告基线——修订日期如下。"
- **到 scope-change-controller：**如果模式 2 假设分析揭示工作范围必须变更（添加阶段、放弃法域、推迟工作）以恢复项目，将其标记为范围信号。附言："拟议的项目恢复涉及范围变更——scope-change-controller 应评估 OOS 影响。"
- **到 matter-plan-builder：**如果模式 2 分析确认计划结构必须变更（添加新任务、重组工作流），触发模式 5 计划更新。附言："级联分析确认这些计划变更——matter-plan-builder 模式 5 应用。"
- **到 stakeholder-comms-planner：**模式 2 级联的修订里程碑日期和沟通函草稿。沟通规划器处理路由和时间安排；本技能起草内容。
- **来自 risk-and-issues-manager：**当 RAID 日志中的假设被违反时——特别是对监管机构或相对方的信息依赖——那是模式 2 触发条件。传递带假设违反标记的 RAID 条目。
**具名律所归属规则：**绝不在技能输出的任何地方引用具名律所——无论是在文档、表格还是对话文本中。这包括将费率、政策、实务或组织结构归属于任何具名律所。本技能不知道任何律所的实际结构、费率或政策。使用"与 Pricing 确认"、"与 Finance 确认"或"律所政策——应用前确认"。此规则适用于本技能产生的一切，而不仅仅是正式文档。
M365 连接模式（可选）
**连接模式调用规则：**当搜索连接系统（Outlook、SharePoint、Teams）能增加价值时进行搜索——当提示中已有足够输入时，不作为默认第一步。
- **已提供足够输入：**用户粘贴了带完整上下文的邮件、文档或数据。就现有内容工作。不要先搜索——它增加摩擦而不增加信息。
- **输入不完整或主动呈现合理：**用户提到应检索的内容（"Outlook 里有发票"、"现在是月底"），或连接模式以后台/定时模式运行。主动搜索——这是倒置的调用模型，是最高价值的连接模式行为。
区别在于用户是否已提供所需内容。如果已提供，就使用它。如果未提供，或主动呈现为 LPM 服务，则搜索。
启用 M365 MCP 连接器（Claude Team/Enterprise）时，本技能可以：
- 直接从 SharePoint 拉取已批准的事项计划（matter-plan-builder 产生的结构化导出），无需 LPM 上传
- 搜索 Outlook 中预示时间线变化的法域更新——标记对方提及延误、修订时间线或重新安排行动的邮件作为模式 2 触发条件
- 模式 3 基线更新确认时，在 SharePoint List 或 Planner 中更新里程碑日期
- 为里程碑到期日和阶段门禁审查创建或更新日历提醒
- 在 Outlook 草稿模式下起草客户通知和当地律师沟通函供合伙人审查
没有连接器时：上传 matter-plan-builder CSV 导出、粘贴相关邮件文本，并直接在聊天中确认变更。
