菜单
当用户需要对合同进行中文审核、条款修订、批注说明、模板比对、风险识别，且最终要直接输出写有逐条批注和修订痕迹的 docx 文件时，使用这个 skill。典型触发包括：审核合同、修改合同、按模板优化合同、输出修订版、输出批注版、输出修订批注版、检查定义词、检查条款逻辑、检查格式、输出清洁版。**特别注意：默认交付物必须是直接可打开的 docx 逐条批注修订版，不先向用户阶段性输出 md 或 txt 征求确认；凡涉及修订和批注，一律通过直接操作 DOCX 底层 XML 写入，不允许切换为其他实现路径，确保 WPS 兼容性。**
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
将法条/规范文件（.txt/.docx/.pdf）转为 Markdown。适用于用户要求“法条转 markdown”“pdf/docx 转 markdown”。处理 .pdf/.docx 时先检查是否已安装 mineru-ocr skill；未安装先引导安装，安装后优先用 mineru-ocr；仅在用户明确同意时再用本地回退方案。
Monitors ongoing risk signals and produces risk briefs for known vendors with QCC MCP integration. Activate for: supplier risk monitoring, vendor risk alert, supply risk, risk brief, supplier financial risk, credit rating downgrade, supplier operational risk, supplier compliance risk, geopolitical risk, Tier 2 risk, sub-supplier disruption, supply disruption, risk monitor, risk rating change, risk alert, distress signal, supplier news, country risk, supply chain resilience, CVA, administration, insolvency. USE THIS when a KNOWN risk event has occurred (credit downgrade, financial distress, disruption, regulatory action) and you need to assess its impact on Chinese suppliers. NOT for: classifying or scoring a vendor (use vendor-assessment), vendor onboarding or approval (use vendor-assessment), vendor Kraljic classification (use vendor-assessment), invoice processing (use invoice-reconciliation), carrier performance (use logistics-brief).
Classifies, scores, and evaluates vendors with QCC MCP integration for Chinese suppliers. Activate for: vendor assessment, classify vendor, vendor classification, Kraljic matrix, vendor tier, bottleneck vendor, strategic vendor, vendor review, supplier assessment, vendor onboarding, new vendor approval, vendor audit, annual vendor review, vendor scorecard, supplier evaluation, vendor qualification, approve vendor, vendor due diligence, vendor health check, vendor performance review, bottleneck supplier, vendor exit, risk profile of a vendor. USE THIS when the task is to CLASSIFY a vendor into a category (Strategic / Tactical / Commodity / Bottleneck), SCORE them across dimensions, or EVALUATE a vendor for onboarding/approval/exit. NOT for: ongoing risk signal monitoring or risk alerts (use supplier-risk), invoice reconciliation (use invoice-reconciliation), carrier performance review (use logistics-brief), spend category analysis (use spend-analysis).
合同审核技能，通过添加批注方式审查合同（不修改原文）。采用四层审核模型（主体核验、基础审核、商务条款、法律条款），生成结构化批注（问题类型、风险原因、修订建议），风险等级通过审核人名称编码，并生成合同概要、综合审核意见和Mermaid业务流程图（含渲染图片）。输出语言遵循合同语言。支持双模式企业核验：QCC CLI 用于主体信息核验（终端直连），QCC MCP 用于风险穿透预警（深度分析）。
开展法律检索、时效审查、法律备忘录写作、模板输出与结论快报。适用于按国别或法律领域分析问题、生成正式研究结果时。
中国法律尽职调查底稿与报告撰写工具。支持公司主体尽职调查的完整工作流： 项目初始化→底稿逐章撰写→完整性检查→报告生成。 涵盖10大调查板块（主体资格、股权结构、公司治理、核心资产、业务经营、 财税、劳动人事、债权债务、诉讼仲裁、其他事项）。 输出专业规范的尽调底稿（.md）和尽调报告（.md）。 Use when user says '尽职调查', '尽调', '底稿', 'due diligence', 'DD报告', '尽调报告', '法律尽调', or needs to write legal due diligence working papers or reports.
| name | Red-Circle-Contract-review |
| description | 当用户需要对合同进行中文审核、条款修订、批注说明、模板比对、风险识别，且最终要直接输出写有逐条批注和修订痕迹的 docx 文件时，使用这个 skill。典型触发包括：审核合同、修改合同、按模板优化合同、输出修订版、输出批注版、输出修订批注版、检查定义词、检查条款逻辑、检查格式、输出清洁版。**特别注意：默认交付物必须是直接可打开的 docx 逐条批注修订版，不先向用户阶段性输出 md 或 txt 征求确认；凡涉及修订和批注，一律通过直接操作 DOCX 底层 XML 写入，不允许切换为其他实现路径，确保 WPS 兼容性。** |
这个 skill 用于处理中文合同审核与修改任务，重点解决以下问题：
本 skill 的目标不是整篇重写合同，而是：先识别问题，再结合客户合同、模板合同和交易逻辑，进行克制、精准、可落地的最小必要修订。
需要审核方法和条款维度时，读取 references/review-playbook.md。
需要输出格式、批注模板、报告模板和文件命名规则时，读取 references/output-spec.md。
凡需要输出带修订痕迹或批注的 docx 时，都必须读取 references/xml-revision-spec.md，并走 XML 直改流程。
如原文件、指令文件或工作目录位于中文路径，或路径编码表现不稳定，优先运行 scripts/internal_stage_review_inputs.ps1，用 PowerShell 按通配符复制到英文临时名后再解包 XML；不要把中文绝对路径直接喂给 Python。scripts/internal_generate_review_docx.ps1 在检测到非 ASCII 路径时也必须自动接入该 staging 流程。
对外只暴露 scripts/run_generate_review_docx.ps1；不要再让用户直接调用 scripts/internal_generate_review_docx.ps1、scripts/internal_stage_review_inputs.ps1 或 Python 实现。不要单独做环境检测，直接运行包装器。
当用户出现以下诉求时，直接使用本 skill：
如果用户没有补充上下文，默认采用以下设定：
docx 的批注正文默认强制锁定为 宋体，对应 OOXML 字体名 SimSun修订批注版 docxdocx 逐条批注修订版，不先向用户输出 md、txt 或其他阶段性文稿再等待确认docx 文件本身，内部中间材料不得先以审查报告、风险清单或摘要形式发给用户清洁版 docx、txt 审查报告、md 审核意见在正式审核前，优先确认以下事项；如用户未提供，仅对会实质影响审核结论的关键信息主动追问。输出模式按默认规则直接落 docx，不因 md/txt 阶段稿单独追问，也不额外追问“是否帮你生成修订批注版 docx”；除非用户明确表示暂不落版，否则默认直接生成 docx：
合同类型 — 例如保密协议、采购合同、服务合同、SaaS 合同等。立场 — 偏甲方、偏乙方，还是中性审查。输入材料 — 是否有客户合同、客户模板、优秀模板、条款清单、项目背景。修订人名称 — 优先使用用户提供的作者名称；如用户未提供，不阻塞落版，默认写入 合同审核AI，后续如用户指定名称再覆盖。输出模式 — 只要用户意图已包含审核、修改、批注、修订版、修订批注版或清洁版中的任一项，就直接进入对应 docx 落版；仅当用户明确要求时，再追加清洁版或其他格式，不以 md/txt 阶段稿向用户征询确认。新增权限 — 是否允许新增完整条款，还是只能局部修改。如果用户给的是复杂交易文件，还应当可选确认：
所有输出都必须遵守以下原则：
docx 的批注内容、修订建议、建议条款、风险说明必须使用简体中文，不得夹带繁体中文表述。word/comments.xml 的批注正文必须强制写入 宋体 字体设置，至少包含 w:rFonts 的 w:eastAsia="SimSun"，并同步写入 w:ascii、w:hAnsi、w:cs 为 SimSun。合同审核AI 写入 author 字段，不因作者名称缺失阻塞 docx 生成。docx，以逐条批注和修订痕迹呈现，不先单独交付 md 或 txt 中间稿。docx，不得作为阶段成果发给用户等待确认。默认从以下六个维度审查合同，优先级从高到低为：
准确 — 条款表意是否唯一、确定、无歧义。逻辑 — 条款间是否勾稽正确、机制是否冲突、是否覆盖交易关键步骤。规范 — 是否符合交易惯例、法律逻辑、市场通用原则。简约 — 是否存在同义反复、冗余表达、无效堆叠。流畅 — 行文是否顺、是否易于理解。工整 — 标题、序号、标点、页码、格式、字体、行距是否统一。问题类型默认区分为：
风险等级默认分为：
高风险中风险低风险先识别用户提供了什么：
如果存在多个模板，默认规则是：
在正式改文前，先判断：
docx 中修订痕迹和批注应显示什么修订人名称对于复杂合同，可先形成简化版条款清单，再进入逐条审核。
逐条审核时，优先找以下问题：
对每一个问题，先决定属于哪一类：
可直接修改建议修改但需确认仅提示风险，不直接改动如果条款带有明显立场性、商业性、谈判性，应优先标记为"建议修改但需确认"或"仅提示风险"。
修订时遵守以下规则：
每个重点问题的批注固定按以下结构输出：
问题：该条款目前存在什么问题风险：为什么有风险，会导致什么后果修改建议：建议如何改建议条款：给出准确、可直接替换或增补的条款文本修改依据：依据模板 / 法律逻辑 / 交易结构（如有必要）批注必须避免以下写法：
除非后面紧接着给出明确的修改方向和具体条款。
重要：凡是修订版、批注版、修订批注版，都必须通过直接操作 DOCX 底层 XML 写入修订和批注，确保 WPS 兼容性。
生成批注版 docx 时，必须遵循以下 XML 结构规范：
使用标准 Track Changes XML 结构
<w:del> 标签包裹，设置 w:del 属性<w:ins> 标签包裹，设置 w:ins 属性<w:commentRangeStart> 和 <w:commentRangeEnd> 标记范围word/comments.xml 中定义WPS 兼容性要求
w:author, w:date, w:idYYYY-MM-DDThh:mm:ssZword/settings.xml 中启用 w:trackRevisions 和 w:showRevisionsXML 命名空间声明
<w:document xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"
xmlns:wps="http://schemas.microsoft.com/office/word/2010/wordprocessingShape"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006">
修订标记示例
<!-- 删除内容示例 -->
<w:p>
<w:r>
<w:del w:author="审核人" w:date="2026-03-19T10:00:00Z" w:id="1">
<w:t>原条款内容</w:t>
</w:del>
</w:r>
</w:p>
<!-- 插入内容示例 -->
<w:p>
<w:r>
<w:ins w:author="审核人" w:date="2026-03-19T10:00:00Z" w:id="2">
<w:t>修订后条款内容</w:t>
</w:ins>
</w:r>
</w:p>
<!-- 批注范围标记 -->
<w:p>
<w:commentRangeStart w:id="101"/>
<w:r><w:t>需要批注的文本</w:t></w:r>
<w:commentRangeEnd w:id="101"/>
<w:r>
<w:commentReference w:id="101"/>
</w:r>
</w:p>
comments.xml 结构
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:comments xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
<w:comment w:id="101" w:author="审核人" w:date="2026-03-19T10:00:00Z">
<w:p>
<w:r>
<w:rPr>
<w:rStyle w:val="CommentText"/>
<w:rFonts w:ascii="SimSun" w:hAnsi="SimSun" w:eastAsia="SimSun" w:cs="SimSun" w:hint="eastAsia"/>
</w:rPr>
<w:t>批注内容：问题描述 + 风险分析 + 修改建议</w:t>
</w:r>
</w:p>
</w:comment>
</w:comments>
settings.xml 配置
<w:settings xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
<w:trackRevisions w:val="1"/>
<w:showRevisions w:val="1"/>
<w:revisionView>
<w:markup>1</w:markup>
</w:revisionView>
</w:settings>
解压 DOCX 文件
word/document.xml、word/comments.xml 等解析 document.xml
写入修订标记
<w:del> 标签<w:ins> 标签更新 comments.xml
<w:comment> 节点更新 settings.xml
重新打包 DOCX
.docxscripts/run_generate_review_docx.ps1；由包装器转调 scripts/internal_generate_review_docx.ps1 的 PowerShell + OOXML 直改流程scripts/internal_stage_review_inputs.ps1 先复制到英文临时名，再进入解包和 XML 处理流程scripts/run_generate_review_docx.ps1；脚本运行时按既有 PowerShell 流程直接尝试可用 ZIP 后端，不改变“修订和批注一律通过 XML 直改”的实现约束默认输出以下文件：
合同名称 - 修订批注版.docx默认输出目录：
合同名称-Output 文件夹如果用户明确要求清洁版，也可额外输出：
合同名称 - 清洁版.docx除非用户明确要求，否则不单独输出 审查报告.txt、审核意见.md 或其他文本阶段稿。
默认禁止以下做法：
md 审核意见再等待用户确认是否落版txt 风险清单再等待用户确认是否写入 docx如需使用结构化文本帮助生成 docx，只能作为内部过程，不作为对用户的阶段性交付。
只有在用户明确要求时，才额外输出 txt 审查报告。
如果用户同时要求 docx 和 txt 审查报告，默认规则是先或同时交付 docx，txt 只能作为附加产物，不得先单独交付 txt 再等待是否落版。
审查报告可按以下结构输出：
一、合同概况二、修改意见表三、格式及一致性问题四、建议进一步确认事项其中“修改意见表”必须使用固定列表头：
| 原条款 | 存在风险 | 修改建议 |
|---|---|---|
| 原条款全文或关键摘录 | 说明该条款的具体风险、可能后果，必要时可在单元格内补充条款定位、风险等级、问题类型 | 必须写明可直接替换或直接增补的具体条款内容，不得只写空泛结论 |
表格输出要求：
原条款 尽量摘录原文关键内容，避免只写条号存在风险 应写明风险成因和可能后果，必要时可补充条款定位、风险等级、问题类型修改建议 必须包含准确、可直接落地的条款文本，能够直接替换或直接增补在输出最终文件前，必须检查以下事项：
docx 逐条批注修订版，且未对用户单独交付 md/txt 阶段稿author 是否已按用户确认的修订人名称写入只有同时满足以下条件，才算审核合格：
最不能接受的问题包括：
在完成审核后，主动提醒用户下一步可选动作：