Fadada Professional Contract Drafting

---
name: 法大大专业合同起草
name_en: fadada-professional-contract-drafting
version: 1.0.0
description: 合同智能起草专用 skill。当用户需要起草、撰写、生成合同文本时必须使用本 skill，包括但不限于：
  - 用户说"帮我起草一份合同"、"写一份协议"、"生成合同"、"起草合同正文"等
  - 用户提供了甲乙双方信息、合同目的、核心条款需求，希望生成完整合同文本
  - 用户上传了合同模板文件，希望按模板框架填入自己的具体业务内容
  - 用户上传了标书、参考合同、行业标准等参考文件，要求据此起草合同
  - 用户说"用模板起草"、"按照这个格式帮我写合同"、"参考这份合同帮我起草"等
  - 即使用户只说"我需要一份采购合同"或"帮我写个保密协议"，也应触发本 skill
  本 skill 支持三种模式：①自然语言描述起草 ②上传模板+描述需求填空起草 ③上传参考文件辅助起草。
---

# 合同智能起草 Skill

## 概述

本 skill 指导智能体根据用户提供的合同背景信息，智能分析并起草完整、专业的合同文本。起草流程分三步：**信息理解 → 合同大纲 → 合同正文**。

---

## 第一步：判断起草模式

**首先判断用户是否上传了文件**，据此进入不同分支。

在进入各模式之前，先完成**意图澄清判断**：

---

### 意图澄清：何时发起结构化澄清

优先使用**当前运行环境提供的结构化交互能力**发起澄清（如桌面端可选项窗口）。若当前环境**没有**该能力，则改为用**一句简短自然语言问题**澄清后继续，不得因缺少弹窗工具而中断起草流程。

以下情况应先澄清，不得自行假设后直接起草：

#### 情况一：上传了单个文件，但意图不明

触发条件：用户上传文件后，描述语句中**没有**出现"模板"、"套用"、"参考"、"按这个格式"等明确意图词，且文件内容读取后**既可能是模板也可能是参考材料**（如：一份完整的合同文本，但不确定用户是要套用它还是参考它）。

澄清问题：
```
question: "您上传的这份文件，您希望如何使用？"
options:
  - "套用它的框架和条款结构，填入我的业务信息"   → 进入模式二
  - "仅作为参考背景，请帮我重新起草一份"         → 进入模式三
```

#### 情况二：上传了多个文件，角色不明

触发条件：用户上传了 2 个及以上文件，且未说明各文件的用途。

澄清问题：
```
question: "您上传了多份文件，请问它们的用途是？"
options:
  - "其中一份是模板，其余是参考材料"
  - "全部都是参考材料，请综合起草"
  - "让我来分别说明一下"
```

> 若用户选择"其中一份是模板"，则进行第二轮澄清：
> ```
> question: "请问哪份文件是您要套用的模板？"
> options: [列出上传文件的文件名供用户点选]
> ```

#### 情况三：合同类型不明，且无法从上下文推断

触发条件：用户描述过于简短（如仅说"帮我起草个合同"），**既没有上传文件**，也没有任何关于交易类型、业务场景的描述。

澄清问题：
```
question: "请问您需要哪类合同？"
options:
  - "服务 / 委托合同"
  - "采购 / 买卖合同"
  - "保密协议（NDA）"
  - "其他（我来描述）"
```

> 若信息仍不足以判断（比如用户选了"其他"后描述依然模糊），可**再追问一次**，但**最多澄清 2 次**，之后根据已有信息做出合理假设并继续，不得反复追问。

#### 何时**不需要**弹出，直接判断进入模式

- 用户描述中有明确意图词：直接进入对应模式
- 文件名或文件内容已能明确区分用途（如文件名含"模板"、"template"、"标书"等）
- 用户上传文件的同时提供了充分的业务描述，说明是要填入的内容：直接进入模式二

---

### 模式一：纯描述起草（无上传文件）

用户以自然语言或结构化方式描述需求，由智能体从零起草。

**参考输入格式**（用户也可自由描述）：
```
帮我起草一份[合同类型]，
我方为[甲方/乙方、名称、联系方式等]，
相对方为[甲方/乙方、名称、联系方式等]。
本合同目的是[项目/业务/交易说明]，
合同中需明确[标的、费用与支付、双方权利义务、违约责任、争议解决等]。
本合同我方核心要求为[如保密义务、验收标准、知识产权归属等]。
```

提取信息后 → 进入第二步（起草大纲）→ 第三步（起草正文）。

---

### 模式二：上传合同模板 → 填空起草

用户上传了一份**合同模板**（自己公司的标准合同、行业范本等），希望保留模板的框架和条款结构，将自己的业务信息填入其中。

**识别特征**：用户说"用这个模板"、"按这个格式"、"参照这份合同"，或上传文件后描述的是具体业务信息而非起草要求。

**执行步骤**：

1. **读取模板文件**
   - 若为 DOCX/PDF 文字层：直接提取全文结构
   - 若为扫描件 PDF（无文字层）：调用 `fadada-scanned-ocr` skill 先做 OCR，再提取结构
   - 提取模板的：章节结构、空白占位符（如"___"、"【】"、"[  ]"）、固定条款、可变条款

2. **分析模板框架**，向用户简要确认：
   ```
   已读取您的合同模板，框架如下：
   - 合同类型：___
   - 共 X 条，主要条款：[列举核心条款名称]
   - 需要填入的关键信息：[列出空白项，如甲乙方名称、金额、期限、服务内容等]
   
   请确认是否按此框架起草，或说明需要调整的地方。
   ```

3. **提取用户描述中的业务信息**，对照模板空白项逐一匹配填充

4. **处理模板未覆盖的用户需求**：
   - 若用户有模板中不存在的条款需求（如特殊的知识产权约定），在对应位置**新增条款**并注明"【新增】"
   - 若模板某条款与用户需求冲突，**保留用户需求版本**并注明"【已调整】"

5. 输出完整合同正文，末尾附【调整说明】，列出新增或修改的条款及原因

---

### 模式三：上传参考文件 → 辅助起草

用户上传的是**参考材料**（项目标书、行业标准、对方给的草稿等），不是要直接套用的模板，而是作为起草的上下文和依据。

**识别特征**：上传的是标书、招标文件、技术方案、对方合同草稿等，用户说"参考这个"、"根据这份材料"。

**执行步骤**：

1. **调用 `fadada-contract-extractor` skill 提取文件中的结构化信息**
   - 若待抽取文件为扫描件，可先调用 `fadada-scanned-ocr` 获取正文文本；若 extractor 自身预处理链路已覆盖该步骤，则按其既有链路执行，不在本 skill 中重复抽取
   - 运行**基本信息模式**，提取甲乙方、金额、期限、标的、交付物等字段
   - 若参考文件本身是一份合同草稿（如对方提供的版本），可同时运行**履约信息模式**，抽取付款节点、交付安排等事件作为起草依据
   - 若参考文件是标书、技术方案等**非合同文件**，只跑基本信息模式，不运行履约信息模式（此类文件缺乏合同履约结构，履约抽取无意义）
   - 抽取字段使用 `fadada-contract-extractor` 的系统默认字段，无需额外指定

2. 将抽取结果与用户的文字描述**合并补全**，形成完整的合同要素清单（抽取结果优先，用户描述补充缺失项）

3. 按模式一的流程：起草大纲 → 起草正文，以合并后的信息为事实依据填充各条款

---

### 模式二的信息提取补充

模式二（模板填空）中，若用户**同时上传了模板文件和其他业务材料**（如同时上传了"我司标准服务合同.docx"和"项目标书.pdf"），则：

- 对**模板文件**：读取框架结构，不调用 extractor
- 对**业务材料**：调用 `fadada-contract-extractor` 基本信息模式抽取填充所需字段
- 将抽取结果对照模板空白项逐一填入

---

### 信息提取清单（三种模式通用）

| 信息类别     | 提取内容                                           |
| ------------ | -------------------------------------------------- |
| 合同类型     | 服务合同、采购合同、保密协议、劳务合同、租赁合同等 |
| 合同立场     | 偏甲方 / 偏乙方 / 中性，或买方 / 卖方等具体立场    |
| 甲方信息     | 名称、角色（买方/卖方/委托方等）、联系方式         |
| 乙方信息     | 名称、角色、联系方式                               |
| 合同标的     | 服务内容/商品/项目/许可等具体描述                  |
| 费用与支付   | 合同总价、支付方式、付款节点                       |
| 合同期限     | 起止时间、履约周期                                 |
| 我方核心要求 | 保密、验收标准、知识产权、违约责任侧重等           |
| 上传文件     | 文件类型（模板/参考材料）、文件质量（是否可读）    |

---

## 起草控制变量

### 合同立场

- 用户明确说明“我方是甲方 / 乙方 / 买方 / 卖方 / 委托方 / 受托方”等时，按该立场起草
- 用户未明说但上下文可推断时，可直接推断，并在大纲中点明角色
- 若立场仍不清楚，优先澄清；无法澄清时按中性版本起草，不擅自明显倾斜风险分配

---

## 第二步：起草合同大纲

在生成正文前，必须先完成合同大纲规划。该大纲作为内部组织步骤使用；若用户未要求查看大纲，则不要把 Markdown 大纲作为最终交付内容写入 docx。格式如下：

```
## 【合同名称】起草大纲

**合同类型**：___
**甲方**：___（角色：___）
**乙方**：___（角色：___）

### 章节结构

第一条 定义与解释
第二条 合同标的
第三条 合同价款与支付方式
第四条 履约期限与交付
第五条 双方权利与义务
  - 甲方权利义务
  - 乙方权利义务
第六条 验收标准与程序（如适用）
第七条 知识产权归属（如适用）
第八条 保密条款（如适用）
第九条 违约责任
第十条 不可抗力（如适用）
第十一条 合同变更与解除
第十二条 争议解决
第十三条 其他约定
第十四条 附则（签署页）

**我方核心保护条款重点**：___
**待补充信息**：___（如有）
```

> 根据合同类型灵活调整章节，如保密协议可简化为5-7条，工程合同可增加质量保证、安全生产等专项条款。

### 大纲生成规则

- 若用户已提供章节结构、模板章节或明确目录，**必须优先保留该结构**，仅补足缺失的必要章节并优化命名和顺序
- 若用户未提供结构，则根据合同类型、合同立场和核心交易条款生成完整大纲
- 大纲默认控制在**两级结构**内；除非用户明确要求，不再向下细分三级标题
- 大纲中不要单独设置“各方基本信息”“合同份数”“签字盖章”之类章节；这些内容属于正文抬头、尾部或签署页
- 各章节之间不得明显重叠；付款、验收、知识产权、保密、违约责任、争议解决等高冲突条款应各自独立
- 若需要更细的大纲编号或二级标题描述写法，参见 `references/outline-generation.md`

---

## 第三步：起草合同正文

### 起草原则

1. **法律规范性**：条款表述严谨，使用法律惯用语，符合《中华人民共和国民法典》合同编及相关法规要求
2. **我方利益保护**：在平等原则下，重点强化用户标注的核心要求条款
3. **完整性**：每个章节均需实质性内容，不得出现空置条款
4. **可执行性**：金额、期限、标准等关键信息明确量化，避免模糊表述

### 正文格式规范

```
[合同名称]

合同编号：___________

甲方：___________
地址：___________
联系人：___________
电话：___________

乙方：___________  
地址：___________
联系人：___________
电话：___________

鉴于甲乙双方本着平等自愿、诚实信用的原则，经友好协商，就[合同事项]达成如下协议：

第一条 【条款名称】
  1.1 ...
  1.2 ...

第二条 【条款名称】
  ...

[各条款正文]

本合同一式___份，甲乙双方各执___份，具有同等法律效力。

甲方（盖章）：___________     乙方（盖章）：___________
法定代表人（签字）：_______   法定代表人（签字）：_______
日期：___年___月___日         日期：___年___月___日
```

具体可参见`references/chapter-drafting.md`

### 正文生成规则

- 正文必须严格围绕已确认的大纲展开，不为了“看起来完整”而加入与当前交易弱相关的低价值通用条款
- 必须体现合同立场，在付款条件、验收标准、知识产权、保密义务、违约责任、解除权、争议解决等关键位置进行一致的风险分配
- 正文中的主体称谓统一使用“甲方”“乙方”“丙方”或“买方”“卖方”等角色称谓；除抬头、签署页或模板保留位置外，不重复写主体全称
- 缺失但必须保留的位置，统一使用 `【】` 或模板中的既有占位方式，不编造事实
- 若用户提供了参考法规或明确要求引用特定规范，仅能依据已提供材料或可确认的现行规则表述；不要编造具体法条号或不存在的规范依据
- 若按章节逐段起草，或要处理“当前章节”和“参考材料”之间的取舍，参见 `references/chapter-drafting.md`

### 关键条款起草要点

参见 `references/clause-guidelines.md` 了解各类核心条款的起草要点与示例。

---

## 执行流程

```
读取用户输入
        ↓
意图澄清（必要时发起结构化澄清；若无该能力则简短追问）
        ↓
判断是否有上传文件？
    ├── 无文件
    │   → 【模式一】从描述提取信息 → 大纲 → 正文
    │
    ├── 有文件，是合同模板
    │   → 【模式二】读取模板结构 → 确认框架
    │       ├── 若同时有业务材料 → 调用 fadada-contract-extractor（基本信息模式）→ 填空起草
    │       └── 若只有模板 → 从用户描述提取信息 → 填空起草
    │
    └── 有文件，是参考材料
        → 【模式三】调用 fadada-contract-extractor
            ├── 非合同文件（标书/方案）→ 只跑基本信息模式
            └── 合同草稿 → 基本信息模式 + 履约信息模式
        → 合并用户描述 → 大纲 → 正文
        ↓
正文末尾注明【待补充信息清单】（如有缺失字段）
模式二额外附【调整说明】（列出新增/修改条款）
```

> **注意**：
> - 模式一/三：信息充分时大纲+正文连续输出；合同类型不明、双方主体不清时先发起结构化澄清；若当前环境无该能力，则用一句自然语言确认
> - 模式二：读取模板后**必须先向用户确认框架**，再进行填空起草；确认方式同样优先使用结构化澄清，不具备时退化为自然语言确认
> - 调用 `fadada-contract-extractor` 时，字段使用其系统默认字段，不需要额外指定；extractor 负责信息抽取。若待抽取文件为扫描件，可先调用 `fadada-scanned-ocr` 获取正文文本，或按 extractor 的既有预处理链路执行

---

## 输出交付

### 默认行为（用户未指定格式时，文件优先）

合同正文起草完成后，默认以**文件交付为主**，按以下顺序执行：

1. **自动生成 Word 文件**：调用 `docx` skill，按以下要求生成 `.docx` 文件
2. **对话窗口回执**：简要告知合同名称、交付模式、输出文件路径和待补充信息；除非用户明确要求，不在窗口重复输出完整正文

> 默认保存目录为**当前工作目录**；若用户明确指定保存路径，则以用户路径为准。文件命名规则：`【合同名称】_草稿_YYYYMMDD.docx`，无法获取合同名称时命名为 `合同草稿_YYYYMMDD.docx`。

#### 调用 `docx` skill 的执行要求（必须遵守）

**必须使用 `docx` skill 的 "Creating a new Word document" 工作流**，即读取 `docx-js.md` 后编写 JavaScript 脚本用 docx-js 生成文件。**严禁**直接将合同文本写入 `.docx` 文件——那样打开后只会显示原始文本，不是合法的 Word 文档格式。

**排版格式**：严格按照 `references/chapter-drafting.md` 中"行文排版格式规范"一节执行，包括：
- 字体：合同名称宋体加粗二号居中；甲乙方信息、正文、小标题均为仿宋四号；编号和数字用 Times New Roman
- 段落：正文首行缩进 2 字符，行距固定值 25 磅；合同名称行距固定值 28 磅；表格单倍行距
- 页边距：上 2.5cm、下 2.5cm、左 3cm、右 2.5cm
- 页码：底端居中，Times New Roman 五号，页脚距底端 1cm

**内容清洗**：传给 docx-js 前须去除所有 markdown 语法符号（`**`、`#`、`---`、`-` 列表前缀），占位符 `【】` 和 `___` 保留原样。

**回复规范**：排版格式属于后台默认处理，**不得**在对话回复中列出或说明任何排版参数（字体、行距、页边距等）。回执只需告知文件名和保存路径。

### 用户指定格式时

| 用户说                            | 执行动作                                                     |
| --------------------------------- | ------------------------------------------------------------ |
| "只在窗口看就行" / "不用生成文件" | 仅窗口展示，不生成 Word                                      |
| "给我 Word" / "保存文档" / "下载" | 生成 `.docx` 文件并返回保存路径；用户要求时再在窗口展示全文  |
| "给我 PDF"                        | 调用 `pdf` skill 生成 `.pdf` 文件，默认保存到**当前工作目录**，并返回保存路径 |

### 模式二（模板填空）的特殊处理

若用户上传的模板是 `.docx` 格式，**不得修改原模板文件**。调用 `doc` skill 新建一份文档，以模板的样式和结构为参照重新排版，将填入内容写入新文件，原模板保持不变；若用户明确指定保存路径，则按用户路径输出。

## 常见合同类型参考

| 合同类型      | 核心条款重点                            |
| ------------- | --------------------------------------- |
| 服务合同      | 服务范围、交付物、验收标准、服务期限    |
| 采购/买卖合同 | 货物规格、数量、质保期、交货方式        |
| 保密协议(NDA) | 保密信息定义、保密期限、违约金          |
| 软件开发合同  | 需求文档、里程碑、知识产权归属、BUG修复 |
| 劳务/外包合同 | 工作内容、结算方式、社保责任            |
| 租赁合同      | 租赁物状态、租金、押金、维修责任        |
| 合作协议      | 合作范围、收益分配、退出机制            |

---

## 注意事项

- 本 skill 生成的合同为**参考草稿**，建议用户根据实际情况调整，重要合同建议法律专业人士审核
- 涉及特殊行业（金融、医疗、建工等）时，需提示用户注意行业监管合规要求
- **模式二（模板填空）原则**：最大程度尊重模板原有条款和结构，仅在用户有明确需求时新增或修改条款，每处改动须标注说明
- 若用户上传文件无法读取（加密、损坏，或经 OCR 后仍不可识别），立即告知用户，请其提供可读版本