lov-review-doc

name	lov-review-doc
description	专业合同分析、审阅、批注与红线修订。用于用户要求审查合同、协议、条款、NDA、采购或服务合同、SaaS 或数据协议、劳动或顾问协议、知识产权许可、投融资文件，或要求风险分析、逐条批注、修订模式、谈判建议、审阅报告时；支持 DOCX 原位批注和修订，以及 PDF、图片或纯文本的定位审阅。
license	MIT
metadata	{"author":"contributors","version":"1.1.0","category":"business","tags":"contract legal review annotate redline negotiation 合同 审阅 批注 修订","compatibility":"Python 3.8+、python-docx 1.0+、lxml 4.9+；支持 macOS、Windows 和 Linux"}

合同专家审阅

以资深交易律师与法务负责人的工作标准审阅合同。既判断法律风险，也判断交易能否履行、责任是否对等、证据是否留得住、争议时是否执行得了。不要把关键词扫描冒充专业审阅。

不可降低的标准

• 先确认审阅立场、法域、合同类型、交易目标和风险偏好；信息不足时列明合理假设并继续，不因非关键缺口停工。
• 区分三类判断：文本事实、法律判断、商业判断。不得把商业偏好写成法律强制要求。
• 引用法律结论前核验当前有效的官方来源、施行日期和适用法域。不得凭记忆引用条号。
• 保留原文件，输出新文件；不得覆盖用户原件。
• 每个高风险问题必须包含后果、建议和可落地的替代文本。只写“建议咨询律师”不算完成。
• 不臆造缺失附件、主体资质、金额、日期、法条、判例或谈判背景。未知项标为“待确认”。
• 对重大交易、跨境、监管、争议中或需要正式法律意见的事项，明确建议由对应法域执业律师复核；这不替代本次实质审阅。

工作流程

1. 建立审阅任务书

优先从用户材料和上下文提取以下信息：

• 我方身份与希望保护的利益
• 对方身份、主体类型和履约能力
• 适用法、争议解决地、合同语言
• 合同类型、交易金额、期限和关键时间点
• 必须接受、可以交换、不可接受的商务条件
• 当前阶段：初稿、对方稿、谈判稿、待签稿或履约争议
• 交付偏好：仅批注、仅修订、批注加修订，或审阅报告

缺少信息时采用默认值：站在提供文件一方的利益立场；中国大陆一般商事合同；中等风险偏好；输出“批注 + 修订 + 审阅报告”。在报告开头显著列出这些假设。

2. 准备并完整读取文件

根据输入格式处理：

• DOCX：运行 scripts/contract_docx.py extract，读取正文、表格、页眉和页脚。不得只看正文段落。
• PDF：使用可用的 PDF/OCR 能力，保留页码和条款号；扫描件先检查 OCR 置信度。无法安全写回时输出页码级批注表，不伪称已写入原文件。
• 图片：逐页 OCR，保留图片序号和区域定位。
• 纯文本/Markdown：按标题、条款号和原文短引定位。

同时检查附件、定义、目录、签署页、价税表、SLA、DPA、订单和引用文件是否齐全。缺失材料单独列为“审阅范围限制”。

DOCX 命令：

python3 scripts/contract_docx.py extract --input 合同.docx --output 合同-blocks.json
python3 scripts/contract_docx.py validate --input 合同.docx --annotations 审阅数据.json
python3 scripts/contract_docx.py annotate --input 合同.docx --annotations 审阅数据.json --output 合同-批注修订版.docx

需要 python-docx>=1.0 与 lxml>=4.9。如果缺失，先在隔离环境安装；不要修改用户项目依赖。

3. 确定法律与行业基线

先识别适用法域，再选择权威来源。中国大陆合同先阅读 中国大陆法律核验基线。其他法域仅使用对应立法机关、法院、监管机构或官方法库；无法可靠核验时明确限制，不把中国法规则套用到境外合同。

对数据、金融、医疗、教育、广告、消费者、劳动、建设工程、房地产、进出口等受监管交易，追加行业专项核验。

4. 做七轮审阅

按顺序完成，不因发现前几项问题而跳过后续检查：

1. 交易结构：主体、授权、标的、对价、税费、交付、验收、付款闭环。
2. 定义与一致性：定义是否完整；条款、附件、日期、金额、币种、比例和交叉引用是否一致。
3. 权利义务：触发条件、履行标准、期限、依赖项、审批权、变更机制是否清晰且可执行。
4. 风险分配：陈述保证、赔偿、违约责任、责任上限、免责、保险、不可抗力和第三方索赔。
5. 生命周期：生效、续期、暂停、解除、终止、交接、退款、数据返还或删除、存续条款。
6. 合规与争议：强制性规则、审批登记、知识产权、保密、数据、出口管制、反商业贿赂、适用法和争议解决。
7. 可操作与可举证：通知、确认、记录、审计、送达、签署、版本优先级、证据留存和执行成本。

按合同类型加载 合同类型与条款检查表，但不要机械套模板。

5. 形成问题清单并定级

每个问题记录：原文定位、原文短引、风险等级、问题类型、结论、依据、可能后果、首选修订、退让方案、是否需业务确认。

风险等级：

• 致命：可能导致交易目的不能实现、重大无上限责任、明显无效或重大监管风险；签署前必须解决。
• 高：发生概率或损失显著，且现有文本明显不利；原则上必须修改或取得书面风险接受。
• 中：会增加履约、举证或争议成本；建议修改，可用商务条件交换。
• 低：清晰度、格式或轻微不一致；有余力时修正。
• 提示：不是缺陷，但需要业务决策、补资料或持续关注。

谈判优先级另行标记为 必须坚持、优先争取、可交换、可接受。风险等级与谈判优先级不得混为一谈。

6. 写批注与修订

默认同时提供批注和红线修订。批注解释“为什么改”，修订文本解决“怎么改”。遵循 批注数据与交付格式。

每条批注使用以下结构，控制在 2 至 5 句：

【高风险｜责任限制｜必须坚持】本条将间接损失排除仅适用于对方，且未设置我方累计责任上限。发生服务中断时，我方可能承担不可预测且无上限的赔偿。建议改为双方对等排除间接损失，并将一般责任上限设为过去十二个月已付费用；保密、知识产权侵权和故意重大过失可另设例外。

修订时：

• 尽量做最小必要修改，保留原有措辞、编号、格式和商业口径。
• 给出可直接粘贴的完整句子或完整条款，不用“酌情调整”“按法律规定”等空话。
• 高风险条款同时给出首选版本和可接受的退让版本；不要把所有条件都改成极端单边保护。
• 中英文合同保持术语和定义一致；如两种文本同等效力，检查冲突处理机制。
• 不确定的商业数字使用 [待业务确认：…]，不得自行填数。

7. 输出完整交付物

默认生成：

1. 原文件名-合同审阅-YYYY-MM-DD.docx：含批注和修订痕迹。
2. 原文件名-审阅报告-YYYY-MM-DD.md：便于决策和谈判。
3. 原文件名-审阅数据-YYYY-MM-DD.json：可复核的结构化批注与修订数据。

审阅报告采用以下结构：

# 合同审阅报告

## 审阅结论
签署建议：可签 / 修改后可签 / 暂缓签署
用一段话说明总体风险、关键前提和审阅范围。

## 审阅任务书与假设
我方立场、适用法、合同类型、风险偏好、材料范围、待确认项。

## 必须在签署前解决
只列致命和高风险事项，按谈判顺序排列。

## 风险清单
表格列：编号、定位、风险、类别、问题、后果、建议、谈判优先级。

## 缺失条款与材料
列出缺失附件、空白字段、未闭环机制和建议补充文本。

## 谈判方案
首选条件、可交换条件、底线、建议话术。

## 法律依据与核验日期
只列实际使用的权威来源、条文或规则、链接、核验日期。

## 审阅范围限制
列出 OCR、材料缺失、法域或行业专项意见等限制。

8. 做签署前质量检查

交付前逐项确认：

• 原文件未被覆盖，输出文件能正常打开。
• DOCX 的批注和修订数量与 JSON 一致；运行 validate 无错误。
• 每个致命和高风险问题都有明确替代文本或可执行动作。
• 所有定位、原文短引、定义、条款号和交叉引用准确。
• 金额、日期、币种、税率、付款比例、期限和附件名称前后一致。
• 争议解决条款写明机构或法院、地点、适用规则、语言和适用法，且组合可执行。
• 法律来源为当前有效的官方文本，并记录核验日期。
• 报告明确签署建议、谈判底线、待确认项和审阅限制。

如果质量检查失败，先修复再交付；不要把脚本“执行成功”当成审阅完成。

交付边界

• 不声称自己是用户的执业律师，不出具律师事务所法律意见书或法律认证。
• 不协助伪造签名、日期、审批、证据或交易背景。
• 不因风险提示而擅自替用户接受条款、签署、发送给对方或提交监管机构。
• 涉及高额、控制权、股权、担保、破产、刑事、制裁、跨境数据或迫近诉讼时，在完成实质审阅后建议专项律师复核。

Runtime context (shared)

运行前读取本 Skill 包的 skill.yaml，由宿主提供 skill-runtime/v1 上下文。字段解析顺序为：当前请求、项目上下文、个人 Preferences、品牌 Profile、通用默认值。

• 只使用 Manifest 声明的字段；Profile 保存公开品牌事实，Preferences 保存个人工作偏好。
• required: true 字段缺失时，按 Manifest 的问题配置向用户提出一个聚焦问题；用户明确同意后再保存回答。
• 报错提供可复制的 context_id、字段路径与来源，诊断内容避开秘密、完整私人路径和原始配置。

通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 task-specific（仅本次）还是 reusable（可跨任务复用）。
2. task-specific 只修改当前任务，不改 Skill。
3. reusable 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. reusable 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。