Keplerjai Contract Draft
v1.0.0基于 Word 模板和结构化业务信息生成合同草稿。适用于 AI 总助根据现有 .docx 模板起草合同、填充甲乙方与合作信息、识别缺失字段并输出可审阅草稿的场景。
Like a lobster shell, security has layers — review code before you run it.
KeplerJAI 合同起草
当目标是“基于现有 Word 模板 + 业务事实生成合同草稿”时使用这份 skill,而不是在没有模板的情况下凭空定稿法律文本。
核心分工
- OpenClaw 负责理解需求、检查模板、起草正文改写方案,并生成结构化 JSON job spec。
scripts/contract_runner.py负责稳定执行.docx修改、输出草稿和校验产物。
当稳定 runner 已能处理任务时,不要再临时生成 _draft_v1.py、_draft_v2.py 这类一次性脚本。
执行主线
默认按以下顺序执行:
- 检查模板与用户输入
- 判断需要联动修改的章节
- 生成一份 UTF-8 编码的 JSON job spec
- 执行
python scripts\contract_runner.py --spec <job-spec.json> - 检查生成的
.docx、未决事项清单.md、run-summary.json、validation-report.json
一旦 JSON job spec 成功写出:
- 不要反复重写同一份 spec
- 必须立刻执行 runner
- 如果 runner 失败,要返回具体失败点,而不是重复状态文本
OpenClaw 必须做的事
- 检查源模板
- 理解用户请求
- 判断哪些章节需要联动修改
- 搜集甲乙方公司介绍,并各自压缩为约 150 字的正式摘要
- 根据合作主题起草合作内容正文
- 生成符合 runner 要求的 JSON job spec
- 检查输出结果并总结汇报
job spec 至少应包含:
template_pathparty_a或party_bcooperation_itemsunresolved_items
如有需要,还应包含:
party_b_credit_codeparty_a_profileparty_b_profileglobal_replacementsparagraph_overridesleave_blank_fieldsagent_idagent_workspaceoutput_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/descriptionparagraph_overrides被写成单个对象
但这只是兜底,不应依赖这种容错。OpenClaw 仍应优先产出标准 schema。
如果 runner 报出 schema error,应按报错一次性修正后重试;同类 schema 错误不要连续盲改多轮。
Runner 必须做的事
scripts/contract_runner.py 应负责:
- 读取
.docx模板 - 更新标题和甲乙方信息
- 写入甲乙方公司介绍相关段落
- 做全局旧术语替换
- 重写合作内容区
- 应用段落级改写
- 在目标 agent workspace 下保存新
.docx - 输出:
未决事项清单.mdrun-summary.jsonvalidation-report.json
对于当前示例模板这类“正文语义很重”的合同,runner 不应只做机械替换。
当 job spec 提供了新的合作内容,但未把所有兼容段显式写进 paragraph_overrides 时,runner 仍应对关键兼容段执行默认改写,至少覆盖:
- 鉴于 / 背景
- 合作原则
- 甲方权利与义务
- 乙方权利与义务
- 合作机制
- 主体承继或连续性相关段落
- 知识产权前置归属段落
起草边界
- 保留原有 Word 结构和格式
- 更新封面及正文中的甲乙方;标题默认保留模板原题,不主动改写
- 根据搜集到的公司介绍改写背景或鉴于段中的主体描述
- 根据用户给定主题重写合作内容区
- 当合作主题变化导致语义不再匹配时,同步修改相关联动段落
- 保证改写后全文逻辑一致
不要为了让文档“看起来完整”而虚构关键法律事实或商业事实。
敏感或未明确字段默认处理:
- 身份证号默认留空
- 签署信息默认留空,除非用户明确提供
- 未确定日期使用空白或待确认标记
- 如果主体是机构,不要强行沿用自然人身份证语义
强约束
- 不要把模板改造成新的“第X章 / 第X条”结构,除非模板本来就是这种结构
- 不要只改合作内容区就停止
- 不要把旧行业、旧地域、旧主体、旧产品的明显残留原样留在正文里
- 不要把内部规则抛回给用户重复描述
- 不要在同一个错误点无限重试
如果一致性检查发现明显残留问题,默认行为应是继续修正并重新生成,而不是先问用户“要不要继续修”。
插件与环境
如果任务需要直接调用 Word 插件能力:
- 先自检
word-docx是否可用 - 如未安装,优先尝试通过
clawhub自动安装 - 如未登录 ClawHub,先补齐登录态
- 只有自动准备明确失败后,才退回纯文本兜底方案
路径规则
- 输出目录应写入
<agent_workspace>/keplerjai-contract-draft - 优先自动推导
agent_workspace - 优先使用相对路径、自动推导路径或由配置读取的路径
- 不要把某台机器上的用户目录、盘符或绝对路径当成默认值
- skill 安装目录只作为说明和脚本来源,不作为输出目录
校验重点
在宣布成功前,至少验证:
- 确实生成了新的
.docx - 向用户汇报时给出完整输出文件路径
- 原模板没有被覆盖
- 关键输入已经写入草稿
- 签署页仍然存在
- 标题保持模板原样,除非用户明确要求改标题
- 当合作语义发生变化时,关键联动段落也已经同步更新
- 甲乙方介绍已写入或已在未决事项中明确说明缺失原因
参考文件
需要补充上下文时,按需阅读:
README.mdscripts/contract_runner.pyreferences/input-contracting-rules.mdreferences/runtime-output-contract.mdreferences/template-analysis.mdreferences/word-plugin-setup.mdreferences/iteration-notes.md
Comments
Loading comments...
