# Contract Drafting Engine

> Draft contracts, build template libraries, and write supplementary agreements (scenarios C3/C4/C9). Use this skill after intake and research to deconstruct the deal structure and commercial logic, identify the contract type, choose a contract structure package, assemble locked general clauses with bespoke core clauses, and add risk annotations to non-standard/high-risk clauses — producing a complete contract text with clearly separated fixed legal clauses and fillable commercial variables.

- Skill: `infometa/contract-drafting-engine` (Agent Skill)
- Install (CLI): `npx skillmds@latest add infometa/contract-drafting-engine`
- Raw SKILL.md: https://api.skillmd.com/api/skills/infometa/contract-drafting-engine/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: infometa (https://skillmd.com/u/infometa)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/infometa/contract-drafting-engine

---


# 合同 · 起草引擎

> 这是合同专家的**起草工序**，承接交易事实清单与检索依据，覆盖具体合同起草（C4）、合同模板库建设（C3）、补充协议起草（C9）。核心是把商业意图严谨地翻译成有约束力、能执行、风险可控的合同条款。

## 一、起草前两道必经分析（不可跳过）

### 1.0 优先加载用户条款库（若有）

起草开工前，先确认用户是否提供了自有模板/范本/惯用条款。

- **若用户已提供**：交 `contract-standards-ingest` 转化为「合同条款库」后**优先拼装**——命中类型后先取用户条款库里对应的核心条款模块 + 基础条款，再用专属拟制补缺口；用户未覆盖的条款才用通用条款补齐，并标注"此条为通用补充，贵司模板未覆盖"。保留用户惯用表述与偏好，不擅自替换成通用版。
- **若用户未提供**：开工前**主动一句话告知**可提供自有模板（"贵司若有合同模板/惯用条款，可发我，我会优先按贵司模板起草，更贴合业务"），不强制；用户不提供就用专家通用条款体系起草。
- **优先级**：用户条款库（第一层） ＞ 专家通用条款（补充层）。成稿中区分标注两类来源。

### 1.1 交易结构与商业逻辑拆解（能力④）

把一笔交易拆透，是写对合同的前提。按六个维度拆解：

| 维度 | 拆解内容 |
|---|---|
| 主体 | 谁和谁签？各自法律地位（甲/乙/丙）、是自然人还是公司、是否需引入第三方 |
| 标的 | 交易对象是什么（货物/服务/成果/权利），范围与边界 |
| 资金流向 | 谁付钱给谁、金额、计价方式、付款节点、是否有保底/分成/预付/尾款 |
| 权利义务分配 | 各方各自要做什么、享有什么权利、承担什么义务 |
| 商业闭环 | 交易从开始到结束的完整链条，钱与货/服务如何对流 |
| 交易时间轴 | 从签约到履行完毕的时间顺序与关键节点 |

> 拆解产出一张「交易结构图（文字版）」，作为选结构、定条款的依据。

### 1.2 合同类型识别与审查点拆解（能力⑤）

1. **类型识别**：把商业需求映射到准确的合同类型——参照 `contract-legal-research` 的合同类型速查表，判断属于买卖/服务/承揽/租赁/技术/授权许可/合作等何种有名合同，或为复合/无名合同。
2. **必备条款与审查点拆解**：命中类型后，逐项罗列该类型的**法定必备条款 + 行业惯例条款 + 本案特殊条款**，形成一张"本合同应当包含的条款清单"。这张清单同时是起草的骨架和后续自查的标尺。

> 复合交易（如"授权+设计+运营+分成"）须拆成多个法律关系分别识别类型，再决定用一份综合合同还是主合同+附件。

## 二、合同结构套餐选择（C4）

据交易频率和复杂程度，为用户选择合同结构（参照场景决策表 C4 工作流）：

| 交易特征 | 推荐结构 | 说明 |
|---|---|---|
| 单次独立交易 | **完整主合同** | 一份合同覆盖全部权义 |
| 长期持续交易 | **框架协议 + 订单** | 框架定通用规则，每次交易下订单 |
| 复杂技术/服务交易 | **主合同 + 附件清单** | 主合同定框架，附件细化技术规格/SOW/价目表 |

## 三、条款组装：固定法律条款 + 可变商业要素

每份合同/模板都拆成两部分，这是模板库与起草的核心方法。**条款来源优先级：用户条款库（若已加载） ＞ 专家通用条款库**——优先取用户惯用条款模块，缺口才用通用补齐并标注来源。

### 3.1 通用基础条款（后台锁定，不随意改）
优先从**用户条款库的基础条款库**调用（保留其惯用管辖地、违约金算法等偏好）；用户未覆盖的，再从专家通用条款库定向调用，包括：定义条款、保密义务、知识产权、违约责任、不可抗力、争议解决与管辖、通知送达、合同生效与变更解除、完整协议条款等。

### 3.2 专属核心条款（按本案拟制）
针对本交易的商业诉求，用严谨法言法语把权利义务转化为具体条款：标的与范围、价款与支付、交付与验收、各方特别权义、排他/独家、成果归属等。

### 3.3 可变商业要素（供用户填写，用占位符）
当事人名称、金额、数量、日期、比例等具体值，一律用 `【】` 占位，并在文末"需你填写/确认的要素清单"统一列出。**严禁编造具体当事人名称、金额冒充用户真实信息。**

## 四、完整合同文本结构骨架

```
合同标题
一、缔约主体（甲方/乙方……基本信息，可变要素占位）
二、鉴于条款/背景（交易目的与基础事实）
三、定义条款（如需）
四、标的与范围
五、价款/费用与支付方式
六、各方权利义务（核心专属条款）
七、交付/履行/验收
八、知识产权 / 成果归属（如适用）
九、保密
十、违约责任
十一、合同的变更、解除与终止
十二、不可抗力
十三、争议解决与管辖
十四、其他（通知、完整协议、附件效力等）
十五、生效与签署区（落款、盖章、日期占位）
[附件清单（如采用主合同+附件结构）]
```

## 五、风险批注（能力⑥的关键产出）

对以下条款，在合同文本中添加客观、清晰的风险提示批注（如用【风险提示】标注）：
- 突破常规商业惯例的条款
- 对本方明显不利或义务过重的条款
- 需用户重点关注并严格履行的环节（如付款前置条件、验收时限、通知义务）
- 存在效力风险的条款（可能被认定无效/可撤销）
- 留白待商务谈判确定的关键点

> 批注只揭示风险、说明依据与后果，**不替用户拍板商业取舍**。

## 六、模板库建设（C3）

按场景决策表 C3 工作流执行：
0. **优先消化用户已有资料**：若用户已有模板、范本、惯用条款，先交 `contract-standards-ingest` 转化为合同条款库作为底座，在其基础上扩建，而非从零另起；用户没有的部分才新建。
1. 梳理核心业务场景，确定模板库的**合同类型分类架构**（如买卖、租赁、服务、采购、合作等大类）。
2. 按各大类的交易时间轴与商业闭环，起草专属核心结构组块条款。
3. 提取通用规则（保密、违约、争议解决）做成**统一基础条款库**。
4. 拼装基础条款 + 专属条款，每份模板拆成"固定法律条款 + 可变商业要素"。
5. 对初代模板做**合法性与合规性审查**（交 `contract-review-engine` 或自查效力风险清单），确认无违反强制性规定后定稿。
6. 分类入库，建立**定期更新机制**（跟踪法律法规变化）。
7. 编制**模板调用操作指引**（如何填入交易对象、金额、付款时间等一键生成正式文本）。

交付物：模板库结构体系（分类架构）+ 各类型模板条款目录 + 具体模板文本 + 调用指引。

## 七、补充协议起草（C9）

按场景决策表 C9 工作流执行：
1. 核对原生效合同文本，确认需变更/增删的条款与类型。
2. **评估变更影响**：是否触发新合规风险、是否改变违约责任/争议解决机制、是否与原合同其他条款冲突。
3. 起草《补充协议》，明确：变更条款的具体措辞 + 生效条件 + 与原合同的关系说明（"本补充协议与原合同冲突的以本协议为准，未变更部分继续有效"）。
4. 给出**签署流程建议**：按原合同同等授权层级走内部审批与用印；签署后原件与原合同归集封存，更新电子档案与履约台账。

补充协议结构骨架：
```
补充协议标题（载明对应原合同名称与编号）
鉴于条款（原合同基本情况 + 变更缘由）
一、变更/新增/删除的具体条款
二、生效条件与生效日期
三、与原合同的关系
四、其他
签署区
```

## 关键约束

- **用户条款库优先**：用户已提供模板/惯用条款时，优先拼装其条款库、保留其偏好；通用条款仅作缺口补充并标注来源。
- **主动告知**：用户未提供模板时，开工前主动告知可提供（一次，不强制）。
- **先拆解、识别类型，再落条款**：不得跳过交易结构拆解和合同类型识别直接拼模板。
- **法律依据真实检索**：条款引用的法条、强制性规定来自 `contract-legal-research` 真实检索，标注现行效力（《合同法》已废止，引《民法典》）。
- **不臆造商业要素**：具体当事人、金额、日期一律占位，文末列出待填清单。
- **风险批注客观克制**：揭示风险不替用户决策。
- **成稿后交付**：定稿交给 `contract-output-formatter` 适配交付形态。

