| name | legal-contract-review |
| description | 对合同、协议、标书、NDA、采购合同、服务合同、合作协议等法律文件进行辅助初筛；提取文本和元数据，检查条款完整性、法律与商业风险、交叉引用和版本差异，计算风险评分，并可生成报告、Docx 标注副本或修订副本。用户要求合同审查、法务审查、合规检查、签署前风险评估、条款修改、合同对比或批量审查时使用。仅提供辅助审阅，不替代律师意见，不处理诉讼或仲裁代理。 |
法务合同辅助审查
不可违反的原则
- 保留原合同；所有标注、修订和报告写入新文件。
- 先确定审查方、法域、合同类型、版本和目的，再判断风险。
- 每项结论引用具体条款；缺失内容标为“未提供/未验证”，不虚构。
- 区分法律风险、商业不利、表述问题和需人工决策事项。
- 正式签署、高金额、跨境、监管敏感或争议事项必须建议执业律师/法务复核。
- 涉及现行法律、监管规则或时效性要求时，查询并引用官方一手来源，注明适用法域与核验日期；无法核验时不得给确定性结论。
执行流程
- 预检：确认文件可访问、未损坏，记录审查方、对方主体、法域、合同类型、金额、版本、审查目的及截止时间。缺少非关键参数时合理推断并披露；会改变结论的参数才询问用户。
- 选择模式：默认标准审查；NDA/低金额紧急件可用快速审查；高金额、战略合作、跨境或强监管行业使用深度审查。具体阈值和命令读取 workflows-and-operations.md。
- 提取与校验：调用
scripts/extract_contract_text.py 和 scripts/extract_metadata.py；核对正文、表格、附件、页码/条款号与 OCR 质量。提取不完整时不得继续输出完整结论。
- 完整性检查：运行
scripts/check_completeness.py，区分“条款缺失”和“条款存在但不利”。
- 逐条审查：读取 legal_playbook.md 中与合同类型、行业、金额和合作对象对应的章节；检查主体授权、权利义务、价款税费、交付验收、知识产权、保密、数据、赔偿、违约、终止、续约、转让分包、争议解决及交叉引用。
- 形成发现：对每项记录编号、条款位置、原文、风险类型、严重程度、依据、影响、建议文本、需确认角色和置信度。相同根因合并，不能把措辞强硬直接等同违法或无效。
- 评分与结论：运行
scripts/calculate_risk_score.py；评分只作排序和沟通辅助，不替代法律判断。结论同时考虑不可接受条款、缺失资料和人工闸门，不能仅由总分决定。
- 生成与验证：按需生成分段报告、标注副本、修订副本或版本差异；核对每项发现能回到原文、风险统计一致、原件未覆盖。详细命令和目录规范读取 workflows-and-operations.md。
审查模式
| 模式 | 使用条件 | 最低范围 |
|---|
| 快速 | 紧急、低金额或简单 NDA | 高风险项 + 必备条款 + 主体/签署信息 |
| 标准 | 常规商务合同 | 全部适用规则 + 完整性 + 交叉引用 |
| 深度 | 高金额、战略、跨境、强监管或复杂合作 | 标准审查 + 法域核验 + 商业合理性 + 行业专项 + 版本/附件一致性 |
风险与人工闸门
高：可能违法/违规、造成重大责任失衡或签署前必须处理。中：存在明显法律或执行风险，原则上建议修改。低：表述、流程或规范性问题，可优化。
以下事项必须交给对应授权人员确认：条款法律效力、诉讼胜率、监管合规、税务、赔偿可接受度、商业让步、信用风险、预算、保险充分性、跨境数据路径及签署授权。不要使用“无风险”“保证有效”“一定胜诉”等表述。
输出契约
默认交付一份结构化审查报告；用户需要时再生成标注或修订文件。报告至少包含：
- 审查范围、立场、法域、版本和资料限制；
- 管理层摘要、签署建议与高/中/低风险数量；
- 合同基本信息及必备条款缺口；
- 逐条风险发现、修改建议和建议文本；
- 待法务/业务/财务确认清单；
- 风险评分解释、未验证事项和免责声明。
文件统一放入任务工作目录下的独立结果子目录，不把产物写入 Skill 目录。原始合同、提取文本、元数据、评分和报告共同构成审查证据链。
按需资源路由
完成检查
- 已说明审查方、法域、模式、版本、目的和资料范围。
- 已完成提取质量检查、完整性检查及适用规则审查。
- 每项发现均有原文定位、依据、影响、建议和责任人。
- 现行法律结论有官方来源与日期，或明确标记未核验。
- 评分未替代实质判断；人工确认事项已单列。
- 原件未修改，产物可打开，统计和文件名一致。
合同修改 DOCX 强制交付约定 (MODIFICATION COMPLETION CONTRACT)
当用户明确要求修改/修订/完善/重写/调整合同，或要求生成修改后的合同文件时，必须遵守：
- 先审核合同（如尚未完成审核）。
- 确定具体的条款修改方案。
- 在原始文档副本上执行修改，禁止覆盖用户上传的原合同。
- 优先使用
scripts/modify_contract.py 或其他能保留 DOCX 结构的脚本生成新的 .docx 文件。
- 如果环境没有 Python/python-docx，禁止尝试
pip install；改为在任务工作目录根写入 docx_modification_request.json，桌面端会自动调用内置 Rust DOCX 引擎生成文件。JSON 格式见 references/workflows-and-operations.md。
- 输出文件放入任务工作目录的正式 Artifact 输出目录，文件命名不得覆盖已有文件；例如
采购合同_修订版.docx，若已存在则追加序号。
- 必须返回真实存在的
.docx 文件路径，并确保文件可打开、大小大于 0、包含 word/document.xml。
- 仅输出 Markdown/文本/JSON/修改建议，不视为完成。
- 只有 DOCX Artifact 存在且有效后，才能声称“合同修改完成”。
- 若 DOCX 生成失败，必须明确说明“合同修改未完成：DOCX 文件生成失败”，不得谎报完成。
