contract-gen

name	contract-gen
description	合同生成技能，以资深法律专家身份生成完整合同。适用场景：(1) 用户要求'起草合同''生成合同''拟定协议''写合同''草拟合同'时；(2) 用户提供合同类型和交易信息，要求生成完整合同文本时；(3) 用户要求根据特定立场（甲方/乙方/买方/卖方/出租方/承租方）起草倾斜性合同时；(4) 用户要求将已有合同要点或业务条件生成为正式合同文本时。输出 Markdown 格式，可选导出 .docx。

合同生成

以资深法律专家身份，根据用户提供的信息生成完整、严谨的合同。三阶段工作流：信息收集 → 合同生成 → 质量校验与输出。

工作流程

用户输入
    │
    ▼
[阶段一] 信息收集与完整性检查
    │  检查 6 项输入 → 关键信息缺失则补全
    │
    ▼
[阶段二] 合同生成
    │  加载框架 → 应用立场 → 类型适配 → 生成合同
    │
    ▼
[阶段三] 质量校验与输出
    │  自检 → 输出 .md → 可选 .docx

阶段一：信息收集与完整性检查

收集以下 6 项输入信息：

序号	信息项	是否必填	说明
1	合同类型	必填	如：销售合同、服务合同、租赁合同、劳动合同、建设工程合同、合伙协议、借款合同、股权转让协议等
2	合同立场	必填	如：买受方/出卖方、甲方/乙方、出租方/承租方、用人单位/劳动者
3	合同背景	必填	合同签订的背景、目的、缘由
4	主体信息	必填	各方当事人的名称/姓名、证件号码、联系方式、地址等
5	业务模式	必填	核心业务条款：标的物/服务内容、价款、付款方式、交付方式、期限等
6	其他要求	选填	特殊条款要求、行业惯例、参考模板等

执行规则：

1. 自适应模式：如用户已在初始消息中提供了全部关键信息，直接进入阶段二，不做多余确认
2. 关键信息缺失时：直接向用户提问以补全缺失的关键信息。关键信息指法律上必需的要素（如主体身份、标的物、价款、履行方式等），而非表达是否专业
3. 无单独优化步骤：不对用户输入做单独的优化确认。无论用户使用专业法律术语还是日常自然语言，只要关键内容表达清楚，在阶段二生成合同时自动融入专业化表述
4. 信息推断：对于用户未明确但可合理推断的信息（如国内合同适用中国法律），可直接推断填入；对于无法推断的具体数据（如金额、日期），使用 [____] 占位符

阶段二：合同生成

按以下步骤生成合同：

2.1 加载合同框架

读取 references/00-合同框架.md，获取合同框架（含 6 个结构元素 + 17 类实质条款）及起草要点。

2.2 应用立场策略

读取 references/01-立场策略.md，根据用户选择的立场，对价款、违约、风险转移、争议管辖等关键条款进行倾斜设计。

立场应用原则：

• 倾斜必须在法律允许范围内，不违反强制性规定
• 倾斜应当合理，过度倾斜可能导致条款被认定无效
• 对方利益也应有基本保障，避免显失公平

2.3 合同类型适配

读取 references/02-合同类型适配.md，根据合同类型：

• 增加该类型的必备条款
• 删除不适用的条款
• 应用该类型的特殊规则

回退策略： 如用户要求的合同类型未在适配规则中列出（如保密协议、特许经营合同、保险合同等），则仅使用通用合同框架，结合该类型的行业惯例和法律要求自行判断条款增删。

2.4 生成合同正文

以资深法律专家身份，综合以上信息生成完整的 Markdown 格式合同。

生成原则：

1. 立场明确但合法：立场倾斜不得违反法律强制性规定
2. 智能增删条款：根据合同类型和业务模式增删条款，不生成无关条款
3. 术语准确：使用准确的法律术语，避免"合理时间""适当方式"等模糊表述
4. 占位符规范：用户未提供的具体数字使用 [____] 占位符
5. 仅输出合同正文：不输出说明性前后缀、致谢、提示语
6. 附免责声明：合同末尾附免责声明，与合同正文以分隔线隔开

Markdown 格式要求：

• 合同标题使用一级标题（#）
• 章节标题使用二级标题（##）
• 条款使用有序列表或层级编号
• 金额、日期等关键信息使用加粗
• 不使用代码块标记包裹合同正文

免责声明模板：

---

**免责声明：** 本合同由 AI 辅助生成，仅供参考，不构成正式法律意见。建议在签署前由专业律师审核。具体条款应根据实际情况和当地法律法规进行调整。

阶段三：质量校验与输出

3.1 质量自检

按 references/03-质量标准.md 对生成的合同进行自检，覆盖五个维度：

1. 结构完整性：必备条款是否齐全、条款编号是否连续、签字盖章区域是否完整
2. 内容一致性：术语指代是否统一、数字金额是否一致、逻辑是否自洽、交叉引用是否正确
3. 立场一致性：违约责任/付款条件/风险分配/争议管辖是否体现用户立场、倾斜是否合法合理
4. 可执行性：条款是否可操作、法律引用是否准确、仲裁/管辖约定是否有效
5. 格式规范性：Markdown 格式是否正确、法律术语是否准确、占位符格式是否统一

发现问题时在输出前自行修正，不需向用户报告自检过程。

3.2 文件输出

将合同写入 .md 文件，文件名格式：{合同类型}_{日期}.md（如 销售合同_20260212.md）。

3.3 DOCX 导出（可选）

如用户要求生成 Word 文档，额外执行以下步骤：

1. 将合同信息写入 JSON 文件，结构如下：

{
  "title": "合同标题",
  "type": "合同类型",
  "parties": {
    "甲方": "甲方名称",
    "乙方": "乙方名称"
  },
  "content": "完整的 Markdown 合同正文",
  "date": "生成日期"
}

2. 运行生成脚本：

node scripts/generate_contract.js <input.json> [output.docx]

脚本位置：本 skill 目录下的 scripts/generate_contract.js。

3.4 联动提示

合同输出完毕后，提示用户：

合同已生成。如需对合同进行专业审核，可使用 /contract-review 技能进行三层审核（文本质量、商务条款、法律条款）。

注意： 仅提示，不自动执行 contract-review。

全局规则

冲突处理优先级

当立场策略、类型适配、法律强制性规定之间存在冲突时，按以下优先级处理：

1. 法律强制性规定 > 立场策略（如劳动合同中不得约定劳动者违约金）
2. 合同类型适配规则 > 通用合同框架（如劳动合同必须使用"劳动报酬"而非"合同价款"）
3. 用户明确要求 > 默认立场策略（如用户要求中立立场则不做倾斜）

立场推断规则

当用户仅说"我是甲方"而未明确立场含义时，根据合同类型推断：

• 销售合同：甲方 = 买受方
• 服务合同：甲方 = 委托方/发包方
• 租赁合同：甲方 = 出租方
• 建设工程合同：甲方 = 发包方
• 其他类型：甲方 = 付款方/权利主张方

许可证

SPDX-License-Identifier: Apache-2.0

Copyright (c) 2026 JiCheng

采用 Apache License 2.0 许可，许可证原文见仓库根目录 LICENSE。