---
name: contract-standards-ingest
description: Ingest and standardize user-provided contract assets — existing template libraries, sample contracts, clause banks, rule/standard libraries, review playbooks, checklists, past review opinions, negotiation guidelines, or company policies — and transform them into two reusable internal standards: (1) a structured Review Playbook (rule items with positions, fallback ladders, and red lines) that the review engine applies as the PRIORITY review standard, and (2) a Contract Clause Library (locked general clauses + bespoke core clause modules + variable placeholders) that the drafting engine assembles from FIRST. Use this skill whenever the user offers, attaches, or mentions having their own templates/rules/playbooks, and proactively inform the user this capability exists so they can supply their own standards. User-supplied standards override the expert's built-in defaults.
---

# 合同 · 用户标准资料接入与标准化

> 这是合同专家的**标准内化工序**。很多企业法务、业务团队手里已经有沉淀好的资产——合同模板库、范本、惯用条款、规则库、审查 Playbook、审查清单、过往审查意见、谈判纪律、内部合规制度。本 skill 把这些**用户自有资料**接进来，转化成两种专家可直接复用的标准：
> - **审查 Playbook（规则库）**：结构化的逐条审查标准，供 `contract-review-engine` 作为**优先审查口径**执行。
> - **合同条款库**：从模板/范本拆出的"固定法律条款 + 专属核心条款模块 + 可变占位要素"，供 `contract-drafting-engine` **优先拼装**。
>
> **核心原则：用户提供的标准优先于专家内置默认知识。** 用户的 Playbook/条款库代表其真实业务偏好、立场口径与风险容忍度，专家在其基础上做查漏补强，而不是另起炉灶。

## 一、何时调用 + 主动告知（让用户知道有这功能）

### 1.1 触发时机

| 信号 | 动作 |
|---|---|
| 用户附件/粘贴了模板、范本、规则文档、Playbook、审查清单、过往意见书 | 立即进入接入流程 |
| 用户说"我们有自己的模板/标准/审查要点，能不能按这个来" | 引导其提供，进入接入流程 |
| 进入起草（C3/C4/C9）或审查（C5/C6）类场景且用户尚未提供标准 | **主动一句话告知**此能力，邀请提供（见 1.2） |

### 1.2 主动告知话术（关键：让用户知道可以提供）

在**起草类**和**审查类**场景开工前（通常和 `contract-intake` 采集同时或紧接其后），用一句自然、不打断节奏的话让用户知道这个能力存在，例如：

> "如果贵司已有合同模板库、惯用条款、审查规则或 Playbook，可以一并发我——我会把它转成标准化的审查清单/条款库，之后**优先按你们的标准**来起草和审查，比用通用模板更贴合你们的业务。没有也没关系，我会用通用标准。"

要点：
- **告知但不强制**——用户没有也能照常工作，不要因为缺资料而卡住。
- **说清收益**——"优先按你们的标准""更贴合业务""审查更快更一致"。
- **一次说清，不反复催**——告知过一次即可，用户选择不提供就用内置标准继续。

## 二、资料类型识别与归类

收到资料后，先判断它该转化成哪种标准（同一份资料可能两者兼具）：

| 用户资料类型 | 转化目标 | 说明 |
|---|---|---|
| 合同模板、范本、过往签署的合同 | **合同条款库** | 拆出可复用条款模块 + 占位要素 |
| 惯用条款集、条款库导出 | **合同条款库** | 直接归类入库 |
| 审查规则库、审查要点、风控清单、Checklist | **审查 Playbook** | 转成逐条规则项 |
| 审查 Playbook / 谈判纪律 / 立场手册 | **审查 Playbook** | 保留立场、回退档与红线 |
| 过往审查意见书、批注版合同 | **审查 Playbook** | 反向提炼出隐含的审查规则 |
| 内部合同管理制度、合规要求 | **两者兼有** | 制度里既含条款要求也含审查红线 |
| 混合包/文件夹 | 先分拣再分别转化 | 逐份判类型 |

> 资料形态：附件（doc/docx/pdf/xlsx/md/txt）、粘贴文本、知识库/模板库链接均可。涉及文件读取或外部库时，按内部规则调用相应读取/检索能力，不向用户透传工具细节。

## 三、转化为「审查 Playbook」（规则库标准化）

把用户的规则/清单/Playbook/过往意见，统一成结构化规则项。每条规则用下面的字段表达：

| 字段 | 含义 |
|---|---|
| 规则编号 | R001、R002… 便于引用 |
| 适用范围 | 适用的合同类型/场景（如"所有采购合同""仅涉外") |
| 立场口径 | 本规则站在甲方/乙方/中立，强势/弱势（继承用户口径） |
| 审查点 | 要检查什么（如"付款条件""违约金上限""数据出境"） |
| 标准要求（期望条款） | 符合标准的理想表述/底线要求 |
| 风险等级 | 命中违反时的风险等级（高/中/低），继承用户分级 |
| **回退档（Fallback）** | 理想档 → 可接受档 → 触发红线档，逐级让步的边界 |
| **红线（绝不可越）** | 一旦突破必须否决或上报的硬约束 |
| 修改建议模板 | 命中问题时建议怎么改（可含建议措辞） |
| 来源 | 标注"用户提供：《XX规则》第X条"，便于追溯 |

### 3.1 从不同资料反向提炼规则

- **从显式规则库/清单**：逐条搬入，补齐缺失字段（如用户清单只写了审查点，帮其补"标准要求/红线"）。
- **从过往审查意见/批注合同**：每一处批注 = 一条隐含规则。把"这里付款周期太长，改为货到30天"反推成规则"采购合同付款周期>45天为高风险，标准为≤30天"。
- **从谈判纪律**：把"价格最多让5%""账期绝不超过60天"转成带回退档和红线的规则。

### 3.2 Playbook 产出物结构

```
【审查 Playbook · 来源：用户提供资料】适用范围：__
| 编号 | 适用范围 | 立场 | 审查点 | 标准要求 | 风险等级 | 回退档 | 红线 | 修改建议 | 来源 |
|---|---|---|---|---|---|---|---|---|---|
| R001 | 采购合同 | 甲方/强势 | 付款周期 | 货到≤30天 | 高 | 30→45→>60红线 | >90天否决 | 增逾期违约金日万分之X | 用户《采购风控清单》#3 |
| … |
```

> 转化完成后，须向用户**回执确认**：列出已识别的规则条数、关键红线，请用户确认或补充，再投入审查。

## 四、转化为「合同条款库」（模板标准化）

把用户的模板/范本/惯用条款，拆成 `contract-drafting-engine` 能直接拼装的结构（沿用其"固定法律条款 + 专属核心条款 + 可变商业要素"方法）：

### 4.1 拆解步骤

1. **识别合同类型**：判断每份模板属于买卖/服务/承揽/租赁/授权/合作等何种类型，作为入库分类。
2. **模块化拆条**：把模板拆成条款模块（定义、标的、价款支付、交付验收、权利义务、违约责任、知识产权、保密、争议解决、通知、生效签署等）。
3. **三分归类每个条款**：
   - **固定法律条款（锁定）**：保密、违约、不可抗力、争议解决等通用条款 → 入"基础条款库"。
   - **专属核心条款（可复用模块）**：标的、价款、特别权义等业务条款 → 入"该类型核心条款库"，保留用户的惯用表述。
   - **可变商业要素**：当事人、金额、日期、比例等 → 标准化为 `【】` 占位符 + 填写说明。
4. **保留用户偏好**：用户模板里的特殊措辞、特别约定、风格（如固定的管辖地、固定的违约金算法）作为该企业的偏好保留，不擅自替换成通用版。
5. **合规体检**：对入库条款做一次效力/时效校验（交 `contract-legal-research` 核对，警惕引用已废止的《合同法》条号、失效监管依据），发现问题标注但**不擅自改动用户条款**，而是提示风险供用户决定。

### 4.2 条款库产出物结构

```
【合同条款库 · 来源：用户模板】
分类架构：买卖 / 服务 / 采购 / 合作 / …
├─ 基础条款库（锁定·跨类型复用）：保密 / 违约 / 不可抗力 / 争议解决 / 通知 / 完整协议
├─ [采购合同] 核心条款模块：标的与规格 / 价款与支付 / 交付验收 / 质量保证 / …（保留用户惯用表述）
│    可变要素：【供方名称】【金额】【账期天数】【验收标准编号】…
├─ [服务合同] 核心条款模块：…
└─ 入库体检备注：R-第X条引用《合同法》已废止 → 建议切《民法典》第X条（待用户确认）
```

> 入库完成后同样**回执确认**：列出已入库的合同类型、条款模块数、体检发现的疑点，请用户确认。

## 五、与起草/审查引擎的衔接（标准如何被使用）

### 5.1 喂给审查引擎（C5/C6）

`contract-review-engine` 在逐条审查时，**先加载并应用用户 Playbook**：
- 用户 Playbook 规则项 = **第一优先审查标准**；逐条比对待审合同是否满足"标准要求"，命中"红线"直接标高风险/否决。
- 专家内置的四类风险核查（条款无效/权义失衡/核心利益缺保障/缺乏可执行性）作为**补充层**，覆盖 Playbook 没写到的点。
- 风险清单中标注每条风险的判断依据来自"用户标准 R0XX"还是"通用法律标准"，便于用户分辨。

### 5.2 喂给起草引擎（C3/C4/C9）

`contract-drafting-engine` 起草时，**优先从用户条款库拼装**：
- 命中类型后，先取用户条款库里对应的核心条款模块 + 基础条款，再用专属拟制补缺口。
- 用户没有覆盖到的条款，才用专家通用条款补齐，并标注"此条为通用补充，贵司模板未覆盖"。
- 保留用户惯用表述与偏好；通用补充条款明确区分，供用户取舍。

### 5.3 优先级总则

```
用户提供标准（Playbook / 条款库） ＞ 专家内置通用标准
            ↓ 专家在用户标准基础上做：查漏 → 补强 → 合规体检（提示不擅改）
```

## 关键约束

- **主动告知一次**：起草/审查场景须让用户知道"可提供自有模板/规则/Playbook"，但不强制、不反复催。
- **用户标准优先**：用户提供的条款库/Playbook 优先于内置默认；专家做增补与体检，不擅自推翻用户偏好。
- **不擅改用户条款**：入库体检发现效力/合规疑点时，标注并提示，由用户决定是否调整，不直接替换。
- **真实转化，不臆造**：只标准化用户**真实提供**的内容；用户没给的规则/条款不得假托"贵司标准"编造，缺口用通用标准并明确标注来源。
- **回执确认**：Playbook 与条款库转化完成后，向用户回执（规则条数/入库类型/疑点），确认后再投入起草/审查。
- **来源可追溯**：每条规则、每个条款模块标注来源（用户某文档第X条 / 通用补充），审查与起草成果中可区分标准来源。
- **不暴露工具状态**：读取附件/外部库的工具选择过程不向用户透传。

## References

- `references/playbook-and-clause-templates.md` — 审查 Playbook 规则项模板、合同条款库结构模板、过往审查意见反向提炼规则示例