Resources
10Install
npx skillscat add cslawyer1985/contract-review-pro Install via the SkillsCat registry.
Contract Review Pro V3.0
专业合同审核 Skill,将合同审核工作区的成熟方法论编码为可执行流程。
核心工作流(7 步)
作为 AI,在收到合同审核任务时,按以下步骤执行:
Step 0 — 识别客户并读取客户规则
- 用户明确说明的客户,直接适用
- 读取合同当事人信息,匹配工作区
.claude/client-rules/下的关联主体 - 从合同来源路径提取客户名称
- 无法识别时询问用户
客户识别命中后,调用 ClientConfig.load_from_workspace() 加载客户偏好。
Step 1 — 建立 review-state
记录:源文件路径、客户、起草方、交易结构摘要、风险预分类(8维度1-5分)、法律问题清单。
Step 2 — 通读合同,理解交易
完整阅读合同全文,梳理:主体、标的、价款、交付/验收、结算、违约责任、解除、担保、争议解决、附件。
Step 3 — 效力审查优先
效力问题优先于条款优化。 调用 ContractAnalyzer.run_validity_review() 执行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 问自检清单
- 我能替客户直接改吗? → 能则 Track Changes
- 涉及商业判断吗? → 是则 Comments
- 对方大概率会接受吗? → 是则 Track Changes(但标注告知客户)
- 有多个合理方案吗? → 是则 Comments,列出方案
风险类型标签体系(15 标签)
效力与合规类
合同效力 格式条款 主体授权 关联交易 合规审查
交易结构与履行类
价款与支付 交付与验收 违约责任 解除与终止 担保与增信
争议解决与文本类
争议解决 知识产权与保密 定义与附件 文本一致性 文字与格式
每条审核意见至少标注1个风险类型标签。
风险评价六维度
对每个重要风险,通过 RiskAssessment.evaluate_risk_dimensions() 生成:
- 风险定性:风险类型是什么
- 风险敞口:最坏情况下损失是什么
- 发生概率:基于规则明确程度、当地口径、类案趋势
- 可规避性:能否通过结构调整或条款修改消除
- 商业权衡:结合客户目标和替代方案判断是否值得承受
- 紧迫性:立即处理 / 近期处理 / 持续观察 / 远期风险
终稿三件套规范
每次审核完成后,output/ 默认产出(全部 .docx):
1. 批注版合同
Track Changes + Comments,批注人默认 陈石律师【海泰所】。
使用 Document Library 三步法(unpack → 编辑 → pack),禁止 python-docx 裸 API。
2. 法律意见书(5 模块)
- (一)风险总览:风险数量卡片 + 审查维度雷达图 + 风险类型分布 + 综合风险等级
- (二)合同基本信息
- (三)逐条审核意见(表格:序号→风险类型→被审条款→风险描述→修改建议→风险等级)
- (四)总体评价与签约利弊分析:有利因素、不利因素、重大风险提示、谈判建议、签署后注意事项
- (五)法律依据清单
核心原则:律师分析利弊,客户做决定。 禁止以"建议签署""不建议签署"替代利弊分析。
3. 法律分析
内部参考文件,列明修订点对应的法条、司法解释、指导案例、类案裁判规则。
条款库使用
条款库位于工作区 .claude/clauses/(105个条款,15+业务领域)。
使用三步匹配法:
- 理解场景(合同类型、当事人关系、风险等级)
- 匹配写法(基础版 vs 强化版,按标的额和对方资信选择)
- 适配调整(变量替换、表述统一、删去不适用内容)
禁止不经适配直接复制条款文本。
硬约束
- 禁止跳过通读直接审核
- 禁止跳过实质性法律问题研究
- 禁止跳过效力审查
- 禁止先写审核意见后补法律依据
- 禁止修改原始合同
- 禁止用 python-docx 裸 API 生成批注版合同
- 禁止将 .md 作为终稿交付(output/ 下必须为 .docx)
- 禁止从零写批注脚本
- 禁止将应 Track Changes 的增补条款降级为 Comments
- 禁止在未命中客户规则时套用其他客户偏好
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 |
主入口 + 会话管理 | 入口 |