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