contract-review-pro

合同批注专家 · Contract Reviewer

概述

此技能通过仅添加批注（不修改原文）来审核合同。审核采用四层审查法（主体核验、基础、业务、法律），并生成：

• 批注版合同（.docx）
• 合同概要（.docx）
• 综合审核意见（.docx）
• 业务流程图（Mermaid + 渲染图像）

**语言规则：**检测合同的主要语言，并使用该语言输出所有生成内容（批注、概要、意见、流程图文本）。请参阅 references/language.md 中的指南。

工作流

1. 解包合同（.docx）以进行 XML 操作
2. 读取合同文本（pandoc 或 XML）
3. 提取并核验合同主体（第 0 层）
4. 执行三层条款审核（第 1–3 层）
5. 为文档添加批注
6. 生成合同概要
7. 生成综合审核意见
8. 生成业务流程图并渲染图像
9. 重新打包为 .docx

输出命名

• 输出目录：中文使用 审核结果：{ContractName}，英文使用 Review_Result_{ContractName}
• 已审核合同：中文使用 {ContractName}_审核版.docx，英文使用 {ContractName}_Reviewed.docx
• 审核报告：中文使用 审核报告.txt，英文使用 Review_Report.txt

批注原则

• 仅添加批注：不得修改原文或其格式
• 精准定位：批注应针对具体条款或段落
• 结构化内容：每条批注均包含问题类型、风险原因和修改建议
• 风险等级：通过审核人名称体现；批注正文中不得包含“风险等级”这一行
• 输出语言：使用合同所用语言的标签（参见 references/language.md）

批注示例（英文）：

[Issue Type] Payment Terms
[Risk Reason] The total amount is stated as USD 100,000 in Section 3.2, but the payment clause lists USD 1,000,000 in Section 5.1. This inconsistency may cause disputes.
[Revision Suggestion] Align the total amount across clauses and clarify whether tax is included.

审核标准

使用四层审核模型和 references/checklist.md 中的详细清单。

第 0 层：主体核验（主体真实性）

• 提取所有合同主体（完整法定名称、统一社会信用代码、法定代表人）
• 核实每个主体的注册名称是否准确、工商登记状态是否有效
• 核验工具优先级：
  1. 如果当前环境中有可用于查询工商登记信息的 MCP 工具（例如企业信息查询、公司查询、企业查询、工商查询），使用该工具查询各方的名称或统一社会信用代码。
  2. 如果没有此类 MCP 工具，则使用 Web Search 搜索“[主体名称] 工商登记信息”或“[主体名称] business registration”。
  3. 在批注中记录核验来源（MCP 工具名称 / Web Search）。

第 1 层：基础（文本质量）

• 数字、日期、术语的准确性
• 编号和引用的一致性
• 表述清晰、无歧义
• 格式和标点质量

第 2 层：业务条款

• 范围、交付物、数量／规格
• 定价和付款安排
• 交付／验收流程
• 权利／义务及履约保证

第 3 层：法律条款

• 生效及期限／终止
• 责任／违约金及救济措施
• 争议解决及适用法律
• 保密、不可抗力、知识产权、通知、授权

风险等级（通过审核人名称体现）：

• 🔴 高：核心业务内容表述不明（价格、范围、权利／义务）
• 🟡 中：重要但非核心内容表述不明
• 🔵 低：实际影响极小

合同概要

使用合同所用语言生成结构化、客观的概要。

• 参见 references/summary.md（英文模板）
• 使用 references/language.md 选择语言和中文标签

输出文件：中文使用 合同概要.docx，英文使用 Contract_Summary.docx（默认字体：仿宋；如语言要求，可调整）

综合审核意见

为业务团队生成一份简洁的两段式回复，使用合同所用语言。

• 参见 references/opinion.md

输出文件：中文使用 综合审核意见.docx，英文使用 Consolidated_Opinion.docx（默认字体：仿宋；如语言要求，请调整）

业务流程图（Mermaid）

根据要求生成 Mermaid 流程图并渲染为图片。

• 参见 references/flowchart.md

输出文件：

• business_flowchart.mmd
• business_flowchart.png

li## 技术说明

核心工作流：

1. 解包 → 2. 实体核验 → 3. 添加批注 → 4. 摘要 → 5. 意见 → 6. 流程图 → 7. 重新打包

API 与实现细节：

• references/technical.md

依赖项

• Python 3.9+（推荐使用 3.10+）
• pandoc（系统安装）
• defusedxml
• Mermaid CLI（mmdc），用于渲染
• python-docx，用于富文本输出

故障排查（简要）

• Word 中缺少批注：运行 doc.verify_comments() 并重新保存
• find_paragraph 失败：缩短搜索文本；确认段落的实际文本
• Mermaid 渲染失败：确保已安装 mmdc；使用 Chrome 路径或 Puppeteer 配置

示例

完整工作流示例请参见 references/examples.md。

重要规则

1. 绝不修改合同原文
2. 必须先完成实体核验（第 0 层），再审核条款（第 1–3 层）
3. 审查全部四层，不得跳过任何项目
4. 确保风险级别准确且一致
5. 批注应准确、专业且可执行
6. 流程图必须严格依据合同原文
7. 摘要仅陈述客观内容，不进行风险分析
8. 意见仅反映已识别的发现

许可证

SPDX-License-Identifier: Apache-2.0

Copyright (c) 2026 JiCheng

根据 Apache License, Version 2.0 许可。详见仓库根目录下的 LICENSE。

通用反馈闭环

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

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