菜单
诉讼信息中枢系统。接收法院短信、送达链接、纸质文书照片，自动 OCR 识别、下载、归档、归类到标准案卷目录。基于 12 种期限规则库自动匹配，通过系统日历 + QQ 邮件（微信送达）+ 本机电脑提醒（系统通知 + 桌面 Markdown 文件）三条线提醒，支持 macOS / Windows / Linux 全平台。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/CSlawyer1985/legal-skillhub --skill litigation-hub命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | litigation-hub |
| homepage | https://github.com/leahlu0124-creator/litigation-hub |
| author | 陆凌燕 |
| original_author | 杨卫薪律师 |
| version | 2.2.2 |
| license | MIT |
| description | 诉讼信息中枢系统。接收法院短信、送达链接、纸质文书照片，自动 OCR 识别、下载、归档、归类到标准案卷目录。基于 12 种期限规则库自动匹配，通过系统日历 + QQ 邮件（微信送达）+ 本机电脑提醒（系统通知 + 桌面 Markdown 文件）三条线提醒，支持 macOS / Windows / Linux 全平台。 |
| slug | litigation-hub |
| displayName | litigation-hub |
处理法院文书的完整流程：粘贴短信 / 发链接 / 上传照片 → 解析内容（OCR 或文本）→ 匹配案件 → 下载/归档文书 → 开庭日历提醒（传票自动写入系统日历 + 本机电脑提醒 + QQ 邮件（微信送达））。
当用户第一次使用本技能时，必须先确认案卷存放目录。
⚠️ 如果没有事先确认目录，后续搜遍整台电脑都找不到案卷，效率极低。这一步一劳永逸。
检查是否已有缓存的案卷目录记录：
config/case-root.json，检查 case_root 字段是否为有效路径case_root 为空 → 首次使用，执行下方交互流程case_root 已配置且路径存在 → 跳过，直接进入正式工作流询问格式：
您好！我是诉讼中枢系统。在开始处理法院文书之前，我需要确认一件事：
您平时把案卷资料存在哪个文件夹？
常见的例子供参考：
· macOS → /Users/你的名字/项目/律师业务/案件/
· Windows → C:\Users\你的名字\Documents\律师业务\案件\
· Linux → /home/你的名字/项目/律师业务/案件/
💡 最简单的方式：打开你的案卷文件夹，把地址栏里的路径直接复制粘贴给我就行。
· macOS：在访达里选中文件夹 → 按 ⌘+⌥+C (Cmd+Option+C) → 路径就复制好了，直接粘贴过来
（或者：访达菜单 → 显示 → 显示路径栏，然后在底部路径栏上右键 → 拷贝路径）
· Windows：在资源管理器打开文件夹 → 点一下顶部地址栏 → 按住 Shift 右键空白处 → 选"复制为路径"（或直接 Ctrl+Shift+C）
（如果不行，就点地址栏后 Ctrl+C 复制）
请把路径发给我：
用户回复后：
ls / dir），如果不存在，创建之config/case-root.json：
{"case_root": "/Users/xxx/项目/02-律师业务", "configured_at": "YYYY-MM-DD HH:MM"}
✅ 已记录案卷目录：/Users/xxx/项目/02-律师业务
以后所有法院文书都会在这个目录下匹配和归档。
config/case-root.json 读取路径，仅在该目录下搜索已有案卷；case_root 无关。桌面上的新案卷用户一眼就能看到，整理后自行移入搜索目录即可。支持三种触发方式：
方式一：粘贴短信原文
收到法院短信，内容如下：
【xx市人民法院】张三，您好！您有（2025）苏0981民初1234号案件文书送达，请点击链接查收：https://zxfw.court.gov.cn/zxfw/#/pagesAjkj/app/wssd/index?qdbh=DEMO1&sdbh=DEMO2&sdsin=DEMO3
用户可能直接粘贴送达链接（非完整短信文本），此时跳过短信文本解析，直接从 URL 中提取 qdbh、sdbh、sdsin 参数，进入第三步下载流程。
https://zxfw.court.gov.cn/zxfw/#/pagesAjkj/app/wssd/index?qdbh=xxx&sdbh=xxx&sdsin=xxx
方式三：上传纸质文书照片 / 扫描件
适用于刑事律师收到纸质传票、判决书、通知书的场景。上传照片（PNG/JPG），MinerU OCR 字符级精度提取文字，再解析为结构化字段。
上传：传票照片.jpg
→ MinerU OCR（flash-extract）→ 解析 → 复核 → 归档 + 日历提醒
依赖
mineru-open-api（npm install -g mineru-open-api），首次使用自动安装，用户无感知。
| 类型 | 特征 | 含下载链接 | 处理方式 |
|---|---|---|---|
| 文书送达 | 含送达平台链接 + 案号 | 是 | 下载文书并归档到案件目录 |
| 立案通知 | 含"已立案"等关键词 | 可能有 | 展示解析结果 |
| 信息通知 | 无链接，纯信息 | 否 | 展示解析结果 |
支持的送达平台：zxfw.court.gov.cn（全国）、sd.gdems.com（广东）、jysd.10102368.com（集约送达）、dzsd.hbfy.gov.cn（湖北）、sfpt.cdfy12368.gov.cn（司法送达网）。同一平台可能使用不同域名（同构异域名），通过 URL 路径特征识别平台。详见 references/sms-patterns.json。
references/sms-patterns.json 作为解析参考【xx法院】）+ 正文 + 链接 → 完整解析流程https://zxfw.court.gov.cn/...?qdbh=xxx&sdbh=xxx&sdsin=xxx）→ 跳过短信文本解析，直接从 URL 提取参数，进入第三步下载。案号、当事人等信息在下载文书后从文书内容中提取。a) 短信分类：根据关键词判断类型
b) 案号提取：使用正则 [（(〔[]\d{4}[）)〕]] 匹配标准案号格式
标准案号格式示例：
（2025）苏0981民初1234号(2024)粤0604执保5678号〔2025〕京0105民初901号c) 当事人提取：从短信文本初步识别，最终以文书内容为准
xx有限责任公司、xx有限公司、xx股份有限公司A与B、A诉B、原告A 被告B原告：xxx、被告：xxx 等d) 下载链接提取：识别短信中的送达平台链接并提取参数
| 平台 | 域名 | 下载方式 | 提取参数 |
|---|---|---|---|
| 全国法院统一送达平台 | zxfw.court.gov.cn | curl API 直连 | qdbh, sdbh, sdsin |
| 广东法院电子送达 | sd.gdems.com | 浏览器自动化 | 路径中的送达标识码 |
| 集约送达平台 | jysd.10102368.com | 浏览器自动化 | key |
| 湖北电子送达 | dzsd.hbfy.gov.cn | HTTP API（免账号）/ 浏览器自动化（账号模式） | 免账号：msg；账号模式：账号+密码从正文提取 |
| 司法送达网 | sfpt.cdfy12368.gov.cn | 纯 Playwright（无 API） | 验证码（手机尾号后6位 / 短信验证码） |
e) 发送时间提取（P0）：从送达平台 API 响应中提取发送时间，用于后续上诉期限计算
dt_cjsj 字段（送达记录创建时间，ISO 8601 格式）发送：YYYY-MM-DD HH:mm 格式document.sent_at 字段排除列表：法院名称、法官姓名、地名、法律术语等不应作为当事人提取。详见
sms-patterns.json→party_extraction.exclude_keywords。
输出格式（向用户展示）：
📋 短信解析结果：
- 类型：文书送达
- 案号：（2025）苏0981民初1234号
- 当事人：张三、xx有限公司
- 下载链接：已提取（zxfw.court.gov.cn）
当用户上传的是纸质文书照片（传票、判决书、通知书等），而非短信或链接时：
MinerU OCR：scripts/court_photo_ocr.py 调用 mineru-open-api flash-extract 提取文字
python3 scripts/court_photo_ocr.py /path/to/传票照片.jpg
MinerU 基于 PaddleOCR，字符级精度。首次运行自动安装
npm install -g mineru-open-api，用户无感知。
结构化解析：提取的文字经正则匹配得到案号、案由、当事人、开庭时间/地点等，附带置信度标记
后续流程：识别到传票/出庭通知 → 跳过下载步骤 → 归档 + 日历提醒；识别到判决书 → 计算上诉期限
自动归纳：OCR 完成后按优先级匹配已有案卷，但「归入已有案卷」必须经过律师确认，绝不自动写入：
(2025)苏0411民初6206号）何玉-诉讼材料）{原告}诉{被告} {案由}/（新建不污染既有案卷，故不询问），内含 10 个标准子目录--to-folder <路径> 重新运行脚本完成归档。标准案卷目录结构（新建案卷时用这些固定名称，不得自行编造）：
{原告}诉{被告} {案由}/
├── 01 法院送达文书/ ← 传票、判决书、裁定书、通知书等所有法院来源材料
├── 02 我方提交资料/ ← 我方向法院递交的材料
├── 03 对方提交资料/ ← 对方通过法院送达的材料
├── 04 案件原始材料/ ← 从当事人收到的原始材料
├── 05 律师工作文本/ ← 法律意见、庭审提纲等
├── 06 委托签署材料/ ← 委托合同、授权书等
├── 07 邮件收寄记录/ ← 邮件往来记录
├── 08 法规类案检索/ ← 法律法规、类案报告
├── 09 法院庭审笔录/ ← 庭审、听证笔录
└── 10 案件保全资料/ ← 财产、证据保全文书
01 法院送达文书/ 对应子目录（新建案卷时自动归入；匹配到已有案卷时，需律师确认后归入）输出格式（向用户展示）：
📷 照片识别结果：
- 类型：传票
- 案号：（2025）沪01刑初1234号
- 当事人：被告人张三
- 开庭时间：2026-05-07 09:30
- 地点：上海市第一中级人民法院 第5法庭
如 OCR 结果不完整（手写批注、模糊、遮挡），提示用户手动补充关键字段。
01*、法院送达、court 等）{原告}诉{被告} {案由}/（新建不污染既有案卷，故不询问用户），随后直接归档--to-folder <路径> 重新运行脚本完成归档⛔ 每个案件第一次处理时必须确认代理方，否则后续无法区分「我方提交资料」和「对方提交资料」。
当新建案卷或首次匹配到已有案卷时：
读取 config/case-parties.json，检查该案号是否已记录代理方：
向用户提问（从解析结果中提取已知当事人）：
⚖️ 案件 (2025)苏0981民初1234号，原告：张三，被告：xx有限公司。
请问您是代理哪一方？
→ 原告 张三（我方）
→ 被告 xx有限公司（我方）
→ 暂时不确定
记录答案：写入 config/case-parties.json：
{
"cases": {
"（2025）苏0981民初1234号": {
"represented_party": "原告",
"party_name": "张三",
"configured_at": "2026-07-13"
}
}
}
影响后续分类：
平台判断：根据第一步识别的链接域名，选择下载策略。
zxfw.court.gov.cn→ 方案一（API 直连）→ 方案二 → 方案三sd.gdems.com或jysd.10102368.com→ 跳过方案一，直接方案二 → 方案三dzsd.hbfy.gov.cn→ 湖北专属流程（见下方）sfpt.cdfy12368.gov.cn（含广西实例171.106.48.55:28083）→ SFDW 专属流程（见下方）- 未知域名但 URL 路径匹配已知平台特征 → 按路径识别平台（同构异域名支持）
- 完全无法识别 → 提示用户提供链接信息
⛔ 降级铁律：严格串行，禁止并行。当前方案成功即停止，绝不降级。禁止"双保险"并行尝试多个方案。
| 依赖 | 用途 | 适用方案 | 安装方式 |
|---|---|---|---|
curl | API 下载 | 方案一 | macOS/Linux 预装 |
jq | JSON 解析（可选） | 方案一 | brew install jq |
| Playwright | 浏览器自动化 | 方案二/三 | 见下方 |
Playwright 安装指引（仅方案二/三需要）：
# 方案二: Playwright CLI
npm install -g playwright
npx playwright install chromium
# 方案三: Playwright MCP（需在 WorkBuddy 设置中配置）
# 在 settings.json 的 mcpServers 中添加：
# "playwright": { "command": "npx", "args": ["@anthropic-ai/mcp-playwright"] }
⛔ 大多数情况下不需要 Playwright：zxfw 平台方案一直接 curl 调用 API，无需浏览器。仅 gdems/jysd 平台或方案一失败后才需要方案二/三。禁止在方案一执行期间同时打开浏览器。
完全无头，无需浏览器。直接调用 zxfw 后端 API 获取文书下载链接，再用 curl 下载 PDF。
API 信息：
POST https://zxfw.court.gov.cn/yzw/yzw-zxfw-sdfw/api/v1/sdfw/getWsListBySdbhNewapplication/json{ "qdbh": "xxx", "sdbh": "xxx", "sdsin": "xxx" }（从短信 URL 提取）data[].c_wsmc（文书名称）、data[].wjlj（OSS 签名下载链接）、data[].c_fymc（法院名称）# 1. 从短信 URL 提取参数（示例）
qdbh="DEMO_qdbh_value"
sdbh="DEMO_sdbh_value"
sdsin="DEMO_sdsin_value"
# 2. 调用 API 获取文书列表
mkdir -p /tmp/court-sms-staging/
resp=$(curl -s -X POST "https://zxfw.court.gov.cn/yzw/yzw-zxfw-sdfw/api/v1/sdfw/getWsListBySdbhNew" \
-H "Content-Type: application/json" \
-d "{\"qdbh\":\"$qdbh\",\"sdbh\":\"$sdbh\",\"sdsin\":\"$sdsin\"}")
# 3. 解析文书列表，逐个下载 PDF
echo "$resp" | jq -r '.data[] | "\(.c_wsmc)\t\(.wjlj)"' | while IFS=$'\t' read -r name url; do
curl -sL -o "/tmp/court-sms-staging/${name}.pdf" "$url"
done
# 4. 验证下载结果
ls -lh /tmp/court-sms-staging/*.pdf
当方案一 API 不可用或链接过期时，用 Playwright CLI 无头模式打开页面，拦截网络请求获取下载链接。
# 需要先安装 playwright
npx playwright install chromium 2>/dev/null
# 无头模式运行（脚本需自行编写，拦截 getWsListBySdbhNew API 响应）
node scripts/download_court_docs.mjs --url "{短信链接}" --output /tmp/court-sms-staging/
当方案二不可用时（需要已配置 Playwright MCP）：
1. browser_navigate → 打开短信中的 zxfw URL
2. 等待页面加载
3. browser_evaluate → 直接调用 fetch API 获取文书列表
4. browser_run_code → 下载 PDF 文件到 /tmp/court-sms-staging/
如 API 调用未成功，改用页面交互：
1. browser_snapshot → 查看当前页面结构
2. 找到文书列表或 PDF 预览区域
3. 定位下载按钮（可能在 iframe 内）
4. browser_click → 点击下载
5. 等待下载完成，保存到临时目录
dzsd.hbfy.gov.cn）湖北电子送达平台有两种链路，根据 URL 格式自动选择：
链路一：免账号模式（URL 含 /hb/msg=xxx）
msg 参数值msg="从URL提取的msg值"
mkdir -p /tmp/court-sms-staging/
# 查询文书信息
resp=$(curl -s -X POST "http://dzsd.hbfy.gov.cn/delimobile/tDeliSms/findSmsInfo?t=$(date +%s%3N)" \
-H "Content-Type: application/json" \
-H "Referer: http://dzsd.hbfy.gov.cn/deli-mobile-ui/" \
-d "{\"msg\":\"$msg\"}")
# 检查是否需要验证码（data.isNeedCaptcha == "Y"）
# 如需验证码或无可下载文书，降级到 Playwright MCP
# 逐个下载文书
echo "$resp" | jq -r '.data.docList[] | "\(.docName)\t\(.downloadPath)"' | while IFS=$'\t' read -r name path; do
if [ -n "$path" ]; then
curl -sL -o "/tmp/court-sms-staging/${name}.pdf" "http://dzsd.hbfy.gov.cn/delimobile${path}"
fi
done
链路二：账号模式（URL 含 /sfsddz）
账号\s*(\d{15,20})默认密码[：:]\s*([0-9A-Za-z]+)提示：湖北平台两种模式都可能遇到验证码。免账号模式优先尝试 HTTP API，账号模式建议引导用户手动打开链接或使用 Playwright MCP。
sfpt.cdfy12368.gov.cn）司法送达网所有 POST 请求使用 TDHCryptoUtil 加密，无法通过 HTTP API 下载，只能使用纯 Playwright 流程。
广西实例：171.106.48.55:28083 域名下的链接路由到同一 SFDW 平台，下载流程相同。
验证码获取（两种方式，按优先级尝试）：
验证码[：:]\s*(\w{4,6})Playwright MCP 流程：
1. browser_navigate → 打开短信中的 SFDW 链接
2. 等待页面自动重定向到 pc.html?tdhParams=xxx
3. browser_snapshot → 查看验证码输入页面（input#checkCode）
4. 输入验证码（优先手机尾号后6位，其次短信验证码）
5. browser_evaluate → 调用 Vue app.checkYzm() 触发验证
6. 验证通过后 browser_evaluate → 获取 app.$data.wsList（文书列表）
7. 遍历 wsList，逐个调用 downloadFile(app, ws) 下载文书
8. 保存到 /tmp/court-sms-staging/
提示：如手机尾号验证失败，提示用户查看短信中的验证码并手动输入。wsList 每项包含 wjmc（文件名）、wjgs（格式）。
当三级均失败时：
⚠️ 自动下载失败，请手动访问以下链接下载：
{原始链接}
下载后请将文件放到对应案件目录中。
我将为您创建待处理记录。
⚠️ 归档铁律：匹配到已有案卷必须经律师确认，绝不静默写入。 同名同姓在中国极为普遍，错误归档会污染他人案卷，因此「找到即归档」是禁止行为。
{原告}诉{被告} {案由}/（安全，不询问），随后归档--to-folder <路径> 重新运行脚本，再归档到该目录date "+%Y%m%d"sms-patterns.json 中的 document_titles 映射推断未知文书{title}（{case_name}）_{YYYYMMDD}收.pdf
受理通知书（张三与李四合同纠纷）_20260404收.pdf< > : " | ? * \ /_2 后缀⛔ 所有法院送达材料一律用日期子文件夹打包，不得直接散放在
01 法院送达文书/根目录。 法院可能对同一案件分批发送不同文书，散放会导致批次混乱、无法区分送达时间。
哪怕是只有一份传票，也放进子文件夹里。
文件夹命名规则：{命名文书}_{送达日期}送达/
送达日期 取 API 响应中 dt_cjsj 的日期部分（如 20260119），或文书落款日期命名文书 从本次送达的所有文书中选优先级最高的作为文件夹名命名优先级（所有文书地位并列，以下仅用于选文件夹名）：
| 优先级 | 适用场景 | 文件夹名示例 |
|---|---|---|
| 1 | 含判决书 | 一审法院判决书_20260318送达/ |
| 2 | 含裁定书（不含判决书） | 一审法院裁定书_20260401送达/ |
| 3 | 含传票（不含判决/裁定） | 传票_20260601送达/ |
| 4 | 含受理案件通知书（不含以上） | 受理案件通知书_20260119送达/ |
| 5 | 其他（举证通知、应诉通知等） | 举证通知书_20260520送达/ |
简单理解：一堆文书里谁最"重"就用谁命名。传票比通知书"重"，判决书比传票"重"——仅此而已，跟文书本身的法律效力无关。 |
文件夹内文件保持 API 返回的原始文件名，不重命名、不合并。
归档路径示例：
海筑建设诉淮安瑞悦/01 法院送达文书/受理案件通知书_20260119送达/
├── 受理案件通知书.pdf
├── 交纳诉讼费用通知书.pdf
├── 民事诉讼权利义务告知书.pdf
└── ...
孙东诉武进建工/01 法院送达文书/传票_20260601送达/
└── 传票.pdf
移入目标目录：将子文件夹整体移入 01 法院送达文书/
写入内部记录：保存本次处理的完整信息到本技能目录下的 archive/（即 ~/.workbuddy/skills/litigation-hub/archive/）。格式详见 references/archive-format.md
自动归纳到桌面案卷（短信/链接方式同样适用）：
{原告}诉{被告} {案由}/（如 张荷玉诉耿平 被继承人债务清偿纠纷/），再放入--to-folder <路径> 重新运行脚本放入一审法院判决书/ 子目录）基础文书解析：法院 PDF 通常带文字层，提取首页文本，快速识别文书类型和关键信息
深度分析（如判决书解读、合同审查）不在此技能范围内，请使用专用分析技能处理。
期限规则匹配（P0）：当识别到任何有期限要求的文书时，自动查表 references/deadline-rules.json 匹配对应规则
规则库覆盖 12 种文书类型，包括：
| 分类 | 文书类型 | 期限 | 提醒策略 |
|---|---|---|---|
| 📄 上诉 | 民事/行政判决书 | 15日 | 2天前 + 截止当天 |
| 📄 上诉 | 刑事判决书 | 10日 | 2天前 + 截止当天 |
| 📑 上诉 | 民事/行政裁定书 | 10日 | 2天前 + 截止当天 |
| 📑 上诉 | 刑事裁定书 | 5日 | 2天前 + 截止当天 |
| ❄️ 保全 | 冻结银行存款裁定 | 1年 | ⚠️ 提前30天 + 14天 + 7天 + 到期当天 | | 🏠 保全 | 查封不动产裁定 | 3年 | ⚠️ 提前30天 + 14天 + 7天 + 到期当天 | | 📝 举证 | 举证通知书 | ≥15日 | 5天前 + 1天前 | | 📬 答辩 | 起诉状副本 | 15日 | 3天前 + 截止当天 | | ⚡ 执行 | 生效法律文书 | 2年 | 30天前 + 7天前 | | 🔄 再审 | 生效判决/裁定 | 6个月 | 30天前 + 7天前 | | 🏛️ 管辖 | 管辖权异议裁定 | 10日 | 2天前 + 截止当天 | | 📋 缴费 | 受理通知书 | 7日 | 3天前 + 1天前 |
保全类必须提前处理：冻结/查封的续期申请不能等到最后一两天，规则库已按 30天 提前提醒。 新增文书类型只需在
deadline-rules.json的rules数组中追加一条 JSON 条目，无需改代码。
匹配逻辑：根据文书类型 + 关键字标签（如"冻结""银行存款"）精确匹配规则
提醒生成：调用 scripts/court_deadline_reminder.py 统一设置 日历 + 本机电脑提醒（系统通知 + 桌面 Markdown 文件）+ QQ 邮件（微信送达）
⚠️ 提醒确认（P0 — 必须执行）：在创建任何提醒之前，必须先展示提醒计划并等待用户确认
📋 即将创建以下提醒：
案号: (2025)苏0411民初6206号
规则: 民事判决书 → 15日上诉期
· 2026-07-13 09:00 — 上诉期限还剩2天 (日历+通知+邮件)
· 2026-07-15 09:00 — 上诉期限今天截止 (日历+通知+邮件)
👉 回复「确认」创建提醒，或指出需要修改的项。
自动提醒设置：识别到判决书/裁定书后，自动为上诉截止日期设置三重提醒：
python3 scripts/court_deadline_reminder.py setup '<案号>' '<案由>' '<文书类型>' '<标签>' '<送达日期>' '<法院>'references/deadline-rules.json（覆盖 12 种文书类型，新增类型只需加 JSON 条目）🔴 保全裁定强制处理（P0 — 不可跳过）：当文书类型为「裁定书」且内容包含保全关键字（冻结、查封、扣押）时，无论其他因素如何（如开庭日期已过、案件状态待定等），都必须执行以下完整流程：
提取保全详情：从裁定书正文中提取以下字段，逐项展示给用户确认：
计算到期日：
| 保全方式 | 期限 | 依据 |
|---|---|---|
| 冻结银行存款 | 1年（365日） | 《民事保全须知》第3条 |
| 查封、扣押动产 | 2年（730日） | 《民事保全须知》第3条 |
| 查封不动产、冻结其他财产权 | 3年（1095日） | 《民事保全须知》第3条 |
创建全部提醒（逐条核对，不得遗漏）：根据 deadline-rules.json 中匹配到的规则，逐条创建所有 reminders 数组中的提醒。以 preservation_freeze（冻结银行存款）为例：
reminders: [
提前30天 (critical) → 日历 + 通知 + 邮件
提前14天 (warning) → 日历 + 通知 + 邮件
提前7天 (warning) → 日历 + 通知 + 邮件
]
reminders，就必须全部创建。不允许只创建30天和到期日、漏掉14天和7天。汇总确认：创建完成后展示完整提醒时间线，让用户一目了然：
📋 (2026)苏0281民初9011号 保全提醒时间线：
裁定日期：2026-05-27 → 到期日：2027-05-26（1年）
· 2027-04-26 — ⛔ 提前30天：请立即申请续冻！
· 2027-05-12 — ⚠️ 提前14天：冻结将在14天后到期
· 2027-05-19 — ⚠️ 提前7天：冻结将在7天后到期
· 2027-05-26 — 🔴 保全到期日
references/report-format.md 输出结构化报告归档确认（P0 — 必须执行）：向用户展示归档结果，等待确认后才能进入提醒步骤
文件 → {案卷路径}/{子目录}/文件名❄️ 重复文件检测：归档前检查目标目录是否已有同名或大小相似的文件
📋 未处理文件追踪：OCR 失败或无法归类的文件，记入 references/pending-items.json 待处理清单
📂 非法院文书智能归类：对非法院发布的文件（代理词、委托书、合同、证据等），根据文件名和内容关键词自动归类到对应子目录
02 我方提交资料: 起诉状、答辩状、代理词、证据清单（仅当文件涉及代理方时才归入此目录）03 对方提交资料: 对方起诉状、对方答辩状、对方代理词（仅当文件涉及对方当事人时才归入此目录）04 案件原始材料: 合同、协议、借条、银行流水06 委托签署材料: 委托代理合同、授权委托书scripts/court_utils.py → FILE_CATEGORY_MAPconfig/case-parties.json，已知代理方时，涉及代理方的诉讼文书（起诉状、答辩状、代理词等）优先归入 02 我方提交资料，涉及对方当事人的归入 03 对方提交资料。未确认代理方时，不确定归属的文书先暂存桌面，待确认后再归类。📅 法定节假日感知：期限截止日如落在周末或法定假期，自动顺延至最近工作日
references/china-holidays.json（来自国务院办公厅通知）触发条件：第四步 PDF 解析识别出传票 / 出庭通知 / 应诉通知书时自动执行。 自动判断：无需用户操作，下载 PDF 后自动扫描文书标题，符合条件即触发。 重复安全：写入前自动删除同一案号的旧事件和邮件提醒，不会重复创建。
下载 PDF 并解析出开庭信息后，自动完成三项工作（根据系统平台自动选择实现）：
本机电脑提醒由两部分组成，确保律师一定能看到开庭提示：
开庭提醒_YYYY-MM-DD_HHMM.md，写明开庭日期 / 时间 / 案由 / 案号 / 地点及需准备材料清单（传票、证据原件、委托手续等）。即使系统通知被勿扰屏蔽或一时没注意，回到桌面也能看到——这是本机提醒的持久化兜底，不依赖系统通知是否真的弹出。| 平台 | 日历 | 定时提醒 | 本机电脑提醒 |
|---|---|---|---|
| macOS | Apple Calendar (AppleScript) | launchd plist | 系统通知 + 桌面 Markdown 文件 |
| Windows | Outlook COM → 失败则 .ics 文件兜底 | schtasks | MessageBox 弹窗 + 桌面 Markdown 文件 |
| Linux | .ics 日历文件（双击导入） | ❌ | 桌面 Markdown 文件 |
📅 日历事件已创建：
- 摘要：⚖️ 开庭：{案由}
- 时间：YYYY年MM月DD日 HH:MM — HH:MM+2h
- 地点：{开庭地点}
- PDF链接：已关联（点开事件可查看文书）
- 日历分组：工作
- 系统提醒：提前1天通知
📄 桌面提醒文件已生成：/Users/你/Desktop/开庭提醒_YYYY-MM-DD_HHMM.md
📧 QQ 邮件（微信送达）提醒已设置（提前1天发送）
#### 依赖
| 依赖 | 用途 | 安装 |
|------|------|------|
| `pypdf` | PDF 文本提取 | `pip install pypdf` |
| macOS: `osascript` / `launchctl` | 日历 + 系统通知 | 系统预装 |
| Windows: `PowerShell` / `schtasks` | Outlook 日历 + 弹窗通知 | 系统预装 |
| `mineru-open-api` | 纸质文书照片 OCR（方式三） | 自动安装 `npm install -g mineru-open-api` |
| `node` | 通过 smtp.js 发送 QQ 邮件（微信送达） | 系统已装 |
| `imap-smtp-email` skill | QQ 邮箱 SMTP 配置 | 已安装 |
#### 操作步骤
**① 从 PDF 中提取开庭信息**
使用脚本 `scripts/court_calendar.py` 的 `parse` 模式：
```bash
# 提取开庭信息（案号、案由、开庭时间、地点）
python3 scripts/court_calendar.py parse /tmp/court-sms-staging/传票.pdf
正则匹配规则：
| 字段 | 正则 | 示例 |
|---|---|---|
| 案号 | （(\d{4})[^）]*\d+号 | （2025）苏0981民初1234号 |
| 案由 | 案 ?由[：:]\s*(.+) | 民间借贷纠纷 |
| 开庭时间 | 应到时间[：:]\s*YYYY年M月D日...HH:MM 或通用日期时间 | 2026年05月07日 09:30 |
| 地点 | 应到处所[：:]\s*(.+) 或 开庭地点[：:]\s*(.+) | xx市人民法院 第3法庭 |
② 判断是否需要创建日历
判定规则：文书标题或类型含以下任一关键词即触发：
③ 删除旧事件（去重）
同一案号可能多次收到文书更新，写入前自动删除该案号的旧日历事件：
python3 scripts/court_calendar.py '<案号>' '<案由>' '<YYYY-MM-DD HH:MM>' '<地点>'
脚本内部自动调用 delete_court_events() 去重。
④ 创建日历事件 + 系统提醒 + QQ 邮件（微信送达）提醒
python3 scripts/court_calendar.py '<案号>' '<案由>' '<YYYY-MM-DD HH:MM>' '<地点>' \
'工作' '<PDF远程链接（如有）>'
这步同时完成：
开庭前1天在同一时刻自动发送，内容示例：
━━━━━━━━━━━━━━━━━━
⚖️ 开庭提醒
━━━━━━━━━━━━━━━━━━
案号：（2025）苏0981民初1234号
案由：民间借贷纠纷
时间：2026年5月7日 09:30（周四）
地点：xx市人民法院 第3法庭
━━━━━━━━━━━━━━━━━━
此邮件由 court-sms 自动发送，请以传票原件为准。
| 字段 | 内容 |
|---|---|
| summary | ⚖️ 开庭：{案由} |
| description | 案号 - 案由 - 开庭地点（纯文本，不含链接） |
| url | PDF 远程访问链接（如无则不传） |
| location | 开庭地点 |
| start | 开庭时间（2小时时长） |
| calendar | 工作 |
如果已有同案号日历事件（如之前手动创建或系统自动创建），脚本的 delete_court_events() 会先清理再重建，保证不重复。
| 状况 | 处理 |
|---|---|
| pypdf 未安装 | 提示安装，跳过日历创建 |
| PDF 无法解析（扫描件） | 跳过自动提取，展示"请手动查看 PDF 确认开庭时间" |
| 提取到案号但无开庭时间 | 只创建事件（摘要以案号命名），不设提醒时间，不发送 QQ 邮件（微信送达） |
| AppleScript 失败 | 展示错误信息，不阻塞后续流程 |
| launchd 加载失败 | 仅提示，日历事件已完成创建 |
| launchd 邮件提醒加载失败 | 仍完成日历创建，展示警告并提示检查 launchd 日志 |
| QQ 邮件（微信送达）发送失败 | 不影响日历和系统通知，检查 ~/.court-email/*-err.log |
日历创建成功后，在文书归档汇报末尾追加：
📅 开庭日历提醒：
- ⚖️ 开庭：{案由}
- 🕙 {开庭时间}
- 📍 {开庭地点}
- 🖥️ 本机电脑提醒：系统通知 + 桌面《开庭提醒_*.md》（含需准备材料清单）
- 📧 已设置提前1天 QQ 邮件（微信送达）通知（YOUR_QQ_EMAIL@qq.com）
不默认启用。仅在检测到文件拆分时主动提示用户。
归档完成后，扫描目标目录中的 PDF 文件，检测是否有同一文书被拆分为多个文件的情况。
读取 config/user-preferences.json 获取用户的合并和重命名偏好。如文件不存在，使用默认值（参考 config/user-preferences.example.json）。
关键偏好项：
| 偏好 | 默认值 | 说明 |
|---|---|---|
merge_strategy | per_evidence | 合并策略：per_evidence（按编号分别合并）或 unified（统一合并） |
merge_options.unified.bookmarks.enabled | true | 统一合并时是否添加 PDF 书签 |
rename.enabled | true | 是否精简文件名 |
读取 references/sms-patterns.json → post_processing.trigger 配置，按以下规则分组：
分组规则：
1. 证据类：文件名以"证据"开头 → 按编号分组（证据1、证据2、证据3…）
2. 其他文书：按文书类型分组（传票、起诉状、应诉通知书…）
3. 如任一组内文件数 > 3（threshold），触发提示
示例：证据3 下有 10 个 PDF → 触发。
使用 AskUserQuestion 提示用户，列出检测到的拆分情况：
检测到以下文书被拆分为多个 PDF：
- 证据3：10 个文件
- 证据5：4 个文件
是否执行 PDF 后处理（合并 + 重命名）？
→ 是，合并所有
→ 让我选择（逐个确认）
→ 跳过
用户确认后，根据 user-preferences.json 中的 merge_strategy 执行：
策略一：per_evidence（默认）
按单个证据编号分别合并，每个证据独立保留：
- 证据3 有 10 个拆分文件 → 合并为「证据3：打印截图.pdf」
- 证据5 有 4 个拆分文件 → 合并为「证据5：电脑截图.pdf」
- 未被拆分的证据（如证据1 只有 1 个文件）保持不动
策略二：unified
将证据目录 + 所有证据合并为一个「原告证据.pdf」，并添加 PDF 书签：
合并顺序：证据目录 → 证据1 → 证据2 → … → 证据N
书签格式：
📑 证据目录
📑 证据1：仲裁申请书、不予受理通知书
📑 证据2：劳动合同、保密协议
📑 证据3：被告工资表
📑 证据4：泄露账号密码的电脑截图
📑 证据5：打印及拷贝资料的电脑截图
📑 证据6：删除电脑操作痕迹的截图
书签名称使用简洁版：证据编号 + 冒号 + 证据标题（去除当事人和日期后缀）。使用 pypdf 的 add_outline_item 添加书签。
用户可随时修改
user-preferences.json切换策略，无需改动 skill 本身。
合并过程中同时标准化页面尺寸为 A4（210×297mm）。使用 pypdf 逐页处理：
from pypdf import PdfReader, PdfWriter, Transformation
A4_W = 595.27 # 210mm in points
A4_H = 841.89 # 297mm in points
for page in reader.pages:
pw, ph = float(page.mediabox.width), float(page.mediabox.height)
is_landscape = pw > ph
# 保持原始方向：纵向→A4纵向，横向→A4横向
target_w = A4_H if is_landscape else A4_W
target_h = A4_W if is_landscape else A4_H
# 等比缩放并居中
scale = min(target_w / pw, target_h / ph)
offset_x = (target_w - pw * scale) / 2
offset_y = (target_h - ph * scale) / 2
new_page = writer.add_blank_page(width=target_w, height=target_h)
page.add_transformation(Transformation().scale(scale).translate(offset_x, offset_y))
new_page.merge_page(page)
规则：
根据 user-preferences.json → rename 配置对所有文件统一重命名：
去除规则（strip_patterns）：
- 去掉括号内的当事人信息：（张三与李四合同纠纷）
- 去掉日期后缀：_20260405收
- 去掉平台标记：（合并）、（自贸法庭）、（素）-
特殊映射（special_mappings）：
- 起诉状（素）… → 起诉状（要素式）.pdf
- 开庭传票 → 传票.pdf
重命名示例：
| 原始 | 重命名后 |
|---|---|
传票（张三与李四合同纠纷）_20260405收.pdf | 传票.pdf |
起诉状（合并）.pdf | 起诉状.pdf |
起诉状（素）-要素式起诉状（合并）.pdf | 起诉状（要素式）.pdf |
应诉通知书（自贸法庭）.pdf | 应诉通知书.pdf |
E法桥平台使用告知书（xxx）_20260405收.pdf | E法桥平台使用告知书.pdf |
每次处理完成后在 archive/ 下创建 JSON 记录，格式详见 references/archive-format.md。
⚠️ 发布前清空：
archive/目录在运行时自动写入真实案件记录，对外发布前必须清空所有.json文件（保留.gitkeep和目录结构），确保案件数据不外泄。
【xx市人民法院】张三，您好！您有（2025）苏0981民初1234号案件文书送达，
请点击链接查收：
https://zxfw.court.gov.cn/zxfw/#/pagesAjkj/app/wssd/index?qdbh=DEMO1&sdbh=DEMO2&sdsin=DEMO3
如非本人操作请联系法院。
【xx市xx区人民法院】您好，您提交的立案材料已审核通过。
案号：（2025）京0105民初54321号
请及时缴纳诉讼费用。
【xx市xx区人民法院】提醒：您有（2025）苏0508民初567号案件，
定于2025年3月15日上午9:30在第3法庭开庭，请准时到庭。
【xx人民法院】您有案件文书待查收，请点击链接查收：
http://dzsd.hbfy.gov.cn/hb/msg=XXXXXXX
如有疑问请联系法院。
【xx人民法院】您有（2025）鄂xxxx民初xxxx号案件文书送达。
账号 420xxxxxxxxxxxxx
默认密码：xxxxxx
请登录 http://dzsd.hbfy.gov.cn/sfsddz 查收。
【xx人民法院】您有（2025）川xxxx民初xxxx号案件文书送达。
验证码：A1B2C3
请点击链接查收：https://sfpt.cdfy12368.gov.cn/sfsdw//r/xxxxxxxxxxxx
| 问题 | 解决方案 |
|---|---|
| 短信无法识别类型 | 展示原文，请用户确认类型后继续 |
| 案号提取失败 | 手动输入案号 |
| 当事人识别不准 | 提示用户确认/修正当事人列表 |
| 无匹配案件 | 自动在桌面新建 {原告}诉{被告} {案由}/（不询问） |
| 找到已有案卷 | 不自动归档：展示匹配路径 + 命中依据 + 同名同姓风险，请律师确认后带 --to-folder <路径> 重新运行脚本归档 |
| Playwright 下载超时 | 检查网络连接，尝试刷新页面重试 |
| 页面需要验证码 | 通知用户，暂停等待手动处理 |
| 下载文件损坏 | 清理临时目录，重新尝试下载 |
| 目标目录不存在 | 自动创建对应目录 |
| SFDW 验证码验证失败 | 尝试手机尾号后6位和短信验证码两种方式，均失败时提示用户联系法院 |
| 日历创建失败 | 检查 pypdf 是否安装，检查 AppleScript 是否有 Calendar 权限（系统偏好设置→隐私与安全性→自动化） |
| 日历事件重复 | 已内置去重（写入前自动删除同案号旧事件），如仍有重复请检查 launchd 是否有残留 plist：ls ~/Library/LaunchAgents/com.mm.court-* |
| QQ 邮件（微信送达）未收到 | 检查 ~/.court-email/*-err.log 查看 smtp.js 报错；检查 QQ 邮箱是否将自动邮件归入垃圾箱；确认授权码未过期（腾讯授权码有效期通常90天） |
| launchd 邮件提醒未触发 | 检查 ~/.court-email/*.log 查看执行记录；确认 launchd plist 已加载：`launchctl list |
| 照片文字识别不准 | 确保照片清晰、正面、光线充足；避免倾斜/阴影/手写体；如关键字段缺失可手动补充 |
references/sms-patterns.json。如需修改解析规则（添加新文书标题、调整正则等），编辑该 JSON 文件即可。config/case-parties.json。每个案件第一次处理时自动询问并记录代理方（原告/被告），用于区分「我方提交资料」和「对方提交资料」。可通过"更新代理方 <案号> <原告/被告>"手动修改。config/case-root.json。首次使用询问并缓存案卷根目录路径。杨卫薪律师（微信 ywxlaw）完成了以下核心基础工作，本技能的所有后续功能均建立在此之上：
| 模块 | 贡献 |
|---|---|
| 📱 短信解析 | 法院短信文本解析，自动提取案号、当事人、下载链接 |
| 🌐 zxfw API 下载 | 全国法院统一送达平台 API 直连，curl 无头下载 PDF |
| 📁 基础归档 | 下载 PDF 后归档到案件目录，写入内部 JSON 记录 |
| 📄 文书识别 | 正则匹配识别文书类型（传票/判决书/裁定书等） |
| 📋 多平台支持 | 广东 gdems、湖北 hbfy、集约送达、司法送达网下载 |
上述工作使本技能从零到一，Stone 了法院短信→下载→归档的核心链路。
基于 v1.5.0 核心链路，新增以下能力：
提醒体系（三条线）
期限规则库（references/deadline-rules.json）
照片 OCR（方式三）
归档体系优化
跨平台支持
自动归纳与案卷管理
--to-folder <路径> 重新运行脚本归档基于第一性原理+对抗性审查，对全部 6 个核心脚本做了一次系统级排查，修复以下问题：
提醒时机修正
hearing_notify() 函数：launchd 到点自动调用，弹系统通知 + 在桌面生成 开庭提醒_YYYY-MM-DD_HHMM.md（含时间/案号/地点/材料清单）。代码清理（P0）
court_appeal_reminder.py：已被 court_deadline_reminder.py 全覆盖且带硬编码路径（换机必炸）、缺少桌面 Markdown 提醒。TO_EMAIL 默认值统一为 YOUR_QQ_EMAIL@qq.com（修正两处占位符 YOUR_QQ_EMAIL@qq.com）。安全加固（P1）
court_deadline_reminder.py 的 send_system_notification 补齐双引号转义（replace('"', '\\"')），与 court_calendar.py 的 _macos_pop_notification 行为一致。_macos_schedule_notification、_macos_schedule_email_script、_macos_schedule）对所有动态数据（case_no/case_type/location/label）增加 xml.sax.saxutils.escape() 转义，防止 & 等特殊字符导致 plist 解析静默失败。_macos_unload_reminder 的 suffix.replace('-email', '-email') 恒等变换 → 写死字面量。安全脱敏
YOUR_QQ_EMAIL@qq.com 占位符（SKILL.md、Python 脚本、报告模板等共 16 处）config/case-root.json 中本地路径替换为占位符 /Users/你的用户名/项目/02-律师业务archive/ 目录发布前清空规则：保留目录结构和 .gitkeep，删除所有真实案件 JSON 数据_meta.json 中 ownerId 替换为占位符代理方识别（P1 新增功能）
config/case-parties.json：首次接触案件时自动询问律师代理哪一方（原告/被告）更新代理方 <案号> <原告/被告>问题：(2026)苏0281民初9011号保全裁定书下载后未触发期限规则匹配，导致：①未提取保全金额/方式/到期日等具体信息；②未创建任何日历提醒；③未计算保全到期日。
修复：
deadline-rules.json 匹配之后）：当文书为裁定书 + 含保全关键字时，强制走完整流程——提取详情 → 算到期 → 逐条创建全部提醒 → 汇总确认时间线reminders 数组有几个条目就必须全建。以冻结银行存款为例：30天 + 14天 + 7天，一条不能少。到期日当天额外追加一条兜底事件P0 修复：
deadline-rules.json 中 preservation_freeze 和 preservation_seal 规则各追加一条 before_days=0 (critical) 提醒。此前只提醒 30/14/7 天前，到期日当天无通知无邮件，仅靠日历事件兜底P1 修复：
court_deadline_reminder.py 的 _macos_create_calendar 函数对 summary 和 location 字段增加 replace('"', '\\"') 转义，防止案由含双引号导致 AppleScript 解析失败（此前仅 description 被转义）