contract-review-pro

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 — 识别客户 + 立场声明（强制） 客户识别 ： 用户明确说明的客户，直接适用 读取合同当事人信息，匹配项目目录 .claude/client-rules/ 下的关联主体（如用户已建） 从合同来源路径提取客户名称 无法识别时询问用户；未命中客户规则时 不得套用其他客户偏好 客户识别命中后，调用 ClientConfig.load_from_workspace() 加载客户偏好。 立场声明（每次审核必须重做，不沿用历史） ： 代表哪一方（甲方/乙方/中立审查） 核心利益排序（本交易中客户最看重的 2-3 项利益） 必守项 vs 可谈项二分 ：哪些条款是 deal-breaker，哪些可让步 审查口径：克制 / 常规 / 强势 立场声明写入 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 — 框架审阅（四问） 逐条审核之前，先审视合同整体框架： 义务单向性 ：主要义务是否单边压在我方（如只有我方违约责任、对方无对应义务）？ 退出权不对等 ：解除权、终止权是否单方倾斜？ 虚假前提 ：鉴于条款、前提条件是否把我方置于不利的事实推定中？ 违约责任对称性 ：双方违约责任的计算标准、上限是否对等？ 框架性问题对我方有利的保留；不利的 用 Track Changes 做框架级重构 （而非仅 Comments 提示），并在法律意见书中说明重构逻辑。 Step 3 — 效力审查优先 效力问题优先于条款优化。 调用 ContractAnalyzer.run_validity_review() 执行 5 项检查： 名实不符交易（循环买卖、名为合作实为借贷等） 关联交易公允性（明显不合理低价、关联输送） 格式条款（免责排除对方主要权利） 审批登记（区分合同效力与物权变动） 合同成立要素（当事人、标的、数量） 发现效力风险时，先处理效力问题，再谈条款优化。 Step 4 — 列出法律问题清单 基于通读、框架审阅和效力审查，列出需要研究的实质性法律问题。 Step 5 — 法律研究（分层检索 + 充分性标准） 实质性法律问题必须检索验证，禁止编造依据。 分层检索 ： 检索改写 ：禁止拿合同原文或用户原话直接检索。先分析检索意图，生成分层关键词（锚点词/正式术语/同义别名/上下位概念/排除词） 优先源检索 ：现行法律法规、司法解释、指导案例、权威数据库（按运行环境中可用的检索源执行：本地知识库 / 法规检索工具 / 官方数据库） 充分性判断 ：统计 直接相关命中数 （剔除无关合同类型、异部门法、失效法条、纯程序规定）： ≥5 条直接相关命中 → 充分 ，进入下一步 <5 条 → 扩展检索 （权威实务文章、类案裁判规则、学术观点），扩展后仍不足的如实标注 来源标注 ：每条依据标注来源层级（法律法规原文 / 裁判文书 / 权威实务观点 / 需复核），警示性来源（可能失效的自媒体、无出处汇编）不得作为唯一依据 检索合规自检（进入 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 问自检 （每条必问）： 我能替客户直接改吗？ → 能则 Track Changes（replace/insert/delete） 涉及商业判断吗？ → 是则 comment 对方大概率会接受吗？ → 是则 Track Changes（但批注告知客户） 有多个合理方案吗？ → 是则 comment，列出方案并标注倾向 最小必要修改原则 ：能局部删减就不整段重写，能局部补入就不替换整条——保留原文结构，让对方清楚看到改了什么。 修订块合并 ：同一条款需多处修改时，收敛为 2-6 组成组修订，避免审阅视图炸出十几个碎修订。 违规自检 ：Comments 中出现"建议补充"上述默认 insert 条款 = 路由错误，应改为 Track Changes。 谈判立场与升级路径 三层谈判优先级 （与立场声明的必守/可谈二分挂钩）： 第一层 必须获得（deal-breaker）：未解决则不建议推进 第二层 应当获得：强烈偏好，可拿第三层去换 第三层 可让步候选：用于交换第二层 每条重大修订附 备用立场 （首选措辞被对方拒绝时的替代方案）。 升级路径 4 级 ： 文本微调 → AI 直接 Track Changes 删除底线条款类风险 → Comments 显著提示律师本人复核 发现不利替代条款 → 标注"需决策"并给出选项 任一评分维度 ≥4 → 意见书标注"建议律师深度审阅" 风险类型标签体系（15 标签） 效力与合规类 合同效力 格式条款 主体授权 关联交易 合规审查 交易结构与履行类 价款与支付 交付与验收 违约责任 解除与终止 担保与增信 争议解决与文本类 争议解决 知识产权与保密 定义与附件 文本一致性 文字与格式 每条审核意见至少标注 1 个风险类型标签；专项门禁命中的风险同时标注专项标签。 风险评分（8 维度 1-5 分制） RiskScoringSystem 对 8 个维度分别评 1-5 分（5 为最高风险），记入 review-state 并驱动意见书雷达图： 合同效力与合规性 / 价款与支付 / 交付与验收 / 违约责任 / 知识产权与保密 / 合同解除与终止 / 争议解决 / 主体授权与担保 评分标尺 ： 分值 含义 1 条款完整且对我方有利 2 基本完整，轻微不利 3 约定不明或存在风险点 4 明显不利或重要条款缺失 5 效力风险或可能直接导致重大损失 跨阶段严重程度下限 ：下游阶段不得无声降级上游评级——如逐条审核阶段要把初评 🔴 高降为 🟠 中，必须在 review-state 中明示降级理由。 风险评价六维度 对每个重要风险，通过 RiskAssessment.evaluate_risk_dimensions() 生成： 风险定性 ：风险类型是什么 风险敞口 ：最坏情况下损失是什么（尽量量化） 发生概率 ：基于规则明确程度、当地口径、类案趋势 可规避性 ：能否通过结构调整或条款修改消除 商业权衡 ：结合客户目标和替代方案判断是否值得承受 紧迫性 ：立即处理 / 近期处理 / 持续观察 / 远期风险 终稿交付规范 每次审核完成后， 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/ 建扩展条款库，存在则自动加载。 使用三步匹配法： 理解场景（合同类型、当事人关系、风险等级） 匹配写法（基础版 vs 强化版，按标的额和对方资信选择） 适配调整（变量替换、表述统一、删去不适用内容） 禁止不经适配直接复制条款文本。 硬约束 禁止跳过立场声明 禁止跳过通读直接审核 禁止跳过实质性法律问题研究（含充分性判断） 禁止跳过效力审查 禁止先写审核意见后补法律依据 禁止修改原始合同 禁止用 python-docx 裸 API 生成批注版合同 禁止将 .md 作为终稿交付（output/ 下必须为 .docx） 禁止将应 Track Changes 的增补条款降级为 Comments 禁止在未命中客户规则时套用其他客户偏好 禁止无声降级上游风险评级（跨阶段降级必须明示理由） 禁止依赖 skill 目录之外的规则文件、知识库路径或工具（可选增强除外） 禁止编造法律依据；检索不足时如实标注 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 主入口 + 会话管理 入口