corporate-integration-management

name	corporate-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. 读取/写入 $LEGAL_AGENT_PROFILE_HOME/corporate-legal/deals/[代码]/integration-tracker.yaml。
6. 任何写入后：展示变更摘要并呈现任何新标记。

---

事项上下文

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

---

目的

外部律师完成交易交割。法务部继承后续事宜。本技能是交割后整合的项目管理层——不是业务整合，不是IT系统，不是HR组织设计。是法律工作流，包含：同意函、合同转让、主体结构优化、知识产权登记、购买协议义务履行。它追踪已完成事项、待办事项、受阻事项以及需要决策的事项。

---

追踪器文件

存放于 $LEGAL_AGENT_PROFILE_HOME/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: "[交割日期 + 7天]"
    items: []
  day_30:
    target_date: "[交割日期 + 30天]"
    items: []
  day_90:
    target_date: "[交割日期 + 90天]"
    items: []
  day_180:
    target_date: "[交割日期 + 180天]"
    items: []

required_consents: []
desired_consents: []

contracts:
  source: "[存储库 / 手动上传 / 披露附表]"
  repository_path: "[路径 或 空]"
  last_imported: "[日期]"
  total: 0
  tier_1: []
  tier_2: []
  tier_3: []
  tier_4: []

工作计划项结构：

- id: "W-001"
  description: "[行动事项]"
  phase: "[第 1 天 / 第 30 天 / 第 90 天 / 第 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-integration-management --init [--deal [代码]]

第1步：加载交易上下文

读取 $LEGAL_AGENT_PROFILE_HOME/corporate-legal/deals/[代码]/deal-context.md。如未找到：询问交易代码名称、目标公司、交割日期、交易负责人和外部律师。如果该文件不存在，写入 deal-context.md 。

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

第2步：读取交易输入

一份完整的购买协议产生最完整的跟踪表。 购买协议的必需同意清单和交割后承诺条款部分是硬性截止日和法定义务的权威来源。但该技能可以根据任何可用的输入进行有用的初始化——部分输入会产生一个由律师填写的的启动跟踪表，而不是一个空白页。

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

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

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

• 交易摘要或条款清单（提供关键经济条款和时间表）
• 来自外部律师的整合待办事项清单或交割后核对清单
• 已有的工作计划或整合追踪器（我将导入并继续处理）
• 交割核对清单——如果由并购冷启动技能生成，我将自动从 $LEGAL_AGENT_PROFILE_HOME/corporate-legal/deals/[代码]/closing-checklist.yaml 继承它
• 单独的必需同意清单（如果收购协议由外部律师持有）

如果你没有任何书面材料： 请用通俗语言告诉我交易详情——收购了谁、何时交割、主要待办事项是什么——我将根据标准的第 1/30/90/180 工作计划构建一个启动跟踪表供你编辑。

根据提供的内容，输出会发生变化：

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

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

从收购协议提取：

必需同意清单：

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

交割后义务：

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

关键日期：

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

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

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

Day 1 — 法务主导：

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

Day 1 — 法务支持：

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

Day 30 — 法务主导：

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

Day 30 — 法务支持：

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

Day 90 — 法务主导：

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

Day 90 — 法务支持：

• 全面人力资整合文件（人力资源部负责，法务就劳动法律提供建议）

Day 180 — 法务负责：

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

生成后展示摘要：

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

交割日期：[日期]
所需同意书截止日期：[日期]（距今 [N] 天）
陈述存续期届满：[日期]

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

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

下一步：运行 corporate-integration-management --contracts 导入合同列表，然后运行 --report 查看您的首次状态摘要。

---

模式2：合同转让分配

corporate-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-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-integration-management --update [--deal [代码]]

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

"我们取得了 Salesforce 的同意。并将其标记为已取得，分配给负责人 [姓名]，日期为今天。" "关于实体精简的决定是合并。更新状态并将合并申报事项添加至 180 天。" "[对方当事人]拒绝同意。标记并说明我们需要外部律师判断这是否触发购买协议赔偿索赔提供意见。"

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

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

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

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

任何更新后，展示：

已更新 [N] 项。

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

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

---

模式5：导出

corporate-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 中打开后、触发宏或通过动态数据交换外泄数据的电子表格，就是对你用户的供应链攻击。