메뉴
诉讼信息中枢系统。接收法院短信、送达链接、纸质文书照片，自动 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에서 현재 제공할 수 있는 파일을 다운로드하세요.
88查企业风险查询与分析工具 —— 专注于中国大陆企业的法务风险查询与分析，覆盖经营异常、行政处罚、监管措施、被执行人、失信被执行人、司法案件等风险类型。支持公司名称、统一社会信用代码、companyId 三种输入方式，自动完成风险查询并输出结构化风险分析总结。 触发场景：仅当用户意图为查询企业风险/法务风险时触发。包括但不限于：企业风险查询、公司风险、经营异常、行政处罚、监管措施、被执行人、失信被执行人、司法风险、风险扫描、风险评估、企业合规审查、风险报告、XX公司有什么风险、XX公司安全吗、XX公司有没有处罚、XX公司被执行过吗。 不触发场景：纯粹的企业信息查询（如查公司、搜企业、工商信息、注册资本、法人代表、股东结构、专利商标等）不应触发本技能，请使用其他 cha88 系列工具。
Manages Rule 30(b)(6) corporate representative deposition workflows — drafting notice topics with reasonable particularity, building examination outlines, defending designees, handling objections, and preserving binding admissions for summary judgment or trial. Use when drafting or responding to 30(b)(6) notices, selecting and preparing designees, building topic-by-topic outlines, or triaging scope and privilege disputes. Trigger keywords: 30(b)(6), corporate representative deposition, topic list, designee, notice analysis, deposition objections, corporate admissions.
Guides taking and defending Rule 30(b)(6) corporate representative depositions. Drafts topic lists with reasonable particularity, builds examination outlines for binding corporate admissions, analyzes noticed topics for objections, and prepares designees. Use when drafting 30(b)(6) notices, preparing corporate deposition topics, selecting or preparing designees, or defending corporate representative depositions.
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 被转义）