---
name: contract-review
description: 合同辅助审查。给一个「合同 + 签约依据」压缩包，解析出合同正文与全部依据材料（含扫描件、会议纪要截图），逐条对照公司标准合同模板，产出结构化 Markdown 审查报告——覆盖基础文本审查（金额、格式、标点、错别字）、条款缺失与模板差异、与签约依据的一致性、风险合规提示。当用户提到合同审查、合同审核、合同比对、条款缺失、合同风险、签约依据、合同模板校验、起草合同把关时触发。
---

# 合同辅助审查

审查一份已起草的合同：先把压缩包里的材料全部转成文本，再对照标准合同模板逐条找问题，最后出一份可直接转成 Word 的 Markdown 报告。解包与抽取全部交给 [file-extract](../file-extract/SKILL.md) 基座技能，本技能只负责审查维度、参考数据的取用与报告写作。

运行约定：

- 路径一律相对本技能根目录：本技能写 `references/x.md`，基座技能写 `../file-extract/scripts/x.py`（两者恒为兄弟目录）。执行时给命令加上技能根目录前缀，不要 `cd` 进技能目录。前缀取宿主加载技能时告知的 Base directory；拿不到就用 `find / -name extract.py -not -path '*__pycache__*' 2>/dev/null | head -1` 定位，取其上两级为 file-extract 的根目录。
- 所有 `uv run` 命令都不要加 timeout 参数，沙箱后端不支持 per-command timeout override，加了必定报错。

## Step 1：取材料

压缩包的完整 URL 由上游给出（平台上传产出的是相对路径，需拼上平台域名）。一次调用取全：

```bash
uv run ../file-extract/scripts/extract.py --url <压缩包完整 URL>
```

输出的 `files` 是全部材料文本（图片与扫描件已 OCR 成文字），`errors` 是没读到的材料。**`errors` 必须原样带进报告最后一节**，不要把读不到的材料当成不存在。字段含义见 [file-extract 的 references/format.md](../file-extract/references/format.md)。

## Step 2：认出合同正文

按文件名规则先筛：**文件名含「合同」且扩展名为 pdf/docx 的是合同正文候选**，其余材料一律视为签约依据（会议纪要、询比价申请表、结果审批表、成交通知书等）。

材料的目录结构不可依赖——同一批合同里，有的把依据放进 `签约依据/` 子目录，有的与合同平铺在同一层。只认文件名与正文内容，不认路径层级。

候选多于一份时结合正文开头判定（真正的合同有甲乙双方、合同编号、签订地点这类要素），并在报告里写明选了哪一份、其余归入了依据。

## Step 3：取标准模板

从合同正文判定类型，调用 MCP 工具 `get-contract-template`（挂在同一 AI 对话节点的 `/mcp/contract-review` 端点）取该类型标准合同模板的**完整正文**：

| contractType | 对应 |
| --- | --- |
| `procurement` | 采购（货物采购、设备采购） |
| `construction` | 施工（小型建设工程等） |
| `lease` | 租赁（房屋、场地） |
| `technical-service` | 技术服务（信息化集成、运维等） |

四类都对不上时选最接近的一类，并在报告里说明该判定是近似的。

返回的 `content` 是模板全文（Markdown），`title` 与 `sourceFile` 带模板版本，报告里要写明比对依据的是哪一版。

工具不可用或返回 404 时，如实写明「未取得标准模板，条款缺失项与模板差异未做比对」，**不要凭印象编造模板条款**——编出来的「缺失条款」会直接误导起草人。

## Step 4：出报告

审查维度与逐项检查清单见 [references/review-dimensions.md](references/review-dimensions.md)，报告结构（固定五节）与 Markdown 语法约束见 [references/report-format.md](references/report-format.md)。

报告正文只输出 Markdown，不要包裹代码围栏——下游是平台「文档输出」节点，它吃的是纯 Markdown，围栏会被原样渲染进 Word。

## 平台编排

```text
文件上传（类型选「其他（全部）」）
  → AI 对话（挂 contract-review 技能 + /mcp/contract-review）产出 Markdown 报告
  → 文档输出（Markdown 来源 = 该 AI 对话节点的 answer，输出格式 = Word）→ 下载链接
```

技能与 MCP 必须挂在**同一个** AI 对话节点：平台无法把文件路径作结构化输出带出节点，产物只能经该节点的 `answer` 往下走。

## 质量要求

- 可追溯：每条问题都要指出在合同中的位置（条款号或小节标题）与原文片段，不写「某处金额有误」这种无法定位的结论
- 分级：按「必须修改 / 建议修改 / 提示关注」三级标注，不把错别字与缺失违约责任条款并列
- 有据：条款缺失的判断依据是标准模板正文，一致性问题的依据是签约依据材料原文，风险提示依据通用合同法律常识——三者的来源要在报告里分得清
- 如实：材料缺失、OCR 未识别、模板未取到，都写进「材料完整性说明」，不假装材料齐备

## 特殊处理

- **OCR 结果的错字**：签约依据里的印章、手写签名区域容易误识，引用金额、单位名称、日期前先与其他材料互证；只在一处出现且不合常理的数字，标为「疑似 OCR 误识，需人工核对」而不是当成合同问题
- **合同正文没抽到**：这是唯一无法继续的情况（`errors` 里该文件报 `parse_failed` 或 `empty_text`），直接告知用户重传或改用可编辑格式，不要拿依据材料硬凑一份审查结论
- **金额一致性**：合同大小写金额、分项之和与总价、与询比价/审批表里的中标价，三者要交叉核对——这是实测最容易出问题的地方
- **本服务不做法规检索**：风险合规提示只能来自通用合同法律常识，不要虚构法条编号或企业红线制度条款