keplerjai-contract-draft（开普勒贾伊合同草案）

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