name	contract-review-pro
description	专业合同审核 Skill：7步工作流（含立场声明、框架审阅、类型路由）、5类通用门禁+16个专项门禁、终稿三件套+HTML可视化报告、8维度风险评分、修订5分类路由。完全自包含，零外部依赖。
version	4.0.0
author	Claude + 陈石律师
tags	["合同审核", "法律", "风险管理", "终稿三件套", "专项门禁", "HTML报告"]

Contract Review Pro V4.0

专业合同审核 Skill，将成熟合同审核方法论编码为可执行流程。

设计原则：完全自包含

本 skill 自身即可完成全部审核工作，不依赖 skill 目录之外的任何规则文件、知识库路径或外部工具：

• 专项门禁、检查清单、风险模板、条款标准全部内置于 references/ 和 data/
• 批注版合同由内置 OOXML 引擎（scripts/ooxml_lite.py）生成；环境中恰好装有 docx skill 或 officecli 时可作可选增强，但不是流程必经环节
• 客户规则、条款库扩展是可选输入：用户可在自己的项目目录建 .claude/client-rules/（客户偏好）和 .claude/clauses/（条款库），存在则加载，不存在则询问或跳过，均不阻断流程
• 法律研究按通用分层检索方法论执行，适配运行环境中可用的任何检索源

核心工作流（7 步）

Step 0 — 识别客户 + 立场声明（强制）

客户识别：

1. 用户明确说明的客户，直接适用
2. 读取合同当事人信息，匹配项目目录 .claude/client-rules/ 下的关联主体（如用户已建）
3. 从合同来源路径提取客户名称
4. 无法识别时询问用户；未命中客户规则时不得套用其他客户偏好

客户识别命中后，调用 ClientConfig.load_from_workspace() 加载客户偏好。

立场声明（每次审核必须重做，不沿用历史）：

1. 代表哪一方（甲方/乙方/中立审查）
2. 核心利益排序（本交易中客户最看重的 2-3 项利益）
3. 必守项 vs 可谈项二分：哪些条款是 deal-breaker，哪些可让步
4. 审查口径：克制 / 常规 / 强势

立场声明写入 review-state，后续所有"对我方有利/不利"的判断以立场声明为基准。

Step 1 — 建立 review-state

记录：源文件路径、客户、起草方、立场声明、交易结构摘要、风险预分类（8 维度 1-5 分初始评分）、法律问题清单。

Step 1.5 — 合同类型路由（激活专项门禁）

按合同名称、关键条款、交易结构识别合同类型，激活 references/gates/ 下对应专项门禁：

识别关键词	加载门禁
建设工程/施工/承包/分包	08-建设工程.md
借款/借贷/融资/还款	09-借贷.md
保证/抵押/质押/担保	10-担保.md
买卖/购销/采购/供应	11-买卖.md
租赁/承租/出租	12-租赁.md
股权转让/并购/股权收购	13-股权转让.md
承揽/加工/定作	14-承揽.md
技术开发/技术服务/技术许可	15-技术.md
委托/物业服务	16-委托物业.md
有限合伙/合伙协议	17-有限合伙.md
广告/推广/营销服务	18-广告.md
劳动/聘用/劳务	19-劳动.md
增资/增资扩股/VC/PE 投资	20-VCPE增资.md

条款级门禁（跨类型触发，与类型门禁并行且结论互相校验）：

• 含反稀释/反摊薄安排 → clause-gates/anti-dilution.md
• 含回购/赎回/股权回售安排 → clause-gates/buyback.md
• 含业绩承诺/估值调整/业绩补偿/对赌 → clause-gates/valuation-adjustment.md

股权转让与 VC/PE 同时命中时，VC/PE 门禁优先。未命中任何类型时仅执行通用门禁。

Step 2 — 通读合同，理解交易

完整阅读合同全文，梳理：主体、标的、价款、交付/验收、结算、违约责任、解除、担保、争议解决、附件。

Step 2.5 — 框架审阅（四问）

逐条审核之前，先审视合同整体框架：

1. 义务单向性：主要义务是否单边压在我方（如只有我方违约责任、对方无对应义务）？
2. 退出权不对等：解除权、终止权是否单方倾斜？
3. 虚假前提：鉴于条款、前提条件是否把我方置于不利的事实推定中？
4. 违约责任对称性：双方违约责任的计算标准、上限是否对等？

框架性问题对我方有利的保留；不利的用 Track Changes 做框架级重构（而非仅 Comments 提示），并在法律意见书中说明重构逻辑。

Step 3 — 效力审查优先

效力问题优先于条款优化。 调用 ContractAnalyzer.run_validity_review() 执行 5 项检查：

1. 名实不符交易（循环买卖、名为合作实为借贷等）
2. 关联交易公允性（明显不合理低价、关联输送）
3. 格式条款（免责排除对方主要权利）
4. 审批登记（区分合同效力与物权变动）
5. 合同成立要素（当事人、标的、数量）

发现效力风险时，先处理效力问题，再谈条款优化。

Step 4 — 列出法律问题清单

基于通读、框架审阅和效力审查，列出需要研究的实质性法律问题。

Step 5 — 法律研究（分层检索 + 充分性标准）

实质性法律问题必须检索验证，禁止编造依据。

分层检索：

1. 检索改写：禁止拿合同原文或用户原话直接检索。先分析检索意图，生成分层关键词（锚点词/正式术语/同义别名/上下位概念/排除词）
2. 优先源检索：现行法律法规、司法解释、指导案例、权威数据库（按运行环境中可用的检索源执行：本地知识库 / 法规检索工具 / 官方数据库）
3. 充分性判断：统计直接相关命中数（剔除无关合同类型、异部门法、失效法条、纯程序规定）：
   • ≥5 条直接相关命中 → 充分，进入下一步
   • <5 条 → 扩展检索（权威实务文章、类案裁判规则、学术观点），扩展后仍不足的如实标注
4. 来源标注：每条依据标注来源层级（法律法规原文 / 裁判文书 / 权威实务观点 / 需复核），警示性来源（可能失效的自媒体、无出处汇编）不得作为唯一依据

检索合规自检（进入 Step 6 前阻断级检查）：

• 所有实质性问题均已检索，无"先结论后依据"
• 检索表达经过改写，未直接照搬合同原文
• 直接相关命中数已统计，充分性结论有记录
• 关键法条已验证现行有效（无失效法规引用）
• 每条依据有来源标注

任一未过，阻断进入逐条审核。检索失败时诚实记录未命中原因。

Step 6 — 逐条审核（正反两面法）+ 偏差记录

调用 ClauseReviewer.review_clause_dual() 对每项权利义务进行三层次审查：

• 正面：正常情况下应做什么，权利义务是否明确
• 反面：做不到怎么办，救济措施是否明确
• 进阶：救济不被执行时怎么办

审查每一项时同时用 RevisionRouter.determine_revision_method() 确定修订方式（见修订路由决策树）。

偏差记录（6A）：审核中偏离内置标准条款或审查惯例的处理（如应增补条款未增补、应 TC 的改为 Comment），记录到输出目录的 deviation-log，注明理由。

Step 7 — 条款提取 + 偏差触发审查

每次审核完成后，调用 ClauseExtractor.scan_for_candidates() 扫描值得入库的条款，输出到项目目录的 candidates/ 子目录，禁止直接写入正式条款库。

偏差触发审查（7B）：deviation-log 中同类偏差 3 个月内累计 ≥3 次时提示用户关注；6 个月 ≥5 次时建议用户审视内置条款标准或审查口径是否需要修订。

审查门禁

通用门禁（5 类强制检查）

门禁	检查内容
gate_validity	名实不符、关联交易、格式条款、审批登记、成立要素
gate_subject	主体适格、签章要求、授权委托、表见代理、一人公司、担保决议；首次出现的企业主体应做工商业信用核查（存续状态、经营范围、涉诉风险），按环境中可用的查询工具执行
gate_clause	价款支付、交付验收、违约责任、解除清算、担保保险、送达争议
gate_consistency	正文与附件、金额数量、期限条件、定义用法一致性；占位符空白检测——必备条款内容为空白线/"待填"/"详见附件"等占位符时，不得判为合规，至少记中风险
gate_output	三件套完整性检查

专项门禁（16 个，references/gates/ 内置）

13 类合同专项门禁 + 3 个条款级门禁，由 Step 1.5 路由激活，与通用门禁并行执行。每个专项门禁含：专项核查事项、专项风险标签、针对性法律依据提示。

修订路由决策树（强制执行）

每条审核意见写入前，必须通过 RevisionRouter 决策。修订动作 5 分类：

动作	适用情形	呈现
replace	错别字、标点、日期、法律名称过时、前后不一致、明显不利且可直接改写	Track Changes 替换（del+ins 配对）
insert	缺失关键条款、对我方有利且可直接落地的增补	Track Changes 插入（独立段落）
delete	重复表述、明显多余或对我方重大不利且无保留价值的内容	Track Changes 删除
comment	条款矛盾、商业取舍、重大风险、对方可能不接受、事实待核、多方案	Comments 批注
report-only	整体评价、框架性观察、无需改动文本的提示	仅写入法律意见书

默认 insert 的常用增补条款（无需每次判断）：实现债权费用（优先嵌入违约责任条款）、送达确认、签章生效、声明与保证、限制收款方式、反商业贿赂、独立关系声明、一人公司补充。

4 问自检（每条必问）：

1. 我能替客户直接改吗？ → 能则 Track Changes（replace/insert/delete）
2. 涉及商业判断吗？ → 是则 comment
3. 对方大概率会接受吗？ → 是则 Track Changes（但批注告知客户）
4. 有多个合理方案吗？ → 是则 comment，列出方案并标注倾向

最小必要修改原则：能局部删减就不整段重写，能局部补入就不替换整条——保留原文结构，让对方清楚看到改了什么。

修订块合并：同一条款需多处修改时，收敛为 2-6 组成组修订，避免审阅视图炸出十几个碎修订。

违规自检：Comments 中出现"建议补充"上述默认 insert 条款 = 路由错误，应改为 Track Changes。

谈判立场与升级路径

三层谈判优先级（与立场声明的必守/可谈二分挂钩）：

• 第一层 必须获得（deal-breaker）：未解决则不建议推进
• 第二层 应当获得：强烈偏好，可拿第三层去换
• 第三层 可让步候选：用于交换第二层

每条重大修订附备用立场（首选措辞被对方拒绝时的替代方案）。

升级路径 4 级：

1. 文本微调 → AI 直接 Track Changes
2. 删除底线条款类风险 → Comments 显著提示律师本人复核
3. 发现不利替代条款 → 标注"需决策"并给出选项
4. 任一评分维度 ≥4 → 意见书标注"建议律师深度审阅"

风险类型标签体系（15 标签）

效力与合规类

合同效力 格式条款 主体授权 关联交易 合规审查

交易结构与履行类

价款与支付 交付与验收 违约责任 解除与终止 担保与增信

争议解决与文本类

争议解决 知识产权与保密 定义与附件 文本一致性 文字与格式

每条审核意见至少标注 1 个风险类型标签；专项门禁命中的风险同时标注专项标签。

风险评分（8 维度 1-5 分制）

RiskScoringSystem 对 8 个维度分别评 1-5 分（5 为最高风险），记入 review-state 并驱动意见书雷达图：

合同效力与合规性 / 价款与支付 / 交付与验收 / 违约责任 / 知识产权与保密 / 合同解除与终止 / 争议解决 / 主体授权与担保

评分标尺：

分值	含义
1	条款完整且对我方有利
2	基本完整，轻微不利
3	约定不明或存在风险点
4	明显不利或重要条款缺失
5	效力风险或可能直接导致重大损失

跨阶段严重程度下限：下游阶段不得无声降级上游评级——如逐条审核阶段要把初评 🔴 高降为 🟠 中，必须在 review-state 中明示降级理由。

风险评价六维度

对每个重要风险，通过 RiskAssessment.evaluate_risk_dimensions() 生成：

1. 风险定性：风险类型是什么
2. 风险敞口：最坏情况下损失是什么（尽量量化）
3. 发生概率：基于规则明确程度、当地口径、类案趋势
4. 可规避性：能否通过结构调整或条款修改消除
5. 商业权衡：结合客户目标和替代方案判断是否值得承受
6. 紧迫性：立即处理 / 近期处理 / 持续观察 / 远期风险

终稿交付规范

每次审核完成后，output/ 产出三件套（全部 .docx，禁止 .md 交付），可选产出第四件 HTML 报告：

1. 批注版合同 {合同名}-审核修订版.docx

Track Changes + Comments，批注人默认 陈石律师【海泰所】。

双引擎：scripts/docx_generator.py 自动分派——环境中存在 docx skill（DOCX_SKILL_ROOT 或 ~/.claude/skills/docx）时使用其 Document library，否则使用内置 ooxml_lite 引擎（标准库实现，零依赖）。

OOXML 编辑纪律：

• 修订标记 del+ins 配对：先 <w:del>（w:delText）后 <w:ins>（w:t）
• 新增条款必须是独立 <w:p> 段落并携带 <w:pPr> 格式属性，不得行内追加到现有段落
• 修订/批注必须携带作者、日期、编号；批注锚点用 2-4 字最短唯一锚点词，避开将被修订修改的文本
• Word/WPS 常把文本拆进多个 <w:t> 分片，定位一律用拼接匹配（ooxml_lite 已内置），禁止单 run 字符串假设
• 执行顺序：段落插入 → 段内文本修改 → 编号/标签修改（防止锚点被自己改掉）
• 环境装有 officecli 时，可用 officecli view <file> screenshot 做修改后视觉复核（可选增强）
• 禁止 python-docx 裸 API 生成批注版

2. 法律意见书 {合同名}-法律意见书.docx

客户速览页（首页，1 页内）：审核结论段（签署利弊的倾向性概括，不给刚性结论）+ Top 风险（≤5 条，每条 ≤3 行、零法条术语）+ 谈判要点（必守/可谈）。

五模块正文：

• （一）风险总览仪表盘：风险数量卡片 + 8 维度雷达图 + 风险类型分布 + 综合风险等级
• （二）合同基本信息
• （三）逐条审核意见（七列表格：序号/风险类型/被审条款原文/风险描述/修改建议/风险等级，红橙蓝色标）
• （四）总体评价与签约利弊分析：有利因素、不利因素、重大风险提示、谈判建议（三层优先级+备用立场）、签署后注意事项；必须含"清单之外的一个问题"强制追问——从商业模式变化、对方履约能力恶化、行业惯例、连锁效应四个角度，追问一个审核清单未覆盖但可能影响客户决策的问题
• （五）法律依据清单

核心原则：律师分析利弊，客户做决定。 禁止以"建议签署""不建议签署"替代利弊分析。

版式规范：深蓝色标题 + 仿宋正文 + 浅底元信息卡（合同名称/当事人/审核日期/审核人）+ 棕色标签高亮 + 页脚页码；紧凑正式件参数（压缩页边距/行距/段距，避免无效留白）；逐条意见表格化（标签列收窄、内容列加宽）。

3. 法律分析 {合同名}-法律分析.docx

内部参考文件，列明修订点对应的法条、司法解释、指导案例、类案裁判规则及检索验证状态。

4. HTML 可视化报告（可选增强件）{合同名}-审核报告.html

scripts/html_report_generator.py 生成，单文件离线可开（无外部依赖）：8 维雷达图、按章节风险热力图、条款对比卡（左原文/右建议/底部修改理由）、风险清单等级筛选器、综合评级徽章、统计卡片行、谈判策略三级标签。定位为增强呈现件，不替代三件套。

多轮迭代目录约定

同一合同多轮审核时：output/round-1/、round-2/、final/，每轮附简版 manifest（文件清单 + 风险统计），final/ 为对客交付版本。

条款库使用

内置标准条款库 data/clause_standards.csv（18 类标准条款）；用户可在项目目录 .claude/clauses/ 建扩展条款库，存在则自动加载。

使用三步匹配法：

1. 理解场景（合同类型、当事人关系、风险等级）
2. 匹配写法（基础版 vs 强化版，按标的额和对方资信选择）
3. 适配调整（变量替换、表述统一、删去不适用内容）

禁止不经适配直接复制条款文本。

硬约束

1. 禁止跳过立场声明
2. 禁止跳过通读直接审核
3. 禁止跳过实质性法律问题研究（含充分性判断）
4. 禁止跳过效力审查
5. 禁止先写审核意见后补法律依据
6. 禁止修改原始合同
7. 禁止用 python-docx 裸 API 生成批注版合同
8. 禁止将 .md 作为终稿交付（output/ 下必须为 .docx）
9. 禁止将应 Track Changes 的增补条款降级为 Comments
10. 禁止在未命中客户规则时套用其他客户偏好
11. 禁止无声降级上游风险评级（跨阶段降级必须明示理由）
12. 禁止依赖 skill 目录之外的规则文件、知识库路径或工具（可选增强除外）
13. 禁止编造法律依据；检索不足时如实标注

Python 模块参考

模块	功能	何时调用
review_config.py	审核配置 + 客户加载	初始化时
contract_analyzer.py	合同解析 + 效力审查 + 门禁	Step 2-3
risk_assessment.py	风险评估 + 六维度	Step 6
clause_review.py	正反两面法 + 条款库匹配	Step 6
revision_router.py	修订 5 分类路由 + 4 问自检	Step 6
intelligent_scoring.py	8 维度 1-5 分制评分	Step 6
sanguan_analysis.py	宏观-中观-微观三层深度分析	Step 2-3
clause_extractor.py	自动条款提取	Step 7
document_generator.py	三件套 docx 生成（版式规范内置）	输出阶段
docx_generator.py	批注版 Track Changes + Comments（双引擎）	批注版合同
ooxml_lite.py	内置 OOXML 引擎（零依赖兜底）	批注版合同
html_report_generator.py	HTML 可视化报告	输出阶段（可选）
main.py	主入口 + 会话管理	入口