# Doubao Contract Amendment > 用于在已签原协议基础上，依据用户提供的新情况起草补充协议、变更协议或终止协议。先重建主体、标的、资金、条件、时间和文件构成的整体法律状态，再在用户明确授权范围内成文。仅处理既有协议的派生修改；不用于全新合同起草、既有合同风险审查、一般法律咨询或纯 Word 排版与纯文件处理，纯文档编辑改用 lark-doc。 - Skill: `ahang1598/doubao-contract-amendment` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add ahang1598/doubao-contract-amendment` - Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/doubao-contract-amendment/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: ahang1598 (https://skillmd.com/u/ahang1598) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/ahang1598/doubao-contract-amendment --- # 补充协议起草：整体法律状态优先 将补充协议视为原协议的衍生修改：`原法律状态 S0 + 用户授权的变化 Δ = 修改后法律状态 S1`。目标不是使补充协议自身面面俱到，而是准确实现本次变化并保持未变部分继续有效。 ## 不适用边界 本 skill 仅用于在既有协议基础上起草补充协议、变更协议或终止协议，不承担以下任务： - 全新合同或全套交易文件从零起草； - 对现有合同进行风险审查、合规审阅、问题清单整理或红线审阅； - 脱离具体起草任务的一般法律咨询、法律分析或法律意见输出； - 仅对现成文档做排版、美化、格式整理、批注处理、转清稿或其他纯文件处理。 若用户主要需求是纯文档编辑、格式整理、批注接受、样式修复或其他不涉及实质法律起草的 Word 处理，交由 `lark-doc`；只有在法律正文已经明确、且文档处理只是交付末端步骤时，才由本 skill 在完成起草后生成可编辑 Word。 ## 1. 先理解整体，不要先拆指令 完整读取用户提供的原协议，包括正文、定义、表格、附件、签署页、修订痕迹和批注。用户通常提供的就是本次拟补充或修改的原协议，默认按原协议处理；只有同时提供多份协议、补充文件、修订稿、事实材料或参考模板时，才进一步识别各材料的角色和效力顺序。 若原文件明确含有附件、表格、批注或修订，而当前读取结果没有显示相应内容，继续读取原文件的相应部分，或者在内部将该部分标记为尚未核验；不得仅因文本提取结果没有显示，就认定原文件不存在该内容。 在拆分用户要求或设计条款前，必须完整读取 [references/legal-state-model.md](references/legal-state-model.md)，并依其方法在内部重建 S0。不得用逐项勾选、“已核对”或摘要罗列代替整体法律状态理解。 用户要求按修订或批注处理时，同时读取修订前文本、接受修订后的文本、插入删除差异及批注；用户仅把带修订痕迹的文件作为当前版本提供时，以接受修订后的文本作为底稿。不得仅因存在修订痕迹就中止任务。 ## 2. 理解、核验用户要求并形成起草交接本 完整理解并核验用户的内容要求、事实状态、立场、目标及输出类型、语言、格式、篇幅、文件类型和清洁版或修订版要求。区分： - 用户要求文本实现的新安排； - 已经发生或各方已确认的事实； - 用户希望保护的立场和目标； - 仅供理解的背景描述。 将全部明确要求作为 Δ 同时叠加到 S0，先判断组合后的 S1 是否能够共同成立。核对用户对原协议的概述与原文是否一致，并检查主体身份、标的来源、权利和资金流向、条件与履行先后、日期状态、文件性质、总额与分项以及责任后果是否相容。用户明确要求改变原约定时，将其视为变化，不当作材料冲突。 在形成 S1 中能够确定的整体状态，并划清未决事项及其影响边界后，再将用户要求拆成 R1、R2……。原子化仅用于防遗漏和限定授权，不得把同一交易关系割裂为彼此独立的事实。每个 R 项必须连接回其影响的主体、标的、资金、条件、时间或文件节点。 起草前在内部形成一份简短的“起草交接本”，作为理解结果的压缩工作记忆以及成文前后共用的验证接口。交接本只记录后续需要保持稳定的结论、边界和缺口，不重复抄录原协议；供后续成文和复核共同使用。交接本至少记录： - 原协议中必须保持不变的关键状态和变量； - 用户明确提出的每项变化、拟达到的 S1、对应用户原话及关联的原协议位置；新增事项没有对应原条款时注明“新增”； - 经核验能够唯一确定的计算和推导； - 明显异常、相互不闭合或材料空白的事项； - 尚未读取或尚未核验的材料范围及其可能影响，不得将其视为不存在或已经确认； - 每个未决事项的安全处理方式：继续适用原约定、限定本次修改范围、设置单一待补项或在确有必要时询问； - 用户的立场以及输出形式要求。 未决事项不得在交接本中被改写成确定事实。能够留白且不妨碍确定部分生效的，明确标记为 `【待补：具体事项】`，供起草阶段原样落实；不得在成文时自行填平。 ## 3. 依据交接本守住事实与授权边界 以用户当前明确指令控制 Δ，以原协议及已生效补充文件控制 S0。用户立场用于选择保护方向和措辞，不得写成各方已经确认的事实。 起草时只使用交接本中明确记录的用户要求、材料原文和唯一推导。无来源的重大安排必须删除、恢复原约定、缩小修改范围或使用交接本确定的待补项；一个占位符只对应一个问题。 不得仅为使文本完整、专业或可执行而自行决定股权或资产来源、交易类型、付款人或收款人、付款期限、留存款用途、税费承担、违约金、利息、定金罚则、保证或连带责任、责任上限、免责或权利放弃、新增先决条件、单方解除权、争议机构或协议编号。 可以补充交叉引用、适用顺序和不改变实质法律事实或法律效果的连接文字。模型自行组织或润色的内容不得新增或改变主体、标的、来源、金额、条件、履行顺序、权利义务、责任范围、风险分配或其他实质变量。任何会改变上述变量的“必要机制”，必须先回到交接本并找到用户要求或原协议依据；没有依据即不得写入。 ## 4. 校验并冻结交接本中的客观关系 在成文前，对交接本中的客观关系执行一次统一校验，不另起互不相连的检查清单： - **数量守恒**：实际计算金额、比例、数量及变更前后总量，记录计算结果和差额；不一致时不得标记闭合。 - **来源一致**：逐项核对主体、标的来源、付款人与收款人、文件出具主体、文件性质和法律效果；未明确时保持未决，不得用近似安排替代。 - **状态与时序一致**：核对事实是已发生、拟发生还是待确认，并沿条件、义务、期限、完成标准和后果检查先后关系、循环及已届满日期。 - **角色与授权一致**：核对新旧称谓及各方角色，确认任何实质变量的变化都有用户要求或原协议依据。 把校验结果写回交接本并冻结为当前起草依据。每个事项只能处于“确定写入”“继续适用原约定”“待补留白”或“必须询问（仅限第5节规定的情形）”之一；不得在正文中静默改变其状态。 如成文过程中暴露出前期未识别的依赖、缺口或矛盾，不得在正文中直接解决。先回到原协议和用户指令核验：能够定位到明确依据的，更新交接本并重新执行本节校验后再写入；没有明确依据的，维持未决、删除相关推断或设置待补项。起草过程中产生的联想或方案本身不是材料依据。 ## 5. 在既定法律状态和指令增量下成文 严格依据原协议、用户指令增量和已冻结的起草交接本组织补充协议。起草裁量仅限于条款结构、交叉引用、逻辑衔接和不改变实质法律事实或法律效果的专业润色。只写本次变化及其不可缺少且已有依据的关联处理；不得因某类合同通常包含某项条款而重述原协议或扩张本次修改范围。确有必要引用未改动的原条款时，只标注其条款编号，不复述其条款内容，以免在复述中把原文空缺或未明确处填成确定内容。 用户要求的形式优先。用户未规定时，采用正式、简洁、可签署的中国商事律师文书格式，明确原协议未变更事项继续有效以及补充协议与原协议的适用顺序。 默认直接完成能够安全确定的部分。只有存在两种均有材料依据且会产生实质不同结果、又无法通过保留原约定、限定范围或待补安全处理时，才提出一个具体问题。 ## 6. 双向验证并交付 完成初稿后直接修正，不输出自评： - 从交接本中每个确定写入或待补事项正向追踪到正文，确认用户的内容和形式要求均已实现； - 从每项重大正文安排反向追踪到交接本、用户要求或原协议依据，无来源即删除或待补； - 将正文还原为 S1 中的确定部分，确认已确定的主体、权属、资金、条件、时间、文件和责任关系能够同时成立，未决事项保持留白且没有污染确定部分； - 按交接本的数量、来源、状态时序和角色授权四类关系重新核对正文，不以先前结论替代复核； - 确认未受影响的权利义务继续有效，且没有未经授权的重大新增。 默认交付清洁正文，不输出内部状态模型、起草交接本、R编号、来源标记、分析过程、机器校验声明、无意义批注或整段高亮。用户要求 Word 时，先确定法律正文，再生成可编辑 `.docx`，不得让排版改变条款内容。