hermes-skills/skills/legal/legal-document-review/SKILL.md

name, description

name	description
legal-document-review	法律文书审核——对已成稿的法律文书（管辖权异议、答辩状、起诉状、合同、法律意见等）做质量审核。Maggie/莎莎说"审核""审阅""帮我看看这份文件有没有问题"时按此标准走。六维度检查（内容疏漏、逻辑错误、表达不准确、错别字、格式、段落），发现问题先提示再用修订模式（tracked changes）修改。区别于文书"制作"（litigation-document-preparation）和"咨询答疑"（legal-research-and-advisory）——本skill针对的是审核他人已写好的稿件。

法律文书审核（Legal Document Review）

触发条件

Maggie或团队律师（莎莎、Doro、刘婷等）发来一份已成稿的法律文书，要求"审核/审阅/帮我看看有没有问题"。 不是从头制作（那是 litigation-document-preparation），也不是回答法律问题（那是 legal-research-and-advisory）。

跨session项目连续性（2026-07-11教训）

涉及进行中的法律项目（苏州新东方、万禹案等）时，开新对话第一步必须session_search回顾上次确认的事实和结论（主体性质、经营范围、核心法律定性等），不要从零开始重新检索已确认的事实。被用户问"你不记得了吗"=工作失误。memory中存有各项目关键信息，每次涉及时先读取。

核心要求（Maggie 2026-06-17 定义）

按六个维度逐段审核，发现问题全部提示，并用修订模式修改：

1. 内容疏漏 — 该有的没有：漏字、漏法条、漏要件、请求事项不完整、法律依据悬空（讲了主张却没锚定法条）、论证缺环
2. 逻辑错误 — 主体写反/混淆（申请人↔被申请人、原告↔被告）、前后矛盾、论证跳步、因果不成立、举证责任错配
3. 表达不准确 — 法言法语用词不当、口语化、指代不明、一词多义、与法条原文表述不符
4. 错别字 — 含形近字、同音字、标点错误
5. 格式 — 标题层级、编号连续性、字号/加粗一致性、对齐、缩进、书名号/顿号用法
6. 段落 — 多余空段、段落割裂或杂糅、应分未分/应合未合

工作流程

第0步：定位文件，逐段读透

0a. 动手改之前，先扫一遍"文件里有没有别人的在先修订"——硬性闸门，不可跳（2026-06-24 平和外教补贴通知实测，差点污染他人修订）

任何 tracked 编辑前的第一个动作 = 扫 w:ins/w:del 看作者集合。 不是"读完正文顺手看一眼"，是改之前必须先回答"这份稿子是干净原稿，还是已经有人改过一轮？"——答错就会在别人的修订上叠加冗余/冲突内容，违反"他人修订不动"铁律。

⚠️ python-docx 的 paragraph.text 会骗你：它返回的是接受所有修订后的文本，把已有的 w:ins/w:del 痕迹完全隐藏。用 .text 逐段读出来是干净通顺的散文，看不出文件其实已含他人一轮修订。2026-06-24 教训：我用 python-docx .text 读《外教补贴通知》，看着是干净原稿就直接 tracked_block_replace 加了一条税务赔偿条款；save 后 dump XML 才发现文件早有 bittersweet 的 9 INS + 2 DEL，且 bittersweet 已经把我想补的那个税务穿透责任点处理得更细（按故意/重大过失分梯度），我的修改既冗余又与之冲突。立即删档止损（原文件未污染），改为先向用户报告"文件已有 X 的在先修订"再问要做什么。

正确的开场探针（zipfile+lxml，不靠 python-docx）：

import zipfile
from lxml import etree
W='{http://schemas.openxmlformats.org/wordprocessingml/2006/main}'
with zipfile.ZipFile(SRC) as z:
    dx=etree.fromstring(z.read('word/document.xml'))
ins=dx.findall('.//'+W+'ins'); dele=dx.findall('.//'+W+'del')
authors=set(e.get(W+'author') for e in ins+dele)
print(f"已有修订: INS={len(ins)} DEL={len(dele)} 作者={authors}")
# 非空 → 文件已被改过一轮，逐条 dump INS/DEL 看清别人改了什么，再决定动作

• 作者集合为空 → 干净原稿，正常走六维度审核 + 自己的 tracked 修订。

• 作者集合非空 → 文件已含他人在先修订（可能是客户方先改、或团队另一人改过）。停下来，先做两件事：① 逐条 dump 每个 INS/DEL 的作者和内容，看清别人改了哪些点、接受态是什么样；② 向用户报告"这份文件已有 <作者> 的一轮修订（N处），改了 XXX"，并问清"那位是谁、与本次任务什么关系、要我在其基础上叠加修订还是只评审不动"。在用户回话前不要叠加自己的 tracked 改动——否则容易做出与他人修订重叠/冲突/责任标准不一致的冗余修改。

• 这条与下文"已有他人修订痕迹的，保持原样不动"是同一铁律的前置探测版：那条讲"不动"，这条讲"动手前必须先知道有没有、是谁、改了啥"。

• 文件通常在 ~/.hermes/cache/documents/（企微/邮件收到）或 Nextcloud 对应人目录

• 用 zipfile+lxml 提取 document.xml，逐段打印，同时标注：是否加粗(b)、对齐(jc)、样式(pStyle)、编号(numPr)、缩进(ind)、以及已有的修订痕迹(ins/del)

• 【动手前强制：先盘清文件里已有谁的修订，再决定改哪里——2026-06-24 平和外教住房补贴实证，栽过】 读完文件、做任何 tracked 编辑之前，必须先用 zipfile+lxml 把全文 w:ins/w:del 按 author 分组列一遍：谁改了、改了哪几段、改了什么。没盘清就动手 = 高概率撞车。 本会话没注意文件已有"学校法务(bittersweet)"一整轮修订，直接加了自己的税务责任条款，结果与他已写内容主题重叠、责任标准还不一致，只能撤回重来。盘清后：① 他人修订段保持原样不动（铁律，只做自己的审查）；② 自己的新增只落在无他人修订的段落，或与他人修订不重叠、不冲突的点；③ 想改的点若他人已处理，先评估他的版本够不够、要不要在其"之外"补，而非覆盖；④ 注意他人 ins 句常与原文用逗号"咬合"（如 bittersweet 新增句以逗号结尾紧接原文收尾句）——删原文那半句会切断他的句子，遇此先问用户。盘清命令：遍历 document.xml 的 ins/del，打印 e.get(qn('author')) + 文本。；改之前先跑 0a 的探针确认作者集合

第1步：六维度过一遍，分级输出

把发现的问题分三级，先报告再动手：

• ■ 必改（硬伤）：漏字、主体写反、法条引用错误、错别字——直接改
• ■ 建议改（补强）：法律依据悬空、论证不完整——改，但说明理由
• ■ 提示项（请用户定夺）：尊称用法（贵院vs受诉法院）、书名号顿号、落款日期、风格偏好——不擅改，列出请用户拍板

报告格式：每条写清【第几段】+【问题】+【性质/依据】+【改法】。

第2步：用修订模式修改（绝不裸写XML）

import sys; sys.path.insert(0,'/home/maggie/contract-work')
from contract_docx_lib import ContractEditor
ed = ContractEditor(SRC)
ed._author = '苌莎莎'   # 署名规则见下
edits = [(old, new), ...]
for o,n in edits:
    ed.tracked_replace(o, n)
ed.save(OUT)

• 署名规则：在莎莎的文书上修订署"苌莎莎"；Doro的合同审查历史上用"WB"。按文书归属人的署名习惯，不确定就问。
• tracked_replace 用字符级diff，纯补字=只产生ins，删改=ins+del
• markup 清洁度铁律（2026-06-23 邹家监督申请书实测）：tracked_replace 的字符级 diff 只适合最小改动（单字错别字、补一个字、删一个字）。整词/整句改写，尤其新旧文本共享字符（如称谓 法庭→莲都法院 共享"法"字）会把修订态咬成 莲都法~~庭~~院、未经~~及~~法庭审理 之类半字脏标记——接受所有修订后文本是对的，但 Doro/莎莎用 OnlyOffice 看的是修订态且有格式洁癖，脏 markup = 交付缺陷。规则：整词/整句/大改写一律用整块删插（[del 整段旧][ins 整段新]，绝不让 difflib 咬共享字）；删整段（合并条款删掉一个自动编号列表项）用段落级标删让自动编号重排（四→三）。两个补充方法实现（tracked_block_replace / tracked_delete_paragraph）+ 双视图核验 + 全角括号 + validate 误报 见 references/tracked-changes-clean-markup.md

第3步：三查后交付（铁律，不可省）

1. ed.validate() 返回空列表才算过（查编号连续性、字号一致、加粗规则）
   • 误报豁免：validate 的"不应加粗"规则是按合同正文（不加粗）设计的。诉讼文书的请求项/标题本就加粗，ins 继承原段落加粗与原文一致时，这条报警是误报——核对方法：读原始文档同类段落第一个普通run的加粗状态，若原文该体例本就加粗，则放行（2026-06-23 邹家申请书请求一）。
2. 检查所有 w:ins 的 author 正确、字体无缺失（zipfile+lxml读XML逐个查rPr/rFonts）
3. 渲染PDF：libreoffice --headless --convert-to pdf，用 pdftotext 提取文字层核对：
   • 乱码符号(U+FFFD)数量=0
   • "接受所有修订后"的最终文本包含所有预期改动（PDF含删除线文本，连续匹配会失败，必须读docx的w:ins或重建最终文本来验证）
   • 未引入不该出现的内容（如管辖异议里别主动提"股权所在地"等自曝点）
4. 双视图核验（Doro/莎莎口径，2026-06-23 起强制）：交付物给的是修订态 docx，但要分别验两个视图——
   • 修订态：用 OnlyOffice 容器内 x2t 渲染（Doro/莎莎实际用 OO 看痕迹，LibreOffice 与 OO 不同源），转 PNG 自查 markup 是否干净（无半字脏标记、无文字重叠）
   • 接受态：脚本剥离 del/unwrap ins/删空列表项后渲染，核对自动编号是否正确重排（删条款后一二三连续无断号）、全角括号生效
   • 两套渲染脚本见 references/tracked-changes-clean-markup.md
   • 仿宋全角引号：若用户要求"引号统一为仿宋"——中文弯引号 “ ”（U+201C/U+201D）是中西文模糊字符，所在 run 常 ascii=Times/eastAsia=None，OnlyOffice 按 ascii 渲染成又粗又重的 Times。修法是给含引号 run 显式设 rFonts eastAsia=ascii=仿宋（含数字的 run 要拆，数字保留 Times），改完必须 OO 实渲染确认。完整诊断+脚本见 references/tracked-changes-clean-markup.md

第4步：交付 + 说明

• 文件名遵循 file-naming-convention：当事人+文件名称+版本+修改人+日期，如 …-v4-rev.MJ-20260617.docx
• MEDIA标签发企微；如要求邮件则发对应人并按规则CC
• 附审核报告：改了哪几处（必改/建议分别列）、提示项留给用户定夺的有哪些、以及任何策略性提醒

常见硬伤清单（高频复现，重点查）

• 主体写反：管辖异议/答辩状里"申请人↔被申请人"颠倒——最高频硬伤，必查每一处主谓
• 法条漏字：引法条要与原文逐字核对。如民诉282条是"更为方便的外国法院"，漏"外国"是常见疏漏
• 法律依据悬空：标题/主张讲了某类连接点或要件，正文却没点明法条编号——补锚点
• 称谓不统一：正文客观陈述用"受诉法院"，结尾呼告用"贵院"可并存（提示项，非必改）
• 编号/标题层级：新增条款标题与内容是一个整体，不拆成两个独立编号（Doro 06-12规则）
• 空段落：连续两个以上空段往往是多排的行

法律内容审核铁律（继承自 legal-research-and-advisory）

• 涉及法条的，必须核实原文有效版本，不凭记忆
• 严格区分"法律依据"与"策略判断/行业惯例"，不把后者包装成法律结论
• 法律法规必须是引用时有效的；事实陈述必须有来源；案例引用要案号+法院+日期
• 法律文书总结/归纳必须用法言法语，不口语化改写

文风随落款主体定：律师代书 vs 当事人自署（Doro 2026-06-24 徐函纠正，铁律）

审稿/优化前先看落款主体，再定文风标准——用错标准会被直接退回。

• 律所/律师署名的文书（代理词、法律意见、律师函以律所名义发）→ 客观克制，禁情绪化/辩论腔（适用 legal-research-and-advisory 的"律师客观陈述"三段式规则）。
• 当事人/公司自己署名的函（"严正回应""问责函""情况说明"，落款是公司+法定代表人签字）→ 保留当事人的情绪与严正语气，这是客户在为自己发声，理应有立场、有分量。Doro 原话："保持情绪，因为这是客户发函。"
  • 我曾对一封公司署名的《严正回应》主动提"通篇降温去情绪化"，被 Doro 纠正——客户函不套律师客观陈述标准。
  • 保留：严正、质问、合理的不满（"非同寻常""厚此薄彼""有求必应""公然违背""断难认可"这类有立场的措辞）。
  • 仍须守的底线（即便保留情绪也不能破）：① 事实必须准确有据；② 法条引用精准（条款号、原文）；③ 不做无证据的人身攻击或诽谤性断言（"关系非同寻常"这类影射要么用客观事实坐实、要么收稳，避免将来被对方反诉名誉侵权）；④ 把最有力的弹药（如违反保密义务的实锤）排到重心，情绪服务于说理而非取代说理。
  • 优化客户函的正确动作 = 保情绪 + 补法律依据 + 弹药排序 + 洗格式，不是"降温改写"。

扫描件 PDF 法条提取（web 源只有图片版时，2026-06-24 广东利益冲突规则实战）

地方律协规则、老版行业规范常只有扫描版 PDF（无文本层），web_extract/pdftotext 提不出字。判别：pdffonts X.pdf 无字体行 + pdftotext 输出空/全 \f。提取办法：

pdftoppm -png -r 200 scan.pdf img        # 转图，200dpi 足够 OCR
# 先用关键词定位目标条在哪几页（避免逐页全 OCR）
for f in img-*.png; do
  tesseract "$f" - -l chi_sim 2>/dev/null | tr -d ' \n' \
    | grep -q "目标关键词" && echo "$f 命中"
done
tesseract img-04.png - -l chi_sim        # 对命中页做完整 OCR

• tesseract + chi_sim 语言包对印刷体法条 OCR 质量足够逐字核（条号、款、关键术语都清晰）。
• OCR 出的文本仍要按"法条款项核查铁律"对待：交叉验证、确认版本施行日期。
• 一个 PDF 常含多个规则合订——先 OCR 找标题页定位目标规则范围，再 OCR 目标条款页。

法条核查方法论铁律（Doro 2026-06-23，第五十一条款项事件，两次纠正）

触发：审核稿引用了"第X条第Y款"，或某主张锚定了某法条。 核"款项准确"与"法条是否真支撑该主张"是审核硬指标，错了就是硬伤。

1. 铁证 = 完整法条原文，不是别人的引用。 律所文章、专业解读、法律问答、教材转述——全都是"别人的引用"，不能当铁证。哪怕中伦/最高法知产法庭的解读白纸黑字写"第二款"，也只是旁证；必须找到法条本身的完整原文逐字逐款确认。我曾拿律所解读当铁证下判断，被 Doro 当场点"铁证只能是完整的法律规定"。
2. 搜索摘要/web_extract 常省略法条开头的款——禁止据摘要判断"第几款"。 多个权威网页（最高法公报、sipf、知产法庭）的摘要都把第五十一条第一款"举证期限可以由当事人协商"省略了，直接从第二款"人民法院指定举证期限的…"显示。我据此误判"十五日"在第一款，把 Doro 写对的"第二款"改成了错的"第一款"。摘要省略 ≠ 原文。
3. 必须抓全条原文（含被省略的款）逐款数。 方法：curl 拿原始 HTML，正则切 第X条(.*?)第X+1条，看原文换行/全角缩进（　　另起一款）数款。两个独立一手源交叉验证，款数与字句都一致才算定。脚本见 references/statute-citation-verification.md
4. 版本核对：极易误抓旧版。 同一部规定有多版（如证据规定 2001版 vs 2019修正版，民诉法 2017/2021/2023修正）。抓到后先核施行日期/修正时间——我曾误抓 2001 旧版证据规定（第51条是"质证顺序"）来核现行第51条（举证期限），完全张冠李戴。
5. 引用法规年份必须用施行日期，不用公布日期。 行政法规的"公布日期"和"施行日期"常不同年（如国务院令第584号2010年11月公布、2011年3月施行）。对外引用时以施行日期为准，说"2011年施行的《XX条例》"，不说"2010年的条例"——用公布日期会被客户/律师质疑"没有这个版本"。同理，修订版以修订施行日期标注。
6. 法条错配也是硬伤：引的条文必须真能支撑该主张。 不只查"款项对不对"，还要查"这条说的是不是这个事"。Doro 用民诉法第137条（"公开审理原则"）去支撑"开庭→举证→质证的程序顺序"——137条讲的是公开审理，跟程序顺序无关，是错配。审核时对每个法条锚点都要回原文确认"条文内容 = 主张所需依据"，不符就是"法律依据错配"，列必改。

关联skill

• contract-editor / contract-reviewer：合同专项审查（reviewer+editor分角色）
• litigation-document-preparation：文书制作（非审核）
• legal-research-and-advisory：法律问题咨询（非文书审核）
• file-naming-convention：交付命名规则

references/

• references/tracked-changes-clean-markup.md — 修订态 markup 清洁度、双视图核验脚本、仿宋全角引号修法、全局字体规范化（中文仿宋/英数 Times，含 OnlyOffice 容器无真仿宋→验属性不验字形的坑）、validate 加粗误报豁免
• references/statute-citation-verification.md — 法条引用一手原文逐款核查 recipe（curl 绕摘要）、已核样本库（民诉法/证据规定/宪法/监督规则现行条文）、检察监督概率评估口径
• references/legal-opinion-review-checklist.md — 法律意见书专项审查要点：定性力度与法律后果匹配（"不建议"vs"不得"）、前后逻辑自洽、法条引用闭环（定义→禁止→后果）、主体信息准确性、实操建议可行性核查

结构性改动技巧（段落重排，2026-06-23 邹家 违法点重排）

用户要求调整章节/条款顺序（如"把违法点C挪到压轴"）时：

• 段落重排用接受态物理移动（lxml 在 body 里 remove + insert 整组段落，含标题+正文段），不要用 tracked-move——OOXML 的移动修订在 OnlyOffice 里渲染成大段删除+大段插入，比脏 markup 更难看。
• 自动编号（numPr/numId）的列表项移动后自动重排，无需手动改编号；移完渲染接受态核对 (一)(二)(三)… 连续无断号。
• 移动与文字层 tracked 改动可叠加：先做文字 tracked_replace/block_replace（留痕给用户看），再做段落物理移动（结构调整），交付时明确告诉用户哪些是修订痕迹、哪些是结构重排（重排不在 markup 里显示）。
• 定位段落用接受态文本前缀匹配（acc(p).startswith(...)），避免误匹配。