cslawyer1985/contract-review-pro

Contract Review Pro V3.0

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

核心工作流（7 步）

作为 AI，在收到合同审核任务时，按以下步骤执行：

Step 0 — 识别客户并读取客户规则

1. 用户明确说明的客户，直接适用
2. 读取合同当事人信息，匹配工作区 .claude/client-rules/ 下的关联主体
3. 从合同来源路径提取客户名称
4. 无法识别时询问用户

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

Step 1 — 建立 review-state

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

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

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

Step 3 — 效力审查优先

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

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

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

Step 4 — 列出法律问题清单

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

Step 5 — 知识库研究

实质性法律问题必须检索知识库，每个问题至少检索2个来源。 先读取 /Users/CS/Documents/知识库/.claude/rules/knowledge-routing.md 确定检索路径。 检索失败时诚实记录未命中原因，不得编造依据。

Step 6 — 逐条审核（正反两面法）

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

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

审查每一项时同时用 RevisionRouter.determine_revision_method() 确定修订方式。

Step 7 — 条款提取

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

审查门禁（5 类强制检查）

| 门禁 | 检查内容 | |------|---------| | gate_validity | 名实不符、关联交易、格式条款、审批登记、成立要素 | | gate_subject | 主体适格、签章要求、授权委托、表见代理、一人公司、担保决议 | | gate_clause | 价款支付、交付验收、违约责任、解除清算、担保保险、送达争议 | | gate_consistency | 正文与附件、金额数量、期限条件、定义用法一致性 | | gate_output | 三件套完整性检查 |

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

每条审核意见写入前，必须通过 RevisionRouter 决策：

错别字/笔误/标点/日期格式/法律名称过时 → Track Changes 直接修订
对我方有利且可直接落地的增补条款 → Track Changes 直接补充：
  - 实现债权费用、送达确认、签章生效、声明与保证
  - 限制收款方式、反商业贿赂、独立关系声明、一人公司补充
条款矛盾/文本不一致 → Comments 指出矛盾，给出倾向性建议
商业取舍/重大风险/对方可能不接受 → Comments 列出方案
事实待核 → Comments 标注
多方案需客户选择 → Comments 列出方案并标注倾向

4 问自检清单

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

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

效力与合规类

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

交易结构与履行类

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

争议解决与文本类

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

每条审核意见至少标注1个风险类型标签。

风险评价六维度

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

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

终稿三件套规范

每次审核完成后，output/ 默认产出（全部 .docx）：

1. 批注版合同

Track Changes + Comments，批注人默认 陈石律师【海泰所】。 使用 Document Library 三步法（unpack → 编辑 → pack），禁止 python-docx 裸 API。

2. 法律意见书（5 模块）

• （一）风险总览：风险数量卡片 + 审查维度雷达图 + 风险类型分布 + 综合风险等级
• （二）合同基本信息
• （三）逐条审核意见（表格：序号→风险类型→被审条款→风险描述→修改建议→风险等级）
• （四）总体评价与签约利弊分析：有利因素、不利因素、重大风险提示、谈判建议、签署后注意事项
• （五）法律依据清单

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

3. 法律分析

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

条款库使用

条款库位于工作区 .claude/clauses/（105个条款，15+业务领域）。 使用三步匹配法：

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

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

硬约束

1. 禁止跳过通读直接审核
2. 禁止跳过实质性法律问题研究
3. 禁止跳过效力审查
4. 禁止先写审核意见后补法律依据
5. 禁止修改原始合同
6. 禁止用 python-docx 裸 API 生成批注版合同
7. 禁止将 .md 作为终稿交付（output/ 下必须为 .docx）
8. 禁止从零写批注脚本
9. 禁止将应 Track Changes 的增补条款降级为 Comments
10. 禁止在未命中客户规则时套用其他客户偏好

Python 模块参考

| 模块 | 功能 | 何时调用 | |------|------|---------| | review_config.py | 审核配置 + 客户加载 | 初始化时 | | contract_analyzer.py | 合同解析 + 效力审查 + 门禁 | Step 2-3 | | risk_assessment.py | 风险评估 + 六维度 + 雷达图 | Step 6 | | clause_review.py | 正反两面法 + 条款库匹配 | Step 6 | | revision_router.py | 路由决策树 + 4问自检 | Step 6 | | intelligent_scoring.py | 8维度加权评分 | Step 6 | | sanguan_analysis.py | 三观四步法深度分析 | Step 2-3 | | clause_extractor.py | 自动条款提取 | Step 7 | | document_generator.py | 三件套 docx 生成 | 输出阶段 | | docx_generator.py | Word Track Changes + Comments | 批注版合同 | | main.py | 主入口 + 会话管理 | 入口 |