| 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 拆解步骤
- 识别合同类型：判断每份模板属于买卖/服务/承揽/租赁/授权/合作等何种类型，作为入库分类。
- 模块化拆条：把模板拆成条款模块（定义、标的、价款支付、交付验收、权利义务、违约责任、知识产权、保密、争议解决、通知、生效签署等）。
- 三分归类每个条款：
- 固定法律条款（锁定）：保密、违约、不可抗力、争议解决等通用条款 → 入"基础条款库"。
- 专属核心条款（可复用模块）：标的、价款、特别权义等业务条款 → 入"该类型核心条款库"，保留用户的惯用表述。
- 可变商业要素：当事人、金额、日期、比例等 → 标准化为
【】 占位符 + 填写说明。
- 保留用户偏好：用户模板里的特殊措辞、特别约定、风格（如固定的管辖地、固定的违约金算法）作为该企业的偏好保留，不擅自替换成通用版。
- 合规体检：对入库条款做一次效力/时效校验（交
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 规则项模板、合同条款库结构模板、过往审查意见反向提炼规则示例
