integration-management

name	integration-management
description	交割后并购整合追踪器——分阶段工作计划、同意追踪、规模化合同转让、 每周状态报告。从任何可获取的交易工件（股权收购协议、交易摘要、 交割检查表）初始化，并连接到来自并购冷启动的 deal-context.md 和 closing-checklist.yaml。当用户说"整合""交割后""同意未决" "合同转让""整合状态"或"交易还差什么"时使用。
argument-hint	[--init | --contracts | --report | --update | --export [--format csv|table] [--section all|consents|contracts|workplan]] [--deal [代码]]

/integration-management

1. 加载 deal-context.md 获取交易代码、目标公司、交割日期、交易负责人。
2. 加载 integration-tracker.yaml（如存在；或通过 --init 创建）。
3. 使用以下工作流。
4. 按标志路由：
   • --init：模式1——读取收购协议，构建分阶段工作计划、同意追踪器
   • --contracts：模式2——导入合同清单（存储库或上传），分层和分类
   • --report：模式3——生成状态报告
   • --update：模式4——手动更新或解析上传的状态文件
   • --export：模式5——CSV 或表格导出
5. 读取/写入 ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[代码]/integration-tracker.yaml。
6. 任何写入后：展示变更摘要并呈现任何新标记。

---

事项上下文

事项上下文。 检查实务级 CLAUDE.md 中的 ## 事项工作区。如果 Enabled 为 ✗（企业法务用户的默认值），跳过本段其余内容——技能使用实务级上下文，事项机制不可见。如果已启用且无活跃事项，询问："这是哪个事项？运行 /corporate-legal:matter-workspace switch <事项简称> 或说 实务级。"加载活跃事项的 matter.md 获取事项特定上下文和覆盖规则。输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<事项简称>/。除非 跨事项上下文 为 开，否则绝不读取其他事项的文件。

---

目的

外部律师交割交易。法务继承混乱。本技能是交割后整合的项目管理层——不是业务整合，不是IT系统，不是HR组织设计。是法律工作流：同意事项、合同转让、主体合理化、知识产权登记、股权收购协议义务。它追踪什么已完成、什么待到期、什么在受阻以及什么需要决策。

---

追踪器文件

存放于 ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[代码]/integration-tracker.yaml。读取 deal-context.md 获取交易代码、目标公司名称、交割日期和交易负责人。从 closing-checklist.yaml（如存在）继承任何交割后项目。

# integration-tracker.yaml

metadata:
  deal_code: "[代码]"
  target: "[公司名称]"
  close_date: "[YYYY-MM-DD]"
  deal_lead: "[姓名]"
  outside_counsel: "[律所和牵头律师]"
  last_updated: "[日期]"
  last_status_report: "[日期 或 空]"

pa_dates:
  required_consents_deadline: "[YYYY-MM-DD — 从收购协议中提取]"
  rep_survival_expires: "[YYYY-MM-DD]"
  escrow_release: "[YYYY-MM-DD 或 空]"
  earnout_milestones:
    - description: "[里程碑]"
      measurement_date: "[YYYY-MM-DD]"
      payment_date: "[YYYY-MM-DD]"
      owner: "finance"   # 始终为财务——法务仅追踪日期

workplan:
  day_1:
    target_date: "[close_date + 7天]"
    items: []
  day_30:
    target_date: "[close_date + 30天]"
    items: []
  day_90:
    target_date: "[close_date + 90天]"
    items: []
  day_180:
    target_date: "[close_date + 180天]"
    items: []

required_consents: []
desired_consents: []

contracts:
  source: "[存储库 / manual-upload / disclosure-schedule]"
  repository_path: "[路径 或 空]"
  last_imported: "[日期]"
  total: 0
  tier_1: []
  tier_2: []
  tier_3: []
  tier_4: []

工作计划项结构：

- id: "W-001"
  description: "[行动事项]"
  phase: "[day_1 / day_30 / day_90 / day_180]"
  owner: "[法务负责 / 法务支持]"
  workstream: "[法务 / 人力 / 信息技术 / 财务 / 不动产 / 其他]"
  priority: "[关键 / 高 / 中 / 低]"
  deadline: "[YYYY-MM-DD 或 空]"
  deadline_basis: "[收购协议义务 / 监管要求 / 最佳实践]"
  status: "[未开始 / 进行中 / 已完成 / 受阻 / 推迟]"
  blocker: "[描述 或 空]"
  depends_on: "[项目 id 或 空]"
  notes: ""

同意项结构：

- id: "CON-001"
  counterparty: "[名称]"
  contract_type: "[客户 / 供应商 / 租赁 / 知识产权许可 / 金融/ 其他]"
  required_consent: true        # true = 在收购协议所需同意清单中列明
  pa_deadline: "[YYYY-MM-DD]"   # 仅对 required_consent: true
  status: "[未开始 / 已发出接洽 / 谈判中 / 已取得 / 已豁免 / 被拒绝]"
  assigned_to: "[姓名 或 空]"
  outreach_date: "[日期 或 空]"
  obtained_date: "[日期 或 空]"
  notes: ""

合同项结构：

- id: "C-001"
  name: "[合同名称或文件名]"
  counterparty: "[当事方名称]"
  contract_type: "[主协议 / SaaS / 租赁 / 知识产权许可 / 劳动/ 保密协议 / 其他]"
  annual_value: "[金额 或 未知]"
  assignment_mechanism: "[自动转让 / 需经同意 / 含控制权变更条款 / 未提及]"
  tier: 1   # 1=所需同意, 2=重大+需经同意, 3=控制权变更, 4=自动转让
  required_consent: false
  pa_deadline: "[YYYY-MM-DD 或 空]"
  status: "[未审查 / 无需行动 / 等待同意 / 接洽已发出 / 谈判中 / 同意已取得 / 转让已完成 / 已豁免 / 被拒绝 / 控制权变更已触发]"
  assigned_to: "[姓名 或 空]"
  notes: ""
  last_updated: "[日期]"

---

模式1：初始化

/corporate-legal:integration-management --init [--deal [代码]]

第1步：加载交易上下文

读取 ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[代码]/deal-context.md。如未找到：询问交易代号、目标公司、交割日期、交易负责人和外部律师。如 deal-context.md 不存在，写入。

读取 ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[代码]/closing-checklist.yaml（如存在）。任何标记为交割后的项目成为 Day 1 或 Day 30 工作计划项（从交割检查表继承状态）。

第2步：读取交易输入

一份完整的股权收购协议产生最完整的追踪器。 收购协议的所需同意清单和交割后承诺部分是硬截止日和法定义务的权威来源。但技能可从任何可获取的输入进行有用的初始化——部分输入产生一个律师填充的入门追踪器，而非空白页。

你有哪些交易工件可用？分享任何存在的：

理想： 股权收购协议（上传或已连接的文件路径）。我将读取交割后承诺、所需同意清单、存续期、托管条款和业绩对赌条款。

同样有用——分享任意组合：

• 交易摘要或条款清单（给我关键经济和时限）
• 来自外部律师的整合待办清单或交割后检查表
• 已有的工作计划或整合追踪器（我将导入并继续）
• 交割检查表——如由并购冷启动技能生成，我将自动从 ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[代码]/closing-checklist.yaml 继承
• 仅所需同意清单（如收购协议由外部律师持有）

如果你没有任何书面材料： 用通俗语言告诉我交易——谁被收购、何时交割、主要未决项是什么——我将从标准 Day 1/30/90/180 工作计划构建入门追踪器供你编辑。

提供什么改变什么：

输入	你获得什么
完整收购协议	完整工作计划 + 带截止日的所需同意 + 收购协议日期
收购协议 + 合同清单	完整追踪器 + 合同转让分层清单
交易摘要 / 待办清单	标准工作计划框架，所需同意为占位符
无	标准工作计划支架；律师填写同意和合同清单

追踪器设计为渐进构建——今天一个框架，随着更多信息可获而填充。

从收购协议提取：

所需同意清单：

• 每项同意：对方当事人名称、合同类型和合同约定的截止日。设为 required_consent: true 并填充 pa_deadline。

交割后义务：

• 将每项义务映射到工作计划项。基于截止日分配到正确的阶段。在 deadline_basis 中标记为收购协议义务。

关键日期：

• 所需同意截止日——从收购协议提取
• 陈述与保证存续到期——从收购协议提取具体的存续期。一般、基本和税务陈述通常有不同的存续期；分别提取收购协议定义的每项并分别记录。不假设默认值。
• 托管释放日期——从收购协议提取
• 任何业绩对赌评估和付款日期——添加到 pa_dates.earnout_milestones，owner 始终设为"finance"

第3步：构建分阶段工作计划

为每个阶段生成标准工作计划项。添加在第2步中提取的收购协议义务。从交割检查表继承的项目预填充。

Day 1 — 法务负责：

• 主体名称变更登记（如被收购主体正在更名）[优先级：关键]
• 银行账户签署人更新——向银行通知交割文件 [优先级：关键]
• 工商登记变更通知 [优先级：高]
• 关键知识产权转让执行——如任何知识产权转让在交割时被推迟 [优先级：关键]
• 域名及社交媒体账号转移 [优先级：高]
• 董事及高管保险——确认被收购主体董事的尾期保单已绑定 [优先级：关键]
• 按注册地要求向市场监督管理局发送所有权变更通知 [优先级：高]

Day 1 — 法务支持：

• 员工公告和沟通（人力负责，法务审阅）[优先级：关键]
• 福利首日覆盖确认（人力负责，法务就劳动法律问题提供建议）
• 客户沟通函（业务负责，法务审查准确性）

Day 30 — 法务负责：

• 所需同意初步推进——联系所有对方当事人，记录接洽 [优先级：关键]
• 知识产权转让登记至国家知识产权局（专利、商标）[优先级：高]
• 著作权转让备案 [优先级：中]
• 商标转让登记 [优先级：高]
• 重大合同审查——完成第1级和第2级合同转让分析 [优先级：高]
• 保险尾期保单最终确认 [优先级：高]

Day 30 — 法务支持：

• 数据迁移隐私审查（IT负责，法务就数据传输机制提供建议）
• 不动产租赁审查转让条款（设施负责，法务提供建议）

Day 90 — 法务负责：

• 所需同意截止日——所有所需同意必须已取得或已上报 [优先级：关键，截止日：pa_dates.required_consents_deadline]
• 主体合理化决策——建议保留分离/合并/注销 [优先级：高]
• 福利计划承继或终止文件 [优先级：高]
• 二次同意推进——剩余未决同意 [优先级：高]
• 第3级控制权变更合同解决 [优先级：关键]

Day 90 — 法务支持：

• 全面HR政策统一文件（人力负责，法务就劳动法律提供建议）

Day 180 — 法务负责：

• 主体合并登记——如合理化决策为合并 [优先级：高]
• 主体注销登记——如合理化决策为清盘 [优先级：高]
• 全面合同更替——需要收购方名称的合同 [优先级：高]
• 陈述与保证存续追踪——记录即将到期的日期 [优先级：中]

生成后展示摘要：

整合追踪器已初始化 — [交易代码] / [目标公司]

交割日期：[日期]
所需同意截止日：[日期]（距今 [N] 天）
陈述与保证存续到期：[日期]

工作计划项：[N]（[N] 法务负责，[N] 法务支持）
所需同意：[N]（来自收购协议清单）
意愿同意：[N]（来自尽调——无收购协议截止日）

合同转让：尚未导入——运行 --contracts 填充

下一步：运行 /corporate-legal:integration-management --contracts 导入
合同清单，然后运行 --report 查看首份状态摘要。

---

模式2：合同转让

/corporate-legal:integration-management --contracts [--deal [代码]]

这是专用的合同转让初始化。独立于主初始化，以便可独立运行和在合同清单变化时重新运行。

第1步：获取合同清单

两条路径——使用适用的任何一条：

路径A：已连接的存储库

你的合同存储库是否已连接？（云文档、飞书或交割后仍可访问的数据室？）

如果是：给我被收购公司合同的文件夹路径或文件夹名称。我将拉取存在什么文件，并逐份读取转让条款和对方当事人。

搜索已连接的存储库。对找到的每份文件：

• 提取文件名和文件路径
• 读取文件——识别：合同当事方（对方当事人名称）、合同类型（从标题或主旨判断）、转让条款文本、控制权变更条款文本（如有）以及年度金额（如有明述）。

路径B：手动清单上传

上传一份合同清单。这可以是：

• 收购协议披露清单中的重大合同清单
• 合同管理系统的 CSV 或 Excel 导出
• 手动准备的清单

最低必需列：合同名称、对方当事人。有帮助但可选的：合同类型、年度金额、转让条款文本。

读取上传的清单。对未提供转让条款文本的合同，将 assignment_mechanism 设为"未审查"并标记待跟进。

路径C：披露清单

如果既没有存储库也没有清单，从收购协议披露清单中读取重大合同清单（来自 --init 中上传的收购协议）。这给出最低必需清单——当事方和合同类型。转让条款将需人工审查。

第2步：确定转让机制

对每份合同，分类转让机制：

机制	定义	层级
需经同意	明确条款禁止未经对方当事人同意的转让	1 或 2
含控制权变更条款	控制权变更条款赋予对方当事人因交易触发的终止或同意权	3
自动转让	无限制，或明确允许转让给关联方或继承人	4
未提及	无转让条款——默认适用管辖法律。当合同对转让保持沉默时，研究管辖法律对合同转让的默认规则并引用控制性规定。标记由律师审查。	2
未审查	未能读取或定位转让条款	标记由人工审查

对在收购协议所需同意清单中标记的合同：无论转让机制如何分类，覆盖层级为1。

第3步：层级分配

层级1 — 所需同意：[N] 份合同
  在收购协议清单中列明，硬截止日 [日期]，必须取得同意

层级2 — 重大，需经同意：[N] 份合同
  存在转让限制，不在收购协议清单中
  建议时限：在 Day 90 内取得

层级3 — 控制权变更条款：[N] 份合同 ⚠️
  对方当事人拥有因交割触发的终止或同意权
  需采取行动：立即联系对方当事人——控制权变更可能已被触发

层级4 — 自动转让 / 无需行动：[N] 份合同
  自动转让或通过关联方/继承人条款转让
  仅追踪——无需接洽

未审查：[N] 份合同
  无法确定转让机制——需人工审查

单独显著展示层级3。控制权变更条款可能已在交割日触发——对方当事人可能拥有正在运行的终止权。

第4步：生成状态项

对每份合同，创建追踪器条目：

• 所有已提取字段（对方当事人、类型、金额、机制、层级）
• 初始状态：层级4 → 无需行动；层级3 → 控制权变更已触发；层级1/2 → 等待同意；未审查 → 未审查
• 对层级1从所需同意清单填充 pa_deadline

---

模式3：状态报告

/corporate-legal:integration-management --report [--deal [代码]]

读取当前追踪器状态。产出：

[工作成果页眉 — 按插件配置 ## 输出规范 — 因角色而异；参见 `## 使用者`]

> 本状态报告来源于股权收购协议、尽调发现和交割后整合记录。它继承其特权和保密状态——向特权保护圈之外分发可能放弃特权。发送前确认接收方名单。

整合状态 — [交易代码] / [目标公司]
[日期] — 交割后第 [N] 天

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

执行摘要
[2-3句段落：整体状态、最大风险、自上次报告以来的关键进展]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

所需同意  [截止日：日期 — 剩余 N 天]
  已取得：       [N] / [总计]  ████████░░  [%]
  谈判中：       [N]
  接洽已发出：   [N]
  未开始：       [N]
  被拒绝：       [N] ⚠️

⚠️ 有风险：[对方当事人] — [N] 天后截止日，接洽无回应
⚠️ 被拒绝：[对方当事人] — 收购协议义务未满足；上报至外部律师

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

合同转让
  层级1（所需同意）：     [N] 完成 / [N] 进行中 / [N] 待处理
  层级2（重大合同）：     [N] 完成 / [N] 进行中 / [N] 待处理
  层级3（控制权变更条款）： [N] 已解决 / [N] 未决 ⚠️
  层级4（自动转让）：     [N] — 无需行动

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

工作计划 — 法务负责
  🔴 逾期 ([N])：
    [项目] — 应于 [日期] 到期

  ⏰ 本周到期 ([N])：
    [项目] — 应于 [日期] 到期

  ✅ 自上次报告以来已完成 ([N])：
    [项目] — 已于 [日期] 完成

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阻碍项和需要决策的事项
  [项目] — 受阻于：[描述] — 负责人：[姓名]
  [项目] — 需要决策：[描述] — 建议：[选项]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

即将到来的关键日期
  [日期] — [里程碑 / 截止日]
  [日期] — 陈述与保证存续到期 — 确认无待处理赔偿索赔

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

模式4：更新

/corporate-legal:integration-management --update [--deal [代码]]

手动更新： 律师告诉 Claude 发生了什么变化。

"我们取得了 Salesforce 的同意。标记为已取得，负责人 [姓名]，日期为今天。" "主体合理化决策是合并。更新状态并将合并登记添加到 Day 180。" "[对方当事人]拒绝同意。标记并说明我们需要外部律师判断这是否触发收购协议赔偿索赔。"

Claude 更新相关追踪器条目，重新计算任何下游状态（例如，如果全部层级1同意现均已取得，将收购协议义务标记为已满足），并展示变化了什么。

上传更新： 工作流负责人或外部律师发送状态文件。

上传来自[外部律师/人力负责人/企业发展团队]的状态更新。我将解析并更新追踪器。

读取上传的文件。按对方当事人名称或工作计划项描述将描述的项目匹配到追踪器条目。更新状态字段。标记更新中不匹配任何已有追踪器条目的任何项目——可能是需要添加的新项目。

任何更新后，展示：

已更新 [N] 项。

变更：
  CON-003 Salesforce：未开始 → 已取得
  W-014 主体合理化：进行中 → 已完成

新标记：
  CON-007 [对方当事人]：被拒绝——收购协议义务可能未满足。考虑：
  外部律师审查赔偿索赔。⚠️

---

模式5：导出

/corporate-legal:integration-management --export [--format csv|table] [--section all|consents|contracts|workplan]

产出平面 CSV 或 markdown 表格。默认：全部章节，CSV。

CSV 格式——每项一行，章节由 section 列指示。 各章节列不同：

工作计划： id, phase, description, owner, workstream, priority, deadline, status, blocker

同意： id, counterparty, contract_type, required_consent, pa_deadline, status, assigned_to, obtained_date, notes

合同： id, name, counterparty, contract_type, annual_value, assignment_mechanism, tier, required_consent, pa_deadline, status, assigned_to, notes

导出是可分享的格式——适合外部律师、企业发展或董事会整合更新。

---

本技能不做什么

• 不管理业务整合工作流（IT、人力、财务、不动产）。它追踪法务在这些工作流中的接触点并标记何时需要法务输入。所有权保留在业务职能。
• 不起草同意请求函或更替协议——这些由 written-consent 技能或外部律师产出。
• 不就赔偿索赔或收购协议违约提供建议。当同意被拒绝或截止日错过时，它标记情况——后果的法律分析是律师的职责。
• 不追踪业绩对赌表现。业绩对赌里程碑和付款日期作为参考日期出现在追踪器中，owner 设为 finance。业务驱动数字。
• 不在状态报告时实时读取合同。合同状态是律师在追踪器中更新的内容。技能在报告时读取追踪器，而非合同。

公式注入防御

在 Excel、表格或 CSV 输出中写入任何单元格前，防御公式注入。来自对方当事人的文本（合同引文、当事方名称、工商登记代办机构数据、合同管理系统导出）是攻击者可控制的。以 =、+、-、@、 、 或 开头的单元格将被解释为公式或破坏行结构。

• 前置单引号： '=SUM(A1:A10) → =SUM(A1:A10)（显示为文本，不执行）
• 适用于每个包含来源于文件、工具结果或用户粘贴的文本的单元格。 你控制的列标题和你产出的计算值是安全的。
• CSV：同时转义嵌入的逗号、双引号、换行符（RFC 4180 引用）。
• 这不是可选的。一个你的用户在 Excel 中打开后触发宏或通过 DDE 外泄数据的电子表格，是对你用户的供应链攻击。