feat: export core Hermes skills
This commit is contained in:
@@ -0,0 +1,160 @@
|
||||
---
|
||||
name: legal-document-review
|
||||
description: 法律文书审核——对已成稿的法律文书（管辖权异议、答辩状、起诉状、合同、法律意见等）做质量审核。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）：**
|
||||
```python
|
||||
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）
|
||||
```python
|
||||
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`。提取办法：
|
||||
```bash
|
||||
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(...)`），避免误匹配。
|
||||
Reference in New Issue
Block a user