菜单
合同辅助审查。给一个「合同 + 签约依据」压缩包，解析出合同正文与全部依据材料（含扫描件、会议纪要截图），逐条对照公司标准合同模板，产出结构化 Markdown 审查报告——覆盖基础文本审查（金额、标点、错别字）、排版格式核对（正文字体字号、行距、页边距、条款编号连续性）、条款缺失与模板差异、与签约依据的一致性、风险合规提示。当用户提到合同审查、合同审核、合同比对、条款缺失、合同风险、签约依据、合同模板校验、排版格式检查、字体字号核对、起草合同把关时触发。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/mhaibaraai/movk-skills --skill contract-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
文件解包、文本抽取与排版样式画像基座。给一个 URL 或本地路径，返回压缩包内全部材料的结构化文本——zip 递归解压（修复中文文件名乱码）、PDF 抽文本、Word（docx）连表格一起抽，图片与扫描件本机联网时走 rapidocr、离线时交回平台识别。脚本零第三方依赖，离线环境直接可跑。另可产出排版样式画像（字体、字号、行距、缩进、页边距）并比对两份文件的差异。单个文件解析失败不影响其余材料，失败原因逐条如实报出。当用户提到压缩包解析、zip 解压、批量文件提取、PDF 文本提取、Word 文本提取、扫描件识别、图片 OCR、排版格式对比、字体字号提取、附件材料整理时触发。
检索中国石化、中国石油、中国海油等国内石化企业，埃克森美孚、壳牌、BP 等国际油气巨头，以及 IEA、OPEC、伍德麦肯兹、中国石油和化学工业联合会等研究机构的公开报告（年报、可持续发展报告、月度报告、研究报告），按核心数据、关键结论、市场趋势、投资动态、风险、产业链影响六个维度提炼洞察，输出深度分析 / 行业动态速览 / 多机构观点对比三类报告。当用户提到石化报告、能源研报、油气行业研究、石化市场洞察、炼化行业分析、油气企业年报解读、行业动态摘要时触发。
面向发改委、工信部、应急管理部三大核心部委及国务院、生态环境部、市场监管总局、能源局、财政部等关联部委，自动检索政策原文（含 PDF 附件全文）并解读，提炼政策层级、核心条款、适用范围、时间节点与处罚责任，评估企业合规影响，输出深度解读 / 要点速览 / 多政策对比三类报告。全流程零 API Key。当用户提到政策解读、法规分析、合规管理、发改委政策、工信部政策、应急管理部政策、政策总结、法规要点、政策影响分析时触发。
| name | contract-review |
| description | 合同辅助审查。给一个「合同 + 签约依据」压缩包，解析出合同正文与全部依据材料（含扫描件、会议纪要截图），逐条对照公司标准合同模板，产出结构化 Markdown 审查报告——覆盖基础文本审查（金额、标点、错别字）、排版格式核对（正文字体字号、行距、页边距、条款编号连续性）、条款缺失与模板差异、与签约依据的一致性、风险合规提示。当用户提到合同审查、合同审核、合同比对、条款缺失、合同风险、签约依据、合同模板校验、排版格式检查、字体字号核对、起草合同把关时触发。 |
审查一份已起草的合同：先把压缩包里的材料全部转成文本，再对照标准合同模板逐条找问题，最后出一份可直接转成 Word 的 Markdown 报告。解包、抽取与样式画像全部交给 file-extract 基座技能，标准模板 docx 随本技能分发在 references/templates/，本技能只负责审查维度、模板取用与报告写作。
运行约定：
references/x.md，基座技能写 ../file-extract/scripts/x.py（两者恒为兄弟目录）。执行时给命令加上技能根目录前缀，不要 cd 进技能目录。前缀取宿主加载技能时告知的 Base directory；拿不到就用 find / -name extract.py -not -path '*__pycache__*' 2>/dev/null | head -1 定位，取其上两级为 file-extract 的根目录。python3 调用，不要用 uv run——正式环境的沙箱完全离线，装不了任何包。压缩包的完整 URL 由上游给出（平台上传产出的是相对路径，需拼上平台域名）。一次调用取全：
python3 ../file-extract/scripts/extract.py --url <压缩包完整 URL> --out-dir ./材料 \
--platform-base <平台域名> --platform-token <平台 token>
--out-dir 必须给：Step 4 的排版核对要读合同正文的原始文件，不落盘就没得读。
平台参数用于把扫描件与图片交回平台识别（沙箱本地没有 OCR 能力）；拿不到 token 时去掉这两个参数照常运行，图片会原样列进 pending_ocr。token 只作为命令参数传入，绝不能出现在回复正文里。
输出分三处要读：files 是抽到正文的材料，pending_ocr 是待识别的图片与扫描件，errors 是没读到的材料。pending_ocr 与 errors 必须原样带进报告最后一节，不要把读不到的材料当成不存在。字段含义见 file-extract 的 references/format.md。
按文件名规则先筛：文件名含「合同」且扩展名为 pdf/docx 的是合同正文候选，其余材料一律视为签约依据（会议纪要、询比价申请表、结果审批表、成交通知书等）。
材料的目录结构不可依赖——同一批合同里，有的把依据放进 签约依据/ 子目录，有的与合同平铺在同一层。只认文件名与正文内容，不认路径层级。
候选多于一份时结合正文开头判定（真正的合同有甲乙双方、合同编号、签订地点这类要素），并在报告里写明选了哪一份、其余归入了依据。
从合同正文判定类型，选中 references/templates/<类型>.docx（四类的对应关系与模板版本见 references/templates/README.md），抽出模板全文：
python3 ../file-extract/scripts/extract.py --path references/templates/<类型>.docx --ocr off
四类都对不上时选最接近的一类，并在报告里说明该判定是近似的。报告要写明比对依据的是 README 表中的哪一版。
模板抽不到正文时，如实写明「未取得标准模板，条款缺失项与模板差异未做比对」，不要凭印象编造模板条款——编出来的「缺失条款」会直接误导起草人。
纯文本里没有字体字号，排版问题只能从原始文件取。合同正文与模板各出一份样式画像并比对：
python3 ../file-extract/scripts/styles.py --path ./材料/<合同正文文件> \
--template references/templates/<类型>.docx
输出的字段含义见 file-extract 的 SKILL.md。三条硬规矩：
not_comparable 必须原样写进报告。合同是 PDF 时首行缩进、对齐、右/下边距天然取不到——不写出来，用户会把「没报问题」读成「排版没问题」。diffs 里 match 为 false 的项，note（容差与口径）一并带上；带 note 的按「提示关注」分级，不要拔高。headings 是按字号推断的，措辞用「疑似标题」，不要断言层级错误。脚本跑不起来或合同正文没落盘时，写明「排版格式未核对」及原因，不要凭正文文本猜测字体字号。
审查维度是五组共 36 个编号检查项，每项只能判「合格 / 存在问题 / 无法判定」三态之一，见 references/review-dimensions.md；报告结构（固定七节）、结论用语规范与 Markdown 约束见 references/report-format.md。
材料缺失导致核不了的项，必须以「无法判定」进报告概览，不能因为没证据就跳过——漏掉某项与该项合格是两回事。
报告正文只输出 Markdown，不要包裹代码围栏——下游是平台「文档输出」节点，它吃的是纯 Markdown，围栏会被原样渲染进 Word。
「文件上传（类型选「其他（全部）」）→ AI 对话（挂本技能与 file-extract）→ 文档输出（Markdown 来源 = 该 AI 对话节点的 answer，格式 Word）」三个节点。
平台无法把文件路径作结构化输出带出节点，跨节点只有 answer 文本这一条通道——所以要传给下游的东西（图片 URL、材料正文）都得写进回复里。
材料里有扫描件或图片时，沙箱本地识别不了，它们会进 pending_ocr；要让平台的视觉模型把它们读出来，需要在编排里加一段（配置方式由部署方提供）。
files[].ocr 为 true 的材料由模型识别得来，印章、手写签名区域容易误识，引用金额、单位名称、日期前先与其他材料互证；只在一处出现且不合常理的数字，标为「疑似 OCR 误识，需人工核对」而不是当成合同问题pending_ocr 里的每一条都要在报告「材料完整性说明」列出文件名，并让依赖它的检查项判「无法判定」；uploaded 为 false 的还要写明未能上传，提示用户单独提供该材料errors 里该文件报 parse_failed 或 empty_text），直接告知用户重传或改用可编辑格式，不要拿依据材料硬凑一份审查结论