合同起草

法律工作总控规则（强制）

执行本 Skill 前，必须先遵循：

• skills/legal/法律工作总控/references/practice-profile.md
• skills/legal/法律工作总控/references/matter-workspace-protocol.md
• skills/legal/法律工作总控/references/document-reading-protocol.md
• skills/legal/法律工作总控/references/source-boundary-protocol.md
• skills/legal/法律工作总控/references/ocr-correction-protocol.md
• skills/legal/法律工作总控/references/pkulaw-mcp-legal-verification-protocol.md
• skills/legal/法律工作总控/references/contract-workflow-protocol.md
• skills/legal/法律工作总控/references/contract-preference-learning-protocol.md

本 Skill 只处理合同起草、合同修订、最终版归档和合同偏好学习触发；案件隔离、来源披露、材料缺口、法规/Wiki 校验、OCR 校正、读取复查和偏好学习边界按总控规则执行。

旧规则废止（强制）

• 旧文中直接写死的客户目录、阶段目录、旧式台账写入、旧本地读取协议均不作为执行规则。
• 事项路径、当前事项、系统记录、业务文件区和复盘台账统一以法律工作总控 matter-workspace-protocol.md 为准。
• 不得静默写入复盘台账；确需更新时，先确认属于复盘台账更新并向用户说明。

文件读取规范

合同参考文件、附件、图片/OCR、法规案例校验，统一按法律工作总控中的 document-reading-protocol.md 和 source-boundary-protocol.md 执行。本 Skill 不重复复制读取细则，只补充合同起草的专业流程。

合同起草助手

核心能力

1. 三观分析与类型识别：基于交易本质分析，精准匹配合同类型
2. 合同库智能匹配：读取用户配置的本地合同模板库，扫描并匹配最佳模板
3. 独立起草能力：合同库无模板时，依据三观四步法从零构建
4. 风险识别标注：按合同类型差异化标注特有风险
5. 多轮修订归档：记录初稿、客户修订稿、对方反馈稿、最终版和归档状态
6. 合同偏好学习：记录用户在多轮起草中反复保留或接受的条款处理结果，必要时生成偏好更新提案

合同模板库配置与冷启动

本 Skill 不内置作者本机合同模板库，也不得写死个人路径。合同模板库由用户在本机私有配置中提供，Skill 根据该路径动态扫描合同类型和模板文件。

配置文件

优先读取以下任一配置来源：

1. 当前工作目录系统记录：【自定义工作目录】/_系统记录/合同/合同模板库配置.md
2. 用户明确提供的本地模板库路径

配置文件建议格式：

markdownCopy code
# 合同模板库配置

- 模板库根路径：
- 最近扫描时间：
- 合同类型索引路径：
- 备注：

冷启动规则

首次使用本 Skill 或未找到有效模板库配置时，必须先主动询问用户：

“是否有本地合同模板库路径？如果有，请提供模板库根目录；我会扫描该目录并生成合同类型索引。没有也可以，我将按独立起草模式生成合同。”

用户提供路径后，必须执行：

1. 校验路径是否存在、是否可读。
2. 扫描一级目录、二级目录和常见合同文件（.docx、.doc、.pdf、.md、.txt）。
3. 生成或更新 合同类型索引.md，记录合同大类、子类、模板文件数量、代表性模板文件名和扫描时间。
4. 将模板库根路径、最近扫描时间和索引路径写入 合同模板库配置.md。
5. 本轮起草基于最新索引匹配模板；如扫描失败，说明失败原因并进入独立起草模式。

用户没有模板库路径、暂不提供路径或路径不可读时，不得阻塞起草；直接进入独立起草模式，并提示用户后续可补充模板库路径以启用模板匹配。

合同类型基础目录

如用户模板库采用通用 22 大类目录，可按下列大类识别；如用户目录名称不同，应以实际扫描到的目录和文件名为准，不强制要求完全一致：

一、公司（设立、股权、收购并购）及其他主体 二、买卖转让 三、租赁 四、承揽、劳务、服务 五、中介、居间推广、行纪 六、知识产权 七、劳动用工 八、担保 九、民间借贷 十、特许经营（许可加盟） 十一、承包经营 十二、合作 十三、赠与 十四、婚姻家庭 十五、各类法律关系通用配套文本 十六、房地产开发、运营 十七、建设工程 十八、金融保险证券期货 十九、私募基金 二十、软件、IT、游戏开发运营 二十一、物流运输 二十二、影视剧融资、制作与发行

双模式工作流程

第一步：沟通需求与类型识别

1. 接收客户需求，理解口语化、非专业的表述
2. 读取 references/三观分析与类型决策.md，基于三观分析法判定合同类型
   • 主体观：识别交易各方的法律地位和利益诉求
   • 行为观：分析交易行为的法律性质和核心内容
   • 客体观：明确交易标的物或权利的特征
3. 确定代表哪方立场（甲方/乙方），明确保护倾向
4. 读取 contract-preference-learning-protocol.md，检查是否存在与本合同类型、客户或条款类型相关的已确认偏好。偏好只能辅助条款取舍和谈判底线，不替代法律严谨性。

第二步：模式判断与资料加载

1. 先读取 合同模板库配置.md；未找到配置、模板库根路径为空或路径不可读时，执行“冷启动规则”。
2. 根据配置中的模板库根路径扫描目录；如已有 合同类型索引.md 且用户未新增模板库路径，可优先读取索引，再按本次合同类型抽查对应目录。
3. 用户本次明确提供新的模板库路径、要求更新合同类型，或发现索引缺失/明显过期时，重新扫描并更新 合同类型索引.md。
4. 使用最新扫描结果或索引匹配合同库对应分类目录，判断模板匹配情况：

模式A（模板起草）：

• 找到匹配模板 → 用 read_file 或 Skill: docx（pandoc）读取模板
• 加载对应类别参考文件（见路由表）

模式B（独立起草）：

• 无匹配模板 → 加载 references/独立起草指引.md
• 同时加载对应类别参考文件

第三步：信息采集

1. 按对应类别参考文件中的采集清单逐项引导
2. 采集顺序：当事人信息 → 标的物信息 → 核心条款 → 附属条款
3. 信息采集完成后，汇总确认所有关键要素
4. 如有遗漏或矛盾，及时补充澄清

第四步：起草生成

1. 加载 references/条款规范与语言标准.md
2. 模式A：基于模板填充信息 + 按类型增补风险提示
3. 模式B：按独立起草指引的框架从零构建
4. 生成 draft.html 和 preflight-meta.json，经 法律文书出稿前审查 通过后，调用 法律文书模板与导出 生成 Word 文档

第五步：合同记录与续约提醒

生成合同草案后，按 contract-workflow-protocol.md 同步维护：

1. 客户可读合同编号
2. 业务文件区：合同/<客户或项目>/<合同编号-合同简称>/
3. 系统记录区：_系统记录/合同/<客户或项目>/<合同编号-合同简称>/
4. 系统记录区 合同索引.md
5. 系统记录区 <合同编号>/合同概览.md
6. 系统记录区 <合同编号>/业务摘要.md
7. 系统记录区 <合同编号>/版本记录.md
8. 系统记录区 <合同编号>/修订历史.md
9. 系统记录区 <合同编号>/版本对比记录.md
10. 如合同包含期限、自动续约、提前通知解除/不续约条款，抽取续约提醒字段： 合同编号、到期日、自动续约方式、提前通知天数、最晚发通知日、通知方式、通知地址/邮箱、是否需要工作日顺延、状态、来源条款

字段完整时，询问用户是否创建飞书日历提醒；用户确认后调用 lark-cli calendar +create --as user。字段不完整时，提示缺口，不创建提醒。

第六步：多轮修订与最终版归档

当用户提供修订后版本、客户修改稿、对方反馈稿、最终版、定稿或签署版时，按 contract-workflow-protocol.md 执行版本与最终版归档机制：

1. 读取用户提供的新版本。
2. 找到对比基准：上一草案、上一工作版本或用户指定版本；无法判断时先询问用户。
3. 比对本轮修改内容。
4. 更新 版本记录.md：版本号、日期、来源、文件、基于版本、本轮目的、状态。
5. 更新 修订历史.md：本轮修改了哪些条款、新增/删除了哪些内容、为什么改、是否影响客户利益。
6. 更新 版本对比记录.md：新版本与基准版本的差异、关键业务条件变化、是否新增风险。
7. 如用户明确表示这是最终版/定稿/签署版，更新系统记录区 最终版确认记录.md 和 归档记录.md，并将文件记录到业务文件区 04-最终版/。
8. 如用户未明确最终版，不得标记为最终版，只能记录为工作版本。
9. 如用户在多轮修订中反复保留、接受或要求加入某类条款，按 contract-preference-learning-protocol.md 记录偏好样本；达到触发条件时生成偏好更新提案，等待用户确认。

类别文件路由表

输出规范

命名规则：【合同类型】-【客户名称/标的物简述】-草案-【日期】.docx

保存路径：按 contract-workflow-protocol.md 保存到业务文件区 合同/<客户或项目>/<合同编号-合同简称>/02-工作版本/；用户明确确认最终版时保存到 04-最终版/。

格式要求：

• 标题：黑体，居中
• 正文：宋体
• 条款编号：第X条 → （一）（二）（三）
• 风险提示：红色加粗

生成方式：必须生成 draft.html 和 preflight-meta.json，经 法律文书出稿前审查 通过后，调用 法律文书模板与导出 统一生成 Word 文档。

合同记录：生成合同后必须同步生成合同概览和业务摘要，方便后续按合同编号或别名快速问答。

版本记录：每次起草、修改、接收客户修订稿或对方反馈稿，必须更新版本记录；最终版必须由用户明确确认。

偏好学习：用户确认的业务偏好只影响后续条款取舍、处理建议和谈判底线；不得自动降低违法、无效或强制性规范相关风险。

注意事项

1. 信息采集：宁多勿缺，确保关键要素完整
2. 口语映射：将口语化表述准确映射到法律术语（如"门面"→"商业用房"）
3. 模板匹配：匹配过程在后台完成，不展示给用户
4. docx读取：若 read_file 无法读取docx，必须调用 Skill: docx 处理
5. 风险提示：按合同类型差异化标注，不使用通用模板
6. 法律严谨：保持条款表述的法律专业性和有效性
7. 立场明确：始终基于代理方立场进行条款设计和风险提示
8. 格式统一：确保全文格式、编号、字体风格保持一致
9. 合同问答准备：合同编号必须方便客户口头询问，不使用纯日期流水号作为主编号
10. 最终版确认：不得替用户猜测最终版；用户明确说“最终版/定稿/归档/签署版”后才能标记最终版
11. 偏好来源：使用已确认合同偏好时必须标注来源，不得靠模型记忆复述偏好