legal-contract-review

name	legal-contract-review
description	对合同、协议、标书、NDA、采购合同、服务合同、合作协议等法律文件进行辅助初筛；提取文本和元数据，检查条款完整性、法律与商业风险、交叉引用和版本差异，计算风险评分，并可生成报告、Docx 标注副本或修订副本。用户要求合同审查、法务审查、合规检查、签署前风险评估、条款修改、合同对比或批量审查时使用。仅提供辅助审阅，不替代律师意见，不处理诉讼或仲裁代理。

法务合同辅助审查

不可违反的原则

• 保留原合同；所有标注、修订和报告写入新文件。
• 先确定审查方、法域、合同类型、版本和目的，再判断风险。
• 每项结论引用具体条款；缺失内容标为“未提供/未验证”，不虚构。
• 区分法律风险、商业不利、表述问题和需人工决策事项。
• 正式签署、高金额、跨境、监管敏感或争议事项必须建议执业律师/法务复核。
• 涉及现行法律、监管规则或时效性要求时，查询并引用官方一手来源，注明适用法域与核验日期；无法核验时不得给确定性结论。

执行流程

1. 预检：确认文件可访问、未损坏，记录审查方、对方主体、法域、合同类型、金额、版本、审查目的及截止时间。缺少非关键参数时合理推断并披露；会改变结论的参数才询问用户。
2. 选择模式：默认标准审查；NDA/低金额紧急件可用快速审查；高金额、战略合作、跨境或强监管行业使用深度审查。具体阈值和命令读取 workflows-and-operations.md。
3. 提取与校验：调用 scripts/extract_contract_text.py 和 scripts/extract_metadata.py；核对正文、表格、附件、页码/条款号与 OCR 质量。提取不完整时不得继续输出完整结论。
4. 完整性检查：运行 scripts/check_completeness.py，区分“条款缺失”和“条款存在但不利”。
5. 逐条审查：读取 legal_playbook.md 中与合同类型、行业、金额和合作对象对应的章节；检查主体授权、权利义务、价款税费、交付验收、知识产权、保密、数据、赔偿、违约、终止、续约、转让分包、争议解决及交叉引用。
6. 形成发现：对每项记录编号、条款位置、原文、风险类型、严重程度、依据、影响、建议文本、需确认角色和置信度。相同根因合并，不能把措辞强硬直接等同违法或无效。
7. 评分与结论：运行 scripts/calculate_risk_score.py；评分只作排序和沟通辅助，不替代法律判断。结论同时考虑不可接受条款、缺失资料和人工闸门，不能仅由总分决定。
8. 生成与验证：按需生成分段报告、标注副本、修订副本或版本差异；核对每项发现能回到原文、风险统计一致、原件未覆盖。详细命令和目录规范读取 workflows-and-operations.md。

审查模式

模式	使用条件	最低范围
快速	紧急、低金额或简单 NDA	高风险项 + 必备条款 + 主体/签署信息
标准	常规商务合同	全部适用规则 + 完整性 + 交叉引用
深度	高金额、战略、跨境、强监管或复杂合作	标准审查 + 法域核验 + 商业合理性 + 行业专项 + 版本/附件一致性

风险与人工闸门

• 高：可能违法/违规、造成重大责任失衡或签署前必须处理。
• 中：存在明显法律或执行风险，原则上建议修改。
• 低：表述、流程或规范性问题，可优化。

以下事项必须交给对应授权人员确认：条款法律效力、诉讼胜率、监管合规、税务、赔偿可接受度、商业让步、信用风险、预算、保险充分性、跨境数据路径及签署授权。不要使用“无风险”“保证有效”“一定胜诉”等表述。

输出契约

默认交付一份结构化审查报告；用户需要时再生成标注或修订文件。报告至少包含：

1. 审查范围、立场、法域、版本和资料限制；
2. 管理层摘要、签署建议与高/中/低风险数量；
3. 合同基本信息及必备条款缺口；
4. 逐条风险发现、修改建议和建议文本；
5. 待法务/业务/财务确认清单；
6. 风险评分解释、未验证事项和免责声明。

文件统一放入任务工作目录下的独立结果子目录，不把产物写入 Skill 目录。原始合同、提取文本、元数据、评分和报告共同构成审查证据链。

按需资源路由

• 如果需要审查规则、行业/金额调整、风险示例或批注 JSON，读取 legal_playbook.md 的对应章节；不要默认整本加载。
• 如果要执行单份、批量、版本对比、Docx 标注、修订或历史查询，读取 workflows-and-operations.md。
• 如果遇到扫描件、乱码、加密文件、依赖失败、报告合并失败、评分异常或 Docx 损坏，读取 troubleshooting.md。

完成检查

• 已说明审查方、法域、模式、版本、目的和资料范围。
• 已完成提取质量检查、完整性检查及适用规则审查。
• 每项发现均有原文定位、依据、影响、建议和责任人。
• 现行法律结论有官方来源与日期，或明确标记未核验。
• 评分未替代实质判断；人工确认事项已单列。
• 原件未修改，产物可打开，统计和文件名一致。

合同修改 DOCX 强制交付约定 (MODIFICATION COMPLETION CONTRACT)

当用户明确要求修改/修订/完善/重写/调整合同，或要求生成修改后的合同文件时，必须遵守：

1. 先审核合同（如尚未完成审核）。
2. 确定具体的条款修改方案。
3. 在原始文档副本上执行修改，禁止覆盖用户上传的原合同。
4. 优先使用 scripts/modify_contract.py 或其他能保留 DOCX 结构的脚本生成新的 .docx 文件。
5. 如果环境没有 Python/python-docx，禁止尝试 pip install；改为在任务工作目录根写入 docx_modification_request.json，桌面端会自动调用内置 Rust DOCX 引擎生成文件。JSON 格式见 references/workflows-and-operations.md。
6. 输出文件放入任务工作目录的正式 Artifact 输出目录，文件命名不得覆盖已有文件；例如 采购合同_修订版.docx，若已存在则追加序号。
7. 必须返回真实存在的 .docx 文件路径，并确保文件可打开、大小大于 0、包含 word/document.xml。
8. 仅输出 Markdown/文本/JSON/修改建议，不视为完成。
9. 只有 DOCX Artifact 存在且有效后，才能声称“合同修改完成”。
10. 若 DOCX 生成失败，必须明确说明“合同修改未完成：DOCX 文件生成失败”，不得谎报完成。