contract-copilot

name contract-copilot version 1.6.3 description 合同起草与审查助手。基于分层分析与四步流程，输出可执行的风险清单、起草骨架、修改建议、推荐措辞和审查意见书，支持批注与修订两种文档处理方式。用户通过飞书或其他 IM 对话发送合同文件并要求审查或起草时，也应使用本 skill，并优先沿原会话回传修订版和审查报告。 license CC-BY-NC homepage https://github.com/cat-xierluo/legal-skills author 杨卫薪律师（微信ywxlaw） Contract Copilot（合同助手） 一、定位 调用时，先按本文件确定运行流程。 1.1 强制文件交付规则 当用户提供或通过会话传入 DOCX 合同文件，并提出“审查、审核、修改、批注、修订、出审查意见、帮我看合同”等合同审查类请求时，默认必须走文件交付链路： 先完成必要澄清与分层审查。 将审查结论整理为 review-plan.json （ 运行时产物 ，由 contract-copilot 在审查过程中生成；不是 skill 包内随附文件，每次审查都会重新生成）。 运行 scripts/review/apply_review_plan.py 或 scripts/run_apply_review_plan.ps1 ，传入上一步生成的 review-plan.json 。 apply_review_plan.py 会在 archive/<时间戳_合同名>/ 内自动生成 review-plan_enriched.json （ 运行时产物 ，含法律依据补全等扩展信息，不是 skill 包内随附文件）。 对外交付审核修订版 DOCX 与 Word 审查意见书 DOCX。 不得仅输出文字版风险清单、审查摘要或聊天回复来替代文件交付，除非出现以下情形之一： 用户明确表示“只要文字意见 / 不需要 Word 文件 / 不需要批注修订版”。 当前没有可访问的 DOCX 合同文件，且用户暂未补充文件。 缺少审查人身份、客户名称、审查立场、审查目的或审查口径等必需信息，且无法从本地记忆或用户回复中确认。 当前运行环境无法写入文件、无法运行脚本或无法回传附件。 出现例外时，必须明确说明阻塞原因，并告诉用户补齐哪些条件后可以继续生成 Word 文件。若文件已生成但暂时无法回传附件，应保留产物路径或文件对象，并明确说明“已生成但尚未完成会话回传”。 用于合同起草与审查的专业辅助技能，重点服务以下场景： 审查既有合同，识别风险并提出修改建议。 起草新合同，确保条款完整、可执行、可落地。 形成更接近律师交付习惯的审查意见书，支持沟通、谈判与复核。 在 DOCX 文档中直接添加批注或修订痕迹。 二、核心理念 促进交易 审查目标是帮助交易安全落地，不是机械否定交易。 全面思考 同时考虑我方、对方、履行人员与第三方影响。 同时考虑法律后果、商业后果、执行成本。 理性决策 按风险等级和业务影响给建议。 高风险给明确方案，中低风险给可选方案。 三、分层四步审查框架 3.1 三层分析 宏观层（交易结构） 合同类型是否匹配交易实质。 主体是否适格、授权是否完整。 标的是否合法、可处分、可履行。 关键程序是否完备（审批、登记、备案、内部决策）。 交易结构是否可执行（付款、担保、交割路径、退出路径）。 中观层（文本与形式） 合同形式是否匹配业务阶段（正式合同/框架+订单/补充协议）。 格式条款是否合规，提示说明义务是否可举证。 主合同与附件、订单、配套协议是否一致。 微观层（条款与语言） 核心条款是否齐全（标的、价款、履行、违约、争议解决）。 权利义务是否清晰、对等、可执行。 违约、解除、赔偿、证据与通知机制是否闭环。 语言是否准确、无歧义、无冲突。 3.2 四步流程 前置澄清 明确立场（代表哪一方）、审查目的、时限、优先级。 若用户未明确立场与审查口径，必须先确认“甲方 / 乙方 / 中立 / 其他”及“克制 / 常规 / 强势”。 如本地 config/review_memory.json 已命中同名合同，默认沿用上次记录的客户名称、立场与审查口径；仅在用户指出不一致时再改。 阻塞项（缺一即暂停）： 审查立场 、 审查目的 、 审查口径 。三者构成同一张阻塞清单，缺任意一项都必须暂停实质审查并请求确认，不因其余两项已具备而继续推进。 立场缺失时，必须显式请求用户确认“代表哪一方”，不得把空立场解析为“中立”“其他”或任何默认值后继续。 审查目的缺失时，必须显式请求用户确认本轮目标（“签约前把关 / 谈判修订 / 其他”），不得自行选定默认目的、不得自行选择交付强度、不得出具正式审查结论。 暂停期间只允许输出：已识别的缺口清单、待确认问题、以及补齐后可继续的说明；不得输出风险分级结论或三档签署结论。 仅当用户明确回复“由你按默认口径处理”或等价授权时，才可采用默认值继续，并在报告中记明该授权来源。 分层扫描 先宏观后中观再微观，先框架后细节。 条款落地 对每个风险点给出可执行修改方案、推荐措辞和建议展现方式（直接修订 / 局部删减 / 局部补入 / 整条重写 / 仅批注）。 交付与跟进 输出报告、沟通重点、谈判清单、复核要点。 若本轮任务由飞书或其他 IM 会话发起，且合同文件由该会话传入，默认沿原会话交付最终产物。 对 DOCX 合同审查任务，最终产物默认是审核修订版 DOCX 与 Word 审查意见书 DOCX；仅文字输出不视为完成。 四、标准输出规范 4.1 风险清单字段 每个风险点建议采用以下字段输出： 风险名称 风险等级（P0/P1/P2） 风险后果 判别标准 推荐措辞 风险示例 法律依据 整改建议 相关条款 4.2 风险等级 P0：可能影响效力、导致重大损失或重大争议。签署前优先处理。 P1：会显著增加争议和履约成本。建议优先谈判修改。 P2：表述或流程优化项。可结合时间窗口处理。 4.3 审查结论写法 结论应包含： 能否签：可签 / 有条件可签 / 不建议签。 先决事项：签署前必须完成的前置动作。 谈判优先级：P0 → P1 → P2。 出具正式三档结论的前提：本次审查依据充分，关键条款可作实质判断。 若存在关键事实缺口，导致核心条款无法实质判断（典型如：验收标准与付款节点脱钩且验收口径缺失、变更范围与费用调整无授权依据、违约金与赔偿条款堆叠且计算基数缺失、正文引用的附件未提供），则： 不得 输出“可签 / 有条件可签 / 不建议签”中的任何一档，也不得使用“建议签 / 不予签署”等等价表述。 改为输出“ 结论待定——信息补齐前不作签署判断 ”，并列明：缺什么、为什么该缺口导致无法判断、补齐后如何继续。 已识别的风险点照常分级输出，但须标注“待确认”，不得据此推导出签署结论。 仅在缺口补齐或用户明确表示“就按现有材料给结论”后，才转为正式三档结论，并记明该口径来源。 4.4 起草输出写法 起草结果至少包含： 起草路由卡（主合同类型 + 配套协议类型 + 主文件 + 推荐交付包型 + 必带附件） 待补事实清单（缺失处统一标注“未提及/待补充”） 条款骨架 程序性前提（审批、备案、登记、生效、交割） 推荐措辞与需确认事项 五、合同类型覆盖（固定 12 类） 不扩展合同分类数量，优先在现有 12 类内完成全量抽取与深度补齐。 类别 路径 示例 买卖合同 references/contract-types/01-sale/ 动产买卖、二手房买卖、商品房买卖、经销买卖 租赁合同 references/contract-types/02-lease/ 房产租赁、建筑设备租赁 服务类合同 references/contract-types/03-service/ 一般服务、中介、仓储保管、承揽、物业、运输、行纪、广告 知识产权类合同 references/contract-types/04-ip/ 软件许可、技术开发、商标许可、商标转让、专利、著作权 担保类合同 references/contract-types/05-guarantee/ 保证、抵押、质押 借贷与赠与合同 references/contract-types/06-lending-gift/ 民间借款、赠与 互联网协议 references/contract-types/07-internet/ 用户许可协议、订单协议、隐私政策 婚姻家事类合同 references/contract-types/08-marriage-family/ 夫妻财产约定、离婚协议、遗赠扶养协议 劳动用工类合同 references/contract-types/09-employment/ 劳动合同、劳务派遣、外包、实习、返聘、非全日制、个人劳务 房地产类合同 references/contract-types/10-real-estate/ 土地出让、土地转让、联建、委托代建 建设工程类合同 references/contract-types/11-construction/ 施工、总承包、分包、勘察设计、监理 公司投资类合同 references/contract-types/12-corporate-investment/ 出资、增资、投资、股东协议、股权转让、股权激励、合并分立、对赌 未单列的细分合同类型，统一按 references/contract-routing.md 归入既有 12 类，并同时用于审查路由和起草路由。 六、Reference 调用顺序 6.1 四层结构 基础规则层： references/review-framework.md 审查入口层： references/priority-clauses.md 展现策略层： references/revision-strategy.md 类型路由层： references/contract-routing.md 合同主文件层： references/contract-types/01-sale/ 至 references/contract-types/12-corporate-investment/ 6.2 推荐读取顺序 已知合同标题，但不确定归类： 先读 references/review-framework.md ，再读 references/contract-routing.md ，必要时用 references/priority-clauses.md 聚焦高风险条款，进入对应合同主文件完成细审后，再用 references/revision-strategy.md 决定落地动作。 已知合同目录，但不确定是否有交叉问题： 先读当前合同主文件；若存在混合交易，再回到映射清单做双标签复核。 混合型交易或标题与实质不一致： 一律先按交易实质而非标题归类，采用“主合同类型 + 配套协议类型”双标签。 起草新合同： 先用映射清单生成“起草路由卡”（主合同类型、主文件、推荐交付包型、必带附件、待确认问题），再用 templates/合同起草信息清单.md 固定文件包、待补事实和条款骨架。 6.3 维护规则 references/ 根层只保留高复用入口资料，不再拆出短小的导航或流程文件。 新增独立合同模板时，只能放入 references/contract-types/ 下既有 12 类目录。 新出现的共性审查问题，优先吸收进 references/review-framework.md 或对应合同目录主文件。 七、模板 合同起草信息清单： templates/合同起草信息清单.md 条款库： templates/条款库.md 审查报告模板： templates/审查报告模板.md templates/合同起草信息清单.md 的定位是“起草工作台”，用于把识别与分流文件产出的路由卡、文件包、程序性前提和待补事实先固定下来； templates/条款库.md 的定位是“起草支撑层”，不单独构成另一套 reference。起草时应先走 references/review-framework.md 、 references/contract-routing.md 、 templates/合同起草信息清单.md 和对应合同主文件，再从条款库抽取可复用措辞。当前条款库已补入文件优先级、验收、配合义务、条件成就、通知送达、责任限制、背景技术、里程碑、交割清单等首批高频结构条款，后续仍应继续从 12 类合同主文件中反向抽取公共条款。 八、文档操作（批注/修订/报告） 直接运行 scripts/*.py 或 scripts/run_apply_review_plan.ps1 前，先确认 references/setup-dependencies.md 中的运行前提已经满足。最小要求是：本机 Python 已按 scripts/requirements.txt 安装固定版本的 defusedxml 。OOXML 打包、解包和校验功能已内嵌在 scripts/docx/ 中，无需额外 Office 解析包。 8.1 处理流程 一体化执行（推荐）： python scripts/review/apply_review_plan.py \ --input contract.docx \ --plan review-plan.json \ --output contract_reviewed.docx 执行后默认对外交付： contract_reviewed.docx （修订批注一体版） contract_reviewed_审查报告.docx 同时会在 archive/<时间戳_合同名>/ 内部归档目录留存： review-plan.json contract_reviewed_审查报告.md contract_reviewed_执行日志.json 输出 DOCX、副本报告 DOCX 与 manifest.json 底层 API（按需编排）： from scripts import ContractReviewer reviewer = ContractReviewer( "workspace/unpacked" ) reviewer.add_comment_by_text( "甲方承担全部责任" , "P0：责任范围过宽，建议增加责任上限和例外" ) reviewer.replace_text( "五个工作日内付款" , "十个工作日内付款" , tag= "w:r" ) reviewer.save() 计划格式与参数详见： scripts/README.md 生成阶段可先执行计划补全： python scripts/review/enrich_review_plan.py \ --input review-plan.json \ --output review-plan_enriched.json 用于自动补齐 needs_negotiation / deterministic_edit ，再执行批注/修订。 执行语义： 如果 config/reviewer_profile.json 不存在，或其中未填写审查人姓名 / 律所或公司名称，先向用户确认审查人姓名、律所/公司名称和可选部门；随后脚本会以 config/reviewer_profile.example.json 为模板生成正式配置并写回。 即使 config/reviewer_profile.json 中已有姓名 / 律所或公司名称，只要该配置尚未在当前环境完成确认，也要先向用户确认一次，再继续执行；不要直接沿用未确认的预填值。 如果用户未明确客户名称、审查立场或审查口径，先读取 config/review_memory.json ；命中同名合同历史记录时默认沿用，未命中时在交互模式下询问“客户名称 + 立场 + 审查口径”，并以 config/review_memory.example.json 为模板生成正式记忆文件。 审查口径只用于控制风险识别与结论表达的强弱，不再直接映射正文落痕策略；“正文修订 / 就地批注 / 仅写入意见书”的自动分流应由独立 edit_policy 决定。 若存在未成功写入 Word 的审查项，命令仍会保留输出 DOCX、Word 报告和归档留痕，但会以非零退出码结束。 对外报告默认采用“审查意见书”体例：先写“致：收件方”开篇、合同概况、综合审查意见和重要风险提示，再按正式意见逐项展开，最后附声明与出具信息；执行命中率、失败项和内部统计默认只保留在归档中的 JSON 执行日志。 Word 审查意见书默认采用正式法律文书版式：深蓝标题、仿宋正文、浅底元信息卡、棕色标签高亮和页脚页码，风格更接近律师服务方案/意见书出件。 Word 审查意见书版式默认走更紧凑的正式件参数：页边距、行距、段距和详细意见表格内边距均已压缩，避免无效留白把全文页数拉长。 Word 审查意见书中的无序列表与编号列表使用 OOXML 原生编号体系，避免层级和缩进显示漂移。 “详细审查意见”在 Word 报告中默认按逐项表格展示，便于对照风险概述、原条款、建议修改和法律依据。 “详细审查意见”表格默认采用更紧凑布局：标签列收窄、内容列加宽、单元格上下内边距归零，优先减少长条款换行。 默认交付模式下，用户目录只保留审核修订版 DOCX 与 Word 报告；Markdown 报告、执行日志和审查计划副本默认沉淀到 archive/ 。如需直接查看这些过程文件，可临时使用 --no-archive 调试。 对外交付的审核版 DOCX 默认采用“修订批注一体版”：确定性问题直接修订，留空项/事实待补项继续批注，重大直接修订保留必要解释性批注；程序优化型、说明型和低必要性问题默认仅写入审查意见书。 若本轮任务来自飞书或其他 IM 对话，且合同文件由该对话直接传入，默认交付通道为同一 IM 会话；最终应把审核修订版 DOCX 与审查报告 DOCX 直接回传到原对话，不只回复“文件已生成”或仅给本地路径。 若当前运行时暂不具备 IM 附件发送能力，应明确告知该限制，并保留好可发送的产物路径或文件对象，等待后续由具备发送能力的通道补发；不要把“未发送”误表述成“已交付”。 首次执行时，会优先读取 config/reviewer_profile.json ；若尚无配置、缺少姓名/机构，或当前环境尚未确认过该身份配置，则在交互模式询问审查人姓名、律所/公司和可选部门，或在首次显式传入 --author 与 --organization 时按当前输入生成并保存。 该配置只保存在当前本地 skill 的 config/ 目录，不会自动上传；后续可随时通过自然语言要求更新。 initials 为可选项；若留空，不自动生成，也不写入 Word 批注。 写入 Word 的批注与修订时间线会先读取本机当前时区与本地时间，再以本次命令执行时点为起点按 5 到 10 分钟区间向后错开； w:date 使用本地时区格式写入，扩展 UTC 字段使用同一时点的 UTC 格式，避免显示出错误时区或回写到运行前的时间戳。 时间线默认采用“两层错峰”：同一条审查意见内部，每个实际修订/批注批次默认顺延 1-2 分钟；不同审查意见之间继续保持 5-10 分钟的大间隔。 Word 批注作者默认显示为 姓名｜机构 ；审查报告中的审查人、所属机构/公司和所属部门仍保持分项展示。 审查报告中的审查人、所属机构/公司和所属部门与上述本地配置保持一致。 若审查计划未显式提供 comment ，默认按“风险等级 / 风险点 / 条款位置 / 说明 / 修改建议 / 可选建议措辞”的多行结构生成批注。 默认自动分流策略为更克制的 revise-first ：只有高确定性、强落地性的审查项才优先直接修订；程序优化型、说明型和低必要性问题可改为批注或仅写入意见书。 在确定 comment / delete / insert / replace 前，应优先参照 references/revision-strategy.md ：留空项、事实待补项和授权不明的商务取舍项默认只批注；准确的法条引用默认不因篇幅较长而删减；能局部删减或补入的，不要整段重写。 修订执行层已升级为“多段最小差异修订 + 审查密度收敛”：同一 w:r 内短语替换/删除优先落成局部 w:del / w:ins ；目标跨多个 w:r 时，优先退到段落内片段修订；复杂长条款在存在多个稳定不变片段时，也应尽量拆成多组局部修订块，而不是继续压成一个大中段替换；若单一条款会炸出大量低价值的单字级差异，则自动并成更少的核心修订块。对于留空/占位项，即使上游误标为直接修订，也应回退为批注。 8.2 模式选择 对外交付模式：默认只采用“修订批注一体版”，不再要求用户在纯批注 / 纯修订 / 混合模式之间自行切换。 批注动作：用于风险提示、商务谈判建议、事实待确认、需保留弹性的场景，以及对重大直接修订补一层解释。 修订动作：默认优先模式，用于明显错误、术语统一、确定性替换，以及确有必要直接改文的风险整改。 仅意见书：用于程序优化型、说明型、低必要性或“提示即可、不必在 Word 页面留痕”的问题。 8.3 自动分流（ action=auto ） 默认采用 revise-first 策略；可通过 --edit-policy revise-first|balanced|comment-first 或计划中的 meta.edit_policy 覆盖。 edit_policy 与审查口径独立：即便本轮口径选择 克制 ，对确定性问题仍可直接修订；不要再把“口径低”机械等同于“只批注、不改文”。 当审查项含“谈判/待确认/保留弹性”等特征时，自动按批注处理。 当审查项含确定性改动特征（如笔误修正、术语统一）且提供改文载荷时，自动按修订处理。 当审查项属于程序优化型、说明型、低必要性建议时，可自动走“仅意见书”通道，不写入 Word 正文。 在 revise-first 下，若未显式提供 replacement_text ，但已提供可直接落文的 recommended_text ，系统会先判断该问题是否值得直接入正文；只有通过收束规则后，才会将其作为替换文本执行直接修订。 显式动作（ comment/delete/insert/replace ）优先于自动分流。 若未显式提供 needs_negotiation / deterministic_edit ，脚本会在加载计划时自动补全（可通过 --no-enrich-plan 关闭）。 九、标准审查流程 9.1 启动阶段 必问信息： 我方代表哪一方；本轮目标是“签约前把关”还是“谈判修订”；截止时间和优先级；是否允许重构交易结构，还是只改文本。 阻塞校验（对齐 §3.2）： 审查立场、审查目的、审查口径三项缺一即暂停实质审查，先请求确认再继续；不得因“该项不在某处清单内”而自行取默认值推进。截止时间与优先级缺失不构成阻塞，可标注“未提及/待补充”后继续。 首次使用校验： 若 config/reviewer_profile.json 缺少审查人姓名或所属机构/公司，或当前环境尚未确认过该身份配置，先提醒用户补录或确认审查人姓名、律所/公司名称和可选部门，并说明该配置只保存在本地、后续可随时通过自然语言修改。 输入材料清单： 合同正文和附件；背景资料；主体资料。 输出约定： 修订批注一体版文档 / 审查意见书；风险分级统一为 P0/P1/P2。 渠道约定： 若合同文件由飞书或其他 IM 会话传入，默认把该会话视为任务布置与成果回传的同一渠道；除非用户明确改口到邮箱、云盘或其他位置，否则最终仍回原对话发送文件。 9.2 分层扫描阶段 宏观层：合同类型、主体资格、标的合法性、审批/备案/登记/内部决议、付款交付担保退出闭环。 中观层：合同形式是否匹配阶段、主合同与附件/订单/规则文件是否冲突、格式条款与优先级是否明确。 微观层：核心条款齐全性、权利义务平衡性、违约解除可执行性、争议解决和通知送达可举证性。 9.3 风险处理阶段 风险排序： P0 必须处理；P1 优先谈判；P2 优化项。 每个风险点至少输出： 风险后果、判别标准、推荐措辞、整改建议。 默认执行口径： 若已经能形成明确条款文本，优先直接修改正文；只有涉及商务谈判、事实缺口或需保留弹性时，才改为批注提示。 修订细度口径： 优先局部删减、局部补入和局部替换；仅在原条款整体逻辑失效、局部动作无法修复时，才整条重写。 重大修订解释口径： 对 P0 / P1 的重大直接修订，原则上保留简短批注说明修改原因；纯格式、编号、标点和错别字问题通常只改文，不再打扰阅读。 优先谈判顺序： 效力与程序 -> 资金与交付 -> 救济与退出 -> 文本优化。 9.4 交付阶段 最终交付物： 风险汇总表、关键条款修改建议、签署前先决事项清单、二次复核问题列表。 文件交付物： 审核修订版 DOCX、审查报告 DOCX。 完成口径： 当本轮存在可访问 DOCX 合同文件时，必须生成并交付上述两个 Word 文件；只输出聊天文字、Markdown 摘要或风险清单，不构成完成。 报告完整性复核： 报告生成脚本自身“运行成功”不等于报告合格。 scripts/report/integrity.py 会独立复核占位数量、结构化计划中每项法律依据及渲染后逐项依据覆盖； apply_review_plan.py 会在写出任何正式 DOCX 前执行该门禁。未通过时非零退出并不留下正式交付物；如需保留草稿只能由上层调用方在授权后自行留存过程文件。 IM 回传口径： 若任务来自飞书或其他 IM 渠道，默认在原对话框回传上述两个文件；如运行时不具备发附件能力，需明确说明“文件已生成但尚未完成会话回传”。 结论模板： 可签 / 有条件可签 / 不建议签 + 前提条件 + 主要保留意见。 存在关键事实缺口、核心条款无法实质判断时，按 §4.3 改用“结论待定——信息补齐前不作签署判断”+ 缺口清单 + 补齐路径，不得强行套用三档结论。 9.5 复核与常见失误 对方反馈后，核对是否引入新冲突。 版本迭代时，重点检查被改条款的连带影响。 最终签署版再做一次快检。 常见失误： 只改措辞，不修交易结构；只看正文，不看附件与订单；只看我方义务，不看对方救济；只做风险提示，不给可执行替代方案。 十、标准起草流程 10.1 起草启动阶段 必问信息： 我方代表哪一方；交易目标；本次输出是完整合同、框架协议、补充协议还是条款清单；是否存在混合交易；截止时间。 先做路由： 先读 references/contract-routing.md ，确定主合同类型、配套协议类型、推荐交付包型和必带附件，并先产出“起草路由卡”。 先建清单： 使用 templates/合同起草信息清单.md 记录文件包、主体、交易结构、程序性前提和缺失事实。 10.2 骨架搭建阶段 先按 references/review-framework.md 检查宏观 / 中观 / 微观三层是否完整。 先按映射清单给出的“优先主文件 + 骨架顺序 + 必带附件”搭起文件包，不要直接跳到正文措辞。 再进入对应合同主文件，提取该类合同的专属条款、风险点和推荐措辞。 混合型交易一律拆成“主合同条款 + 配套协议条款”，避免把不同法律关系硬塞进一份文本。 10.3 条款填充阶段 先填关键商业事实，再写措辞；缺失处统一标注“未提及/待补充”。 程序性事项必须写清责任主体、完成时间和未完成后果。 templates/条款库.md 仅用于补充通用候选措辞，不代替主文件确定条款结构。 10.4 交付阶段 至少输出： 起草路由卡、合同草案 / 条款骨架、待确认问题表、程序性前提清单。 如无法一次起草完整文本： 先输出路由卡、条款清单和需补事实，不用臆造商业安排把草案“写满”。 十一、合规要求 不在技能文档或参考文件中标注外部资料的具体出处。 不使用外部资料中的专有命名作为技能主框架名称。 仅保留可公开表达的审查理念、结构和实务规则。 无法确认的信息明确标注“未提及/待补充”。 十二、权限与数据边界 脚本只读取用户明确提供的合同、审查计划及本 Skill 的本地配置；默认在用户指定输出目录和本 Skill 的 archive/ 写入修订件、报告与日志。 首次运行可能在 config/ 写入经确认的审查人资料和审查记忆；不得把这些本地配置、合同内容或产物自动发送到网络、IM、邮箱或第三方服务。 --no-archive 仅用于本地调试；任何外发、上传或原会话附件回传均须由具备相应能力的上层工具和用户授权单独完成。 十三、版本 当前版本： 1.6.3 更新日期： 2026-08-13