Keplerjai Contract Draft

SKILL.md

---
name: keplerjai-contract-draft
description: 基于 Word 模板和结构化业务信息生成合同草稿。适用于 AI 总助根据现有 .docx 模板起草合同、填充甲乙方与合作信息、识别缺失字段并输出可审阅草稿的场景。
---

# KeplerJAI 合同起草

当目标是“基于现有 Word 模板 + 业务事实生成合同草稿”时使用这份 skill，而不是在没有模板的情况下凭空定稿法律文本。

## 核心分工

1. OpenClaw 负责理解需求、检查模板、起草正文改写方案，并生成结构化 JSON job spec。
2. `scripts/contract_runner.py` 负责稳定执行 `.docx` 修改、输出草稿和校验产物。

当稳定 runner 已能处理任务时，不要再临时生成 `_draft_v1.py`、`_draft_v2.py` 这类一次性脚本。

## 执行主线

默认按以下顺序执行：

1. 检查模板与用户输入
2. 判断需要联动修改的章节
3. 生成一份 UTF-8 编码的 JSON job spec
4. 执行 `python scripts\contract_runner.py --spec <job-spec.json>`
5. 检查生成的 `.docx`、`未决事项清单.md`、`run-summary.json`、`validation-report.json`

一旦 JSON job spec 成功写出：

1. 不要反复重写同一份 spec
2. 必须立刻执行 runner
3. 如果 runner 失败，要返回具体失败点，而不是重复状态文本

## OpenClaw 必须做的事

1. 检查源模板
2. 理解用户请求
3. 判断哪些章节需要联动修改
4. 搜集甲乙方公司介绍，并各自压缩为约 150 字的正式摘要
5. 根据合作主题起草合作内容正文
6. 生成符合 runner 要求的 JSON job spec
7. 检查输出结果并总结汇报

job spec 至少应包含：

- `template_path`
- `party_a` 或 `party_b`
- `cooperation_items`
- `unresolved_items`

如有需要，还应包含：

- `party_b_credit_code`
- `party_a_profile`
- `party_b_profile`
- `global_replacements`
- `paragraph_overrides`
- `leave_blank_fields`
- `agent_id`
- `agent_workspace`
- `output_dir`

如果用户只明确给出了甲方或乙方中的一方，另一方默认可补为 `成都景合开普勒科技有限公司`。  
如果双方都未提供，则不能继续起草。

如果用户没有提供甲乙方介绍，应先检查当前 agent 工作区中的 `MEMORY.md` 与 `memory/` 目录。  
若记忆中已存在准确版本，直接优先使用；仅在记忆中找不到或信息不足时，才通过可用的检索能力补齐。  
优先使用已安装的第三方检索 skill 或搜索工具，例如 Tavily；若无外部检索能力，再根据用户已给事实做审慎摘要，但不要编造履历、资质、融资、专利或政府背书。

如果用户在对话中明确表示“记住”“以后按这个版本用”“作为永久性记忆保存”等含义，应把对应公司介绍或规则写入当前 agent 工作区的永久记忆文件中，并保存到 `memory/` 目录或 `MEMORY.md` 中，供后续合同任务优先复用。

不要再使用旧版简化字段，例如只写 `content_sections` 却不写 `cooperation_items`。  
如果 job spec 未提供 `cooperation_items`，就不能把任务视为“已完成正文起草”。
runner 会自动归一化少数常见输错格式，例如：

- `global_replacements` 被写成单个对象
- `cooperation_items` 中误写成 `title/description`
- `paragraph_overrides` 被写成单个对象

但这只是兜底，不应依赖这种容错。OpenClaw 仍应优先产出标准 schema。  
如果 runner 报出 schema error，应按报错一次性修正后重试；同类 schema 错误不要连续盲改多轮。

## Runner 必须做的事

`scripts/contract_runner.py` 应负责：

1. 读取 `.docx` 模板
2. 更新标题和甲乙方信息
3. 写入甲乙方公司介绍相关段落
4. 做全局旧术语替换
5. 重写合作内容区
6. 应用段落级改写
7. 在目标 agent workspace 下保存新 `.docx`
8. 输出：
   - `未决事项清单.md`
   - `run-summary.json`
   - `validation-report.json`

对于当前示例模板这类“正文语义很重”的合同，runner 不应只做机械替换。

当 job spec 提供了新的合作内容，但未把所有兼容段显式写进 `paragraph_overrides` 时，runner 仍应对关键兼容段执行默认改写，至少覆盖：

1. 鉴于 / 背景
2. 合作原则
3. 甲方权利与义务
4. 乙方权利与义务
5. 合作机制
6. 主体承继或连续性相关段落
7. 知识产权前置归属段落

## 起草边界

1. 保留原有 Word 结构和格式
2. 更新封面及正文中的甲乙方；标题默认保留模板原题，不主动改写
3. 根据搜集到的公司介绍改写背景或鉴于段中的主体描述
4. 根据用户给定主题重写合作内容区
5. 当合作主题变化导致语义不再匹配时，同步修改相关联动段落
6. 保证改写后全文逻辑一致

不要为了让文档“看起来完整”而虚构关键法律事实或商业事实。

敏感或未明确字段默认处理：

1. 身份证号默认留空
2. 签署信息默认留空，除非用户明确提供
3. 未确定日期使用空白或待确认标记
4. 如果主体是机构，不要强行沿用自然人身份证语义

## 强约束

1. 不要把模板改造成新的“第X章 / 第X条”结构，除非模板本来就是这种结构
2. 不要只改合作内容区就停止
3. 不要把旧行业、旧地域、旧主体、旧产品的明显残留原样留在正文里
4. 不要把内部规则抛回给用户重复描述
5. 不要在同一个错误点无限重试

如果一致性检查发现明显残留问题，默认行为应是继续修正并重新生成，而不是先问用户“要不要继续修”。

## 插件与环境

如果任务需要直接调用 Word 插件能力：

1. 先自检 `word-docx` 是否可用
2. 如未安装，优先尝试通过 `clawhub` 自动安装
3. 如未登录 ClawHub，先补齐登录态
4. 只有自动准备明确失败后，才退回纯文本兜底方案

## 路径规则

1. 输出目录应写入 `<agent_workspace>/keplerjai-contract-draft`
2. 优先自动推导 `agent_workspace`
3. 优先使用相对路径、自动推导路径或由配置读取的路径
4. 不要把某台机器上的用户目录、盘符或绝对路径当成默认值
5. skill 安装目录只作为说明和脚本来源，不作为输出目录

## 校验重点

在宣布成功前，至少验证：

1. 确实生成了新的 `.docx`
2. 向用户汇报时给出完整输出文件路径
3. 原模板没有被覆盖
4. 关键输入已经写入草稿
5. 签署页仍然存在
6. 标题保持模板原样，除非用户明确要求改标题
7. 当合作语义发生变化时，关键联动段落也已经同步更新
8. 甲乙方介绍已写入或已在未决事项中明确说明缺失原因

## 参考文件

需要补充上下文时，按需阅读：

- `README.md`
- `scripts/contract_runner.py`
- `references/input-contracting-rules.md`
- `references/runtime-output-contract.md`
- `references/template-analysis.md`
- `references/word-plugin-setup.md`
- `references/iteration-notes.md`