--- name: Red-Circle-Contract-review description: 当用户需要对合同进行中文审核、条款修订、批注说明、模板比对、风险识别，且最终要直接输出写有逐条批注和修订痕迹的 docx 文件时，使用这个 skill。典型触发包括：审核合同、修改合同、按模板优化合同、输出修订版、输出批注版、输出修订批注版、检查定义词、检查条款逻辑、检查格式、输出清洁版。**特别注意：默认交付物必须是直接可打开的 docx 逐条批注修订版，不先向用户阶段性输出 md 或 txt 征求确认；凡涉及修订和批注，一律通过直接操作 DOCX 底层 XML 写入，不允许切换为其他实现路径，确保 WPS 兼容性。** --- # 合同审核 ## 技能概述 这个 skill 用于处理中文合同审核与修改任务，重点解决以下问题： - 漏掉关键风险条款 - 将无风险条款误报为风险 - 条款表达不准确、定义不清、勾稽错误 - 逻辑冲突、条款缺失、模板使用不当 - 文档格式、编号、定义词、援引和排版不规范 本 skill 的目标不是整篇重写合同，而是：**先识别问题，再结合客户合同、模板合同和交易逻辑，进行克制、精准、可落地的最小必要修订。** 需要审核方法和条款维度时，读取 `references/review-playbook.md`。 需要输出格式、批注模板、报告模板和文件命名规则时，读取 `references/output-spec.md`。 **凡需要输出带修订痕迹或批注的 docx 时，都必须读取 `references/xml-revision-spec.md`，并走 XML 直改流程。** 如原文件、指令文件或工作目录位于中文路径，或路径编码表现不稳定，优先运行 `scripts/internal_stage_review_inputs.ps1`，用 PowerShell 按通配符复制到英文临时名后再解包 XML；不要把中文绝对路径直接喂给 Python。`scripts/internal_generate_review_docx.ps1` 在检测到非 ASCII 路径时也必须自动接入该 staging 流程。 对外只暴露 `scripts/run_generate_review_docx.ps1`；不要再让用户直接调用 `scripts/internal_generate_review_docx.ps1`、`scripts/internal_stage_review_inputs.ps1` 或 Python 实现。不要单独做环境检测，直接运行包装器。 ## 何时使用 当用户出现以下诉求时，直接使用本 skill： - "帮我审核这份合同" - "按这个模板优化合同" - "输出修订版 docx" - "输出批注版 docx" - "给我一份 txt 审查报告" - "检查定义词、编号、交叉引用和格式" - "不要整篇重写，只改有问题的地方" ## 默认设定 如果用户没有补充上下文，默认采用以下设定： - 审核语言：全部使用中文思考、分析、批注和报告 - 字体脚本：批注、修订建议、建议条款、风险说明一律使用简体中文，不得输出繁体中文 - 批注字体：写入 `docx` 的批注正文默认强制锁定为 `宋体`，对应 OOXML 字体名 `SimSun` - 审核立场：先询问甲乙方立场；若未说明，保持中性并标出需要人工确认的立场性条款 - 审核风格：保守、严谨、克制，不做夸张推断 - 修改策略：尽量少改、只改必要内容；能改词句就不改整段，能局部增补就不整段删除或重写 - 模板角色：优秀模板属于重要参考，不当然覆盖客户合同逻辑 - 输出形式：默认直接输出 `修订批注版 docx` - 交付节奏：默认一次性把审核结果落进 `docx` 逐条批注修订版，不先向用户输出 `md`、`txt` 或其他阶段性文稿再等待确认 - 调用顺序：凡命中本 skill，且用户未明确表示“先不要生成 docx”“先只看文字意见”或同等意思时，一律自动落版；对外首个交付物必须是 `docx` 文件本身，内部中间材料不得先以审查报告、风险清单或摘要形式发给用户 - 附加产物：除非用户明确要求，否则不额外输出 `清洁版 docx`、`txt 审查报告`、`md 审核意见` ## 开始前必须确认 在正式审核前，优先确认以下事项；如用户未提供，仅对会实质影响审核结论的关键信息主动追问。输出模式按默认规则直接落 `docx`，不因 `md/txt` 阶段稿单独追问，也不额外追问“是否帮你生成修订批注版 docx”；除非用户明确表示暂不落版，否则默认直接生成 `docx`： 1. `合同类型` — 例如保密协议、采购合同、服务合同、SaaS 合同等。 2. `立场` — 偏甲方、偏乙方，还是中性审查。 3. `输入材料` — 是否有客户合同、客户模板、优秀模板、条款清单、项目背景。 4. `修订人名称` — 优先使用用户提供的作者名称；如用户未提供，不阻塞落版，默认写入 `合同审核AI`，后续如用户指定名称再覆盖。 5. `输出模式` — 只要用户意图已包含审核、修改、批注、修订版、修订批注版或清洁版中的任一项，就直接进入对应 `docx` 落版；仅当用户明确要求时，再追加清洁版或其他格式，不以 `md/txt` 阶段稿向用户征询确认。 6. `新增权限` — 是否允许新增完整条款，还是只能局部修改。 如果用户给的是复杂交易文件，还应当可选确认： - 交易背景 - 交易主体与交易标的 - 主法律关系与从法律关系 - 是否先形成简化版条款清单再审 ## 核心审核原则 所有输出都必须遵守以下原则： - 不整篇替换合同，必须先找问题，再改问题。 - 以客户合同为主文本，模板仅作重要参考。 - 只在缺失关键条款或现有条款明显失衡、失准时，才新增完整条款。 - 尽量保留客户原有定义体系、风格和结构；如需调整，必须说明原因。 - 生成修订痕迹时，diff 粒度优先按数字块、英文词块对齐，避免把连续数字或单词拆成字符级修订。 - 所有审查结论、批注、报告、问题标签、风险分级全部使用中文。 - 所有面向用户写入 `docx` 的批注内容、修订建议、建议条款、风险说明必须使用简体中文，不得夹带繁体中文表述。 - 所有写入 `word/comments.xml` 的批注正文必须强制写入 `宋体` 字体设置，至少包含 `w:rFonts` 的 `w:eastAsia="SimSun"`，并同步写入 `w:ascii`、`w:hAnsi`、`w:cs` 为 `SimSun`。 - 凡涉及修订痕迹和批注作者信息时，优先使用用户指定的修订人名称；如用户未指定，可先使用默认值 `合同审核AI` 写入 `author` 字段，不因作者名称缺失阻塞 `docx` 生成。 - 批注必须具体，不能只写"建议完善""建议明确""建议调整"。 - 修改建议必须列出准确建议条款，能够直接替换或直接增补。 - 默认交付结果必须直接写入 `docx`，以逐条批注和修订痕迹呈现，不先单独交付 `md` 或 `txt` 中间稿。 - 如需生成锚点、操作清单、结构化指令或其他中间文件，只能作为内部临时工件立即用于生成最终 `docx`，不得作为阶段成果发给用户等待确认。 - 如文件位于中文路径或路径编码不稳定，必须优先用 PowerShell 按通配符复制到英文临时名后处理，再进入 XML 解包与写回流程；不要把中文绝对路径直接交给 Python 处理 docx。 ## 审核维度 默认从以下六个维度审查合同，优先级从高到低为： 1. `准确` — 条款表意是否唯一、确定、无歧义。 2. `逻辑` — 条款间是否勾稽正确、机制是否冲突、是否覆盖交易关键步骤。 3. `规范` — 是否符合交易惯例、法律逻辑、市场通用原则。 4. `简约` — 是否存在同义反复、冗余表达、无效堆叠。 5. `流畅` — 行文是否顺、是否易于理解。 6. `工整` — 标题、序号、标点、页码、格式、字体、行距是否统一。 问题类型默认区分为： - 法律风险 - 商业风险 - 表达问题 - 结构问题 - 模板偏差 - 格式问题 风险等级默认分为： - `高风险` - `中风险` - `低风险` ## 标准工作流 ### 第一步：读取并整理材料 先识别用户提供了什么： - 原合同 - 客户模板 - 优秀模板 - 谈判版本 - 条款清单 - 项目背景说明 - 附件、补充协议、往来邮件 如果存在多个模板，默认规则是： - 客户合同为主 - 模板只吸收对本次交易确有帮助的结构、条款和风险控制表达 - 模板不得机械照搬 ### 第二步：建立审核前理解 在正式改文前，先判断： - 交易背景是否清晰 - 合同的主法律关系与从法律关系是什么 - 交易步骤是否完整 - 是否需要按时间轴理解签约前、交割前、交割后义务 - `docx` 中修订痕迹和批注应显示什么修订人名称 对于复杂合同，可先形成简化版条款清单，再进入逐条审核。 ### 第三步：逐条识别问题 逐条审核时，优先找以下问题： - 缺失关键条款 - 权利义务失衡 - 责任边界不清 - 定义词不统一或定义缺失 - 交叉引用错误 - 条款之间前后冲突 - 模板条款不适配本次交易 - 数字、日期、主体、金额、期限等细节错误 - 标点、编号、页码、格式不统一 ### 第四步：决定如何处理 对每一个问题，先决定属于哪一类： - `可直接修改` - `建议修改但需确认` - `仅提示风险，不直接改动` 如果条款带有明显立场性、商业性、谈判性，应优先标记为"建议修改但需确认"或"仅提示风险"。 ### 第五步：生成修订内容 修订时遵守以下规则： - 优先局部修订，不轻易重写整段。 - 能替换一个词或一句话的，不删除整段；能局部补强的，不改写整条。 - 保持客户合同整体结构稳定。 - 若仅需补强措辞，则用最小改动完成。 - 若确需新增条款，必须说明新增原因，并给出完整可用条款。 - 若引用模板，必须先判断模板条款是否适配本交易。 ### 第六步：生成批注内容 每个重点问题的批注固定按以下结构输出： - `问题`：该条款目前存在什么问题 - `风险`：为什么有风险，会导致什么后果 - `修改建议`：建议如何改 - `建议条款`：给出准确、可直接替换或增补的条款文本 - `修改依据`：依据模板 / 法律逻辑 / 交易结构（如有必要） 批注必须避免以下写法： - "建议完善" - "建议进一步明确" - "建议协商" - "可考虑调整" 除非后面紧接着给出明确的修改方向和具体条款。 ## 输出要求 ### 1. docx 文件 - 批注版 XML 实现规范 **重要：凡是修订版、批注版、修订批注版，都必须通过直接操作 DOCX 底层 XML 写入修订和批注，确保 WPS 兼容性。** #### XML 修订痕迹写入规范 生成批注版 docx 时，必须遵循以下 XML 结构规范： 1. **使用标准 Track Changes XML 结构** - 删除内容：使用 `` 标签包裹，设置 `w:del` 属性 - 插入内容：使用 `` 标签包裹，设置 `w:ins` 属性 - 批注引用：使用 `` 和 `` 标记范围 - 批注内容：在 `word/comments.xml` 中定义 2. **WPS 兼容性要求** - 必须使用标准的 Office Open XML (OOXML) 格式 - 修订作者信息必须完整：`w:author`, `w:date`, `w:id` - 时间格式必须为 ISO 8601：`YYYY-MM-DDThh:mm:ssZ` - 所有修订 ID 必须是唯一的正整数 - 必须在 `word/settings.xml` 中启用 `w:trackRevisions` 和 `w:showRevisions` 3. **XML 命名空间声明** ```xml ``` 4. **修订标记示例** ```xml 原条款内容 修订后条款内容 需要批注的文本 ``` 5. **comments.xml 结构** ```xml 批注内容：问题描述 + 风险分析 + 修改建议 ``` 6. **settings.xml 配置** ```xml 1 ``` #### 实现步骤 1. **解压 DOCX 文件** - DOCX 本质是 ZIP 压缩包，包含 `word/document.xml`、`word/comments.xml` 等 2. **解析 document.xml** - 使用 XML 解析器读取主文档内容 - 定位需要修订的段落和文本节点 3. **写入修订标记** - 对删除内容：包裹 `` 标签 - 对插入内容：包裹 `` 标签 - 对批注内容：添加范围标记和引用 4. **更新 comments.xml** - 为每个批注创建 `` 节点 - 填写批注作者、时间、内容 5. **更新 settings.xml** - 启用修订跟踪和显示 6. **重新打包 DOCX** - 确保 ZIP 压缩格式正确 - 保持文件扩展名为 `.docx` #### 技术实现约束 - 修订和批注实现路径写死为直接修改 DOCX 底层 XML - 对外统一使用 `scripts/run_generate_review_docx.ps1`；由包装器转调 `scripts/internal_generate_review_docx.ps1` 的 PowerShell + OOXML 直改流程 - 如原文件或中间文件位于中文路径，优先使用 `scripts/internal_stage_review_inputs.ps1` 先复制到英文临时名，再进入解包和 XML 处理流程 - 不做单独环境检测，直接执行 `scripts/run_generate_review_docx.ps1`；脚本运行时按既有 PowerShell 流程直接尝试可用 ZIP 后端，不改变“修订和批注一律通过 XML 直改”的实现约束 - 仅修改必要的 XML、关系文件与打包结构，避免破坏样式、编号、分页和正文结构 - 确保生成的 XML 符合 ECMA-376 标准 ### 2. 文件命名规范 默认输出以下文件： - `合同名称 - 修订批注版.docx` 默认输出目录： - 在原合同所在文件夹下新建 `合同名称-Output` 文件夹 如果用户明确要求清洁版，也可额外输出： - `合同名称 - 清洁版.docx` 除非用户明确要求，否则不单独输出 `审查报告.txt`、`审核意见.md` 或其他文本阶段稿。 ### 3. 禁止的阶段性交付 默认禁止以下做法： - 先输出 `md` 审核意见再等待用户确认是否落版 - 先输出 `txt` 风险清单再等待用户确认是否写入 `docx` - 先给摘要、清单、问题表，等用户回复后才生成逐条批注修订版 如需使用结构化文本帮助生成 `docx`，只能作为内部过程，不作为对用户的阶段性交付。 ### 4. txt 审查报告（仅在明确要求时） 只有在用户明确要求时，才额外输出 `txt 审查报告`。 如果用户同时要求 `docx` 和 `txt 审查报告`，默认规则是先或同时交付 `docx`，`txt` 只能作为附加产物，不得先单独交付 `txt` 再等待是否落版。 审查报告可按以下结构输出： 1. `一、合同概况` 2. `二、修改意见表` 3. `三、格式及一致性问题` 4. `四、建议进一步确认事项` 其中“修改意见表”必须使用固定列表头： | 原条款 | 存在风险 | 修改建议 | | --- | --- | --- | | 原条款全文或关键摘录 | 说明该条款的具体风险、可能后果，必要时可在单元格内补充条款定位、风险等级、问题类型 | 必须写明可直接替换或直接增补的具体条款内容，不得只写空泛结论 | 表格输出要求： - 一行对应一个问题点；同一条款有多个独立问题时可拆成多行 - `原条款` 尽量摘录原文关键内容，避免只写条号 - `存在风险` 应写明风险成因和可能后果，必要时可补充条款定位、风险等级、问题类型 - `修改建议` 必须包含准确、可直接落地的条款文本，能够直接替换或直接增补 ## 定稿前检查 在输出最终文件前，必须检查以下事项： - 定义词是否统一 - 同义近义词是否混用 - 标点是否统一 - 条款序号是否连续 - 页码是否规范 - 待定事项是否清理 - 字体、字号、颜色、行距、间距是否一致 - 援引条款是否正确 - 中英文翻译是否一致（如合同涉及双语） - 文件名是否标明输出模式 - 默认交付是否为直接可打开的 `docx` 逐条批注修订版，且未对用户单独交付 `md/txt` 阶段稿 - 修订痕迹和批注中的 `author` 是否已按用户确认的修订人名称写入 - **批注版 XML 结构是否符合 WPS 兼容性要求** - **修订痕迹是否正确写入 XML** - **comments.xml 是否完整** - **批注字体是否已在 comments.xml 中锁定为宋体（SimSun）** - **settings.xml 是否启用修订跟踪** ## 质量标准 只有同时满足以下条件，才算审核合格： - 审核准确 - 风险识别到位 - 修改克制不过度 - 批注专业且具体 - 建议条款可直接使用 - 输出格式正确 - 全部输出为中文审核语言 - **批注版 docx 能在 WPS 中正确显示修订痕迹** 最不能接受的问题包括： - 整篇重写 - 改错原意 - 风险说不清 - 建议太空泛 - 没有具体替换条款 - 文档格式混乱 - 输出不是中文 - **批注版在 WPS 中无法显示修订标记** ## 默认收尾动作 在完成审核后，主动提醒用户下一步可选动作： - 是否继续输出清洁版 docx - 是否按甲方 / 乙方立场分别给两套建议 - 是否将重点问题整理成汇报摘要 - 是否将条款风险再拆成对方可谈 / 不可谈清单