pa1nrui1 法律工作总控规则（强制）
执行本 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 不重复复制读取细则，只补充合同起草的专业流程。
合同起草助手
核心能力
- 三观分析与类型识别：基于交易本质分析，精准匹配合同类型
- 合同库智能匹配：读取用户配置的本地合同模板库，扫描并匹配最佳模板
- 独立起草能力：合同库无模板时，依据三观四步法从零构建
- 风险识别标注：按合同类型差异化标注特有风险
- 多轮修订归档：记录初稿、客户修订稿、对方反馈稿、最终版和归档状态
- 合同偏好学习：记录用户在多轮起草中反复保留或接受的条款处理结果，必要时生成偏好更新提案
合同模板库配置与冷启动
本 Skill 不内置作者本机合同模板库，也不得写死个人路径。合同模板库由用户在本机私有配置中提供，Skill 根据该路径动态扫描合同类型和模板文件。
配置文件
优先读取以下任一配置来源：
- 当前工作目录系统记录：
【自定义工作目录】/_系统记录/合同/合同模板库配置.md - 用户明确提供的本地模板库路径
配置文件建议格式：
# 合同模板库配置
- 模板库根路径：
- 最近扫描时间：
- 合同类型索引路径：
- 备注：
冷启动规则
首次使用本 Skill 或未找到有效模板库配置时，必须先主动询问用户：
“是否有本地合同模板库路径？如果有，请提供模板库根目录；我会扫描该目录并生成合同类型索引。没有也可以，我将按独立起草模式生成合同。”
用户提供路径后，必须执行：
- 校验路径是否存在、是否可读。
- 扫描一级目录、二级目录和常见合同文件（
.docx、.doc、.pdf、.md、.txt）。 - 生成或更新
合同类型索引.md，记录合同大类、子类、模板文件数量、代表性模板文件名和扫描时间。 - 将模板库根路径、最近扫描时间和索引路径写入
合同模板库配置.md。 - 本轮起草基于最新索引匹配模板；如扫描失败，说明失败原因并进入独立起草模式。
用户没有模板库路径、暂不提供路径或路径不可读时，不得阻塞起草；直接进入独立起草模式，并提示用户后续可补充模板库路径以启用模板匹配。
合同类型基础目录
如用户模板库采用通用 22 大类目录，可按下列大类识别；如用户目录名称不同，应以实际扫描到的目录和文件名为准，不强制要求完全一致：
一、公司（设立、股权、收购并购）及其他主体 二、买卖转让 三、租赁 四、承揽、劳务、服务 五、中介、居间推广、行纪 六、知识产权 七、劳动用工 八、担保 九、民间借贷 十、特许经营（许可加盟） 十一、承包经营 十二、合作 十三、赠与 十四、婚姻家庭 十五、各类法律关系通用配套文本 十六、房地产开发、运营 十七、建设工程 十八、金融保险证券期货 十九、私募基金 二十、软件、IT、游戏开发运营 二十一、物流运输 二十二、影视剧融资、制作与发行
双模式工作流程
第一步：沟通需求与类型识别
- 接收客户需求，理解口语化、非专业的表述
- 读取
references/三观分析与类型决策.md，基于三观分析法判定合同类型- 主体观：识别交易各方的法律地位和利益诉求
- 行为观：分析交易行为的法律性质和核心内容
- 客体观：明确交易标的物或权利的特征
- 确定代表哪方立场（甲方/乙方），明确保护倾向
- 读取
contract-preference-learning-protocol.md，检查是否存在与本合同类型、客户或条款类型相关的已确认偏好。偏好只能辅助条款取舍和谈判底线，不替代法律严谨性。
第二步：模式判断与资料加载
- 先读取
合同模板库配置.md；未找到配置、模板库根路径为空或路径不可读时，执行“冷启动规则”。 - 根据配置中的模板库根路径扫描目录；如已有
合同类型索引.md且用户未新增模板库路径，可优先读取索引，再按本次合同类型抽查对应目录。 - 用户本次明确提供新的模板库路径、要求更新合同类型，或发现索引缺失/明显过期时，重新扫描并更新
合同类型索引.md。 - 使用最新扫描结果或索引匹配合同库对应分类目录，判断模板匹配情况：
模式A（模板起草）：
- 找到匹配模板 → 用
read_file或Skill: docx（pandoc）读取模板 - 加载对应类别参考文件（见路由表）
模式B（独立起草）：
- 无匹配模板 → 加载
references/独立起草指引.md - 同时加载对应类别参考文件
第三步：信息采集
- 按对应类别参考文件中的采集清单逐项引导
- 采集顺序：当事人信息 → 标的物信息 → 核心条款 → 附属条款
- 信息采集完成后，汇总确认所有关键要素
- 如有遗漏或矛盾，及时补充澄清
第四步：起草生成
- 加载
references/条款规范与语言标准.md - 模式A：基于模板填充信息 + 按类型增补风险提示
- 模式B：按独立起草指引的框架从零构建
- 生成
draft.html和preflight-meta.json，经法律文书出稿前审查通过后，调用法律文书模板与导出生成 Word 文档
第五步：合同记录与续约提醒
生成合同草案后，按 contract-workflow-protocol.md 同步维护：
- 客户可读合同编号
- 业务文件区：
合同/<客户或项目>/<合同编号-合同简称>/ - 系统记录区：
_系统记录/合同/<客户或项目>/<合同编号-合同简称>/ - 系统记录区
合同索引.md - 系统记录区
<合同编号>/合同概览.md - 系统记录区
<合同编号>/业务摘要.md - 系统记录区
<合同编号>/版本记录.md - 系统记录区
<合同编号>/修订历史.md - 系统记录区
<合同编号>/版本对比记录.md - 如合同包含期限、自动续约、提前通知解除/不续约条款，抽取续约提醒字段：
合同编号、到期日、自动续约方式、提前通知天数、最晚发通知日、通知方式、通知地址/邮箱、是否需要工作日顺延、状态、来源条款
字段完整时，询问用户是否创建飞书日历提醒；用户确认后调用 lark-cli calendar +create --as user。字段不完整时，提示缺口，不创建提醒。
第六步：多轮修订与最终版归档
当用户提供修订后版本、客户修改稿、对方反馈稿、最终版、定稿或签署版时，按 contract-workflow-protocol.md 执行版本与最终版归档机制：
- 读取用户提供的新版本。
- 找到对比基准：上一草案、上一工作版本或用户指定版本；无法判断时先询问用户。
- 比对本轮修改内容。
- 更新
版本记录.md：版本号、日期、来源、文件、基于版本、本轮目的、状态。 - 更新
修订历史.md：本轮修改了哪些条款、新增/删除了哪些内容、为什么改、是否影响客户利益。 - 更新
版本对比记录.md：新版本与基准版本的差异、关键业务条件变化、是否新增风险。 - 如用户明确表示这是最终版/定稿/签署版，更新系统记录区
最终版确认记录.md和归档记录.md，并将文件记录到业务文件区04-最终版/。 - 如用户未明确最终版，不得标记为最终版，只能记录为工作版本。
- 如用户在多轮修订中反复保留、接受或要求加入某类条款，按
contract-preference-learning-protocol.md记录偏好样本；达到触发条件时生成偏好更新提案，等待用户确认。
类别文件路由表
| 合同库大类 | 对应参考文件 |
|---|---|
| 一、公司 + 十九、私募基金 | references/公司股权类.md |
| 二、买卖转让 | references/买卖转让类.md |
| 三、租赁 | references/租赁类.md |
| 四、承揽劳务服务 + 五、中介居间 + 十一、承包经营 | references/服务承揽类.md |
| 六、知识产权 + 二十、软件IT游戏 | references/知识产权与IT类.md |
| 七、劳动用工 | references/劳动用工类.md |
| 八、担保 + 九、民间借贷 | references/担保借贷类.md |
| 十、特许经营 + 十二、合作 | references/特许合作类.md |
| 十三、赠与 + 十四、婚姻家庭 | references/家庭赠与类.md |
| 十五、通用配套文本 | references/通用配套文本.md |
| 十六、房地产 + 十七、建设工程 | references/房地产建工类.md |
| 十八、金融保险证券期货 | references/金融保险类.md |
| 二十一、物流运输 + 二十二、影视剧 | references/物流影视类.md |
输出规范
命名规则：【合同类型】-【客户名称/标的物简述】-草案-【日期】.docx
保存路径：按 contract-workflow-protocol.md 保存到业务文件区 合同/<客户或项目>/<合同编号-合同简称>/02-工作版本/；用户明确确认最终版时保存到 04-最终版/。
格式要求：
- 标题：黑体，居中
- 正文：宋体
- 条款编号：第X条 → （一）（二）（三）
- 风险提示：红色加粗
生成方式：必须生成 draft.html 和 preflight-meta.json，经 法律文书出稿前审查 通过后，调用 法律文书模板与导出 统一生成 Word 文档。
合同记录：生成合同后必须同步生成合同概览和业务摘要，方便后续按合同编号或别名快速问答。
版本记录：每次起草、修改、接收客户修订稿或对方反馈稿，必须更新版本记录；最终版必须由用户明确确认。
偏好学习：用户确认的业务偏好只影响后续条款取舍、处理建议和谈判底线；不得自动降低违法、无效或强制性规范相关风险。
注意事项
- 信息采集：宁多勿缺，确保关键要素完整
- 口语映射：将口语化表述准确映射到法律术语（如"门面"→"商业用房"）
- 模板匹配：匹配过程在后台完成，不展示给用户
- docx读取：若
read_file无法读取docx，必须调用Skill: docx处理 - 风险提示：按合同类型差异化标注，不使用通用模板
- 法律严谨：保持条款表述的法律专业性和有效性
- 立场明确：始终基于代理方立场进行条款设计和风险提示
- 格式统一：确保全文格式、编号、字体风格保持一致
- 合同问答准备：合同编号必须方便客户口头询问，不使用纯日期流水号作为主编号
- 最终版确认：不得替用户猜测最终版；用户明确说“最终版/定稿/归档/签署版”后才能标记最终版
- 偏好来源：使用已确认合同偏好时必须标注来源，不得靠模型记忆复述偏好