litigation-demand-received · git:20260910.441da73 · 2026-09-10 · sha256 b97ff6d898a5bfb0
litigation-demand-received git:20260910.441da73A
Immutable. This exact content is served forever at /api/v1/blob/b97ff6d898a5bfb0.
--- name: litigation-demand-received description: 收到律师函的分诊处理——提取字段、交叉检查案件组合、评估实质、提出回应选项并给出建议，并根据需要移交给案件受理或催告处理技能。当用户说"收到律师函"、"分诊这个催告"或分享需要评估的律师函时使用。 argument-hint: "[path-to-incoming] [--slug=custom-slug]" --- # /demand-received-cn 1. 读取提供的路径中的收文文档 2. 加载 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/_log.yaml` 进行案件组合交叉检查 3. 加载 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md` → 风险校准、态势评估、律师函处理实践 4. 按照以下工作流和参考执行 5. 提取字段；交叉检查案件组合；评估实质；提出选项并给出建议 6. 写入 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/inbound/[slug]/triage.md`。将收文复制或链接至 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/inbound/[slug]/incoming.[ext]` 7. 按用户选择移交： - 创建案件 → 预填充的 `matter-intake` - 以反向催告回应 → 预填充的 `demand-intake` - 关联现有案件 → 更新日志中的 `related_matters` - 独立处理 → 无需进一步行动 --- # 收到律师函 — 分诊处理 ## 目的 收到的律师函是企业内部诉讼实务中最常见的业务类型。只有一小部分需要升级处理；大多数可以通过结构化回应或暂缓函处理。其失败模式在于将所有律师函一概而论。本技能进行分诊、交叉检查案件组合，并生成应对选项。 ## 加载上下文 - 收文文档（用户提供路径或会话中直接发送） - `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/_log.yaml` — 扫描相关案件（同一相对方、通过实体关系重叠的相对方，或案件类型+近期日期） - `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md` → 风险校准（用于实质评估）、态势评估（发函方是否为频繁对抗方？）、律师函处理实践（团队风格和回应惯例） ## 工作流 ### Step 1: 阅读律师函 从收文中提取： - **发函方** — 主体、签署人、代理律师（如由外部律所签署） - **收函方** — 我方哪个主体/人员 - **送达方式** — 公证送达、邮寄、专人送达（影响期限计算） - **收到日期** vs. **签署日期** - **催告类型** — 付款、违约/补救、停止侵权通知、证据保全、和解提议、其他 - **具体要求** — 对方要什么、何时要 - **主张事实** — 对方版本的发生了什么 - **法律依据** — 引用的法律条文、合同条款、理论依据 - **威胁内容** — 如不配合将采取什么行动 - **和解通讯标注** — 研究送达地适用的和解通讯保护规则（《最高人民法院关于适用〈中华人民共和国民事诉讼法〉的解释》第107条，仅覆盖诉讼中的和解妥协）。注意催告函是否标注为和解通讯，但需记住：保护依附于行为和情境，而非仅仅标注。记录标注情况（如有）以及对实质是否属于和解协商的初步判断。 ### Step 2: 案件组合交叉检查 在 `_log.yaml` 中检索： - **直接匹配** — 与发函方相同 slug 的案件 - **类型匹配** — 与该相对方过去相似类型的案件（已结案件也计算——可供参考模式） - **主体重叠** — 主题可能是同一争议的案件（如同一合同、同一产品、同一项目） 呈现检索结果： - 如为**直接匹配+活跃案件：** 标记为几乎肯定是同一案件；建议将收文归入现有案件，而非新开案件。如属于旁支，更新 `related_matters` - 如为**直接匹配+已结案件：** 标记——相对方再次出现。可能是新争议（新开案件）或旧争议复活（重新开放或修订）。由用户决定 - 如为**类型匹配：** 备注为参考/背景；可能是独立案件但为回应策略提供参考 - 如为**无匹配：** 新案件。按全新处理 ### Step 3: 实质评估 不是法律意见——而是结构化研读： - **事实** — 主张的事实与我们所知是否一致？差异在哪里？ - **法律依据** — 引用的条款/法律是否确实适用？（标记引文供用户核实——不得自主验证法律） - **对方实力** — 如果对方明天起诉，其诉请理由是什么？ - **我方实力** — 我们可能的抗辩有哪些？ - **请求损害赔偿 vs. 可能金额** — 其请求与法院若判令赔偿的金额是否成比例？ - **杠杆和压力** — 对方是否可信地准备起诉？是否有能力？根据 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md`，是否为惯诉对抗方？ 输出分诊评级：**有实质性依据 / 有争议 / 依据薄弱 / 无理取闹**。直接了当。用户是在做分诊，不是在写代理词。 ### Step 4: 回应选项 呈现3-4个选项及其权衡： **选项A — 实质性回应** - 适用场景：对方请求有依据或至少存在争议；理性的回复有助于保护记录 - 权衡：书面形式承诺我方立场 - 下一步：预填充字段的 `/demand-intake` 用于反向回应函 **选项B — 暂缓函/收悉确认函** - 适用场景：需要时间调查；不想让步或触发对方期限计算 - 权衡：不解决问题；争取2-4周时间 - 下一步：简短的收悉确认函草稿 **选项C — 和解回应** - 适用场景：早日解决比诉讼更划算；愿意协商但不承认 - 权衡：需采取和解通讯姿态——研究适用规则（《民诉法解释》第107条，⚠️仅覆盖诉讼中），并确保回复结构使实质而非仅标注符合和解协商要件。必须注意不构成权利自弃 - 下一步：类型为 `settlement-response` 的 `/demand-intake` **选项D — 忽略+保全** - 适用场景：请求无理取闹或期限不产生法律不利 - 权衡：沉默在某些情况下可能对我方不利（⚠️注意：诉外沉默不构成自认，但诉讼中经法官释明后仍沉默可视为承认《民事诉讼证据规定》第4条）；仍需证据保全 - 下一步：如尚未发出，运行 `/legal-hold [slug] --issue` 发出证据保存通知；记录该催告并继续 给出建议。具体说明原因。 ### Step 5: 截止日期分诊 - **对方声明的期限** — 记录，但不约束我方 - **我方内部期限** — 我们必须做决定的日期（通常为：声明期限减去5个工作日用于起草+审批） - **法律期限** — 诉讼时效（《民法典》第188条：3年普通时效，可能存在特别时效）、合同补救期、程序要求 标记任何紧张的法律期限。记入日程。 **不得静默补充。** 如收文引用的规则、案例或法律需要核实，且通过配置的法规检索工具（元典法规案例检索接口和工具）检索某一法律依据返回结果很少或无结果，应报告已发现的情况并停止。**不得**在未经询问的情况下以网络搜索或模型知识填补空白。应说明："通过[工具]检索返回[N]条结果。[引文/原则]的覆盖似乎不足。可选方案：(1) 扩大检索词，(2) 尝试不同的检索工具，(3) 进行网络搜索——结果将标记为`[网络搜索—核实]`，在使用前应核对原始来源，或 (4) 保留`[SME VERIFY]`标记并在此停止。您希望采用哪种方案？" 是否接受较低置信度来源由律师决定；本技能不能替其做决定。 **来源标注。** 将进入分诊的每条引文标注来源：对于通过元典检索的引文标注`[元典法规]`；对于网络搜索引文标注`[网络搜索—核实]`；对于从训练数据中回忆的引文标注`[模型知识—核实]`；对于催告本身提供的引文标注`[对方提供]`。标注`verify`的引文具有较高的错误风险，应优先核对。不得剥离或合并这些标记。 ### Step 6: 撰写分诊报告 输出：`$LEGAL_AGENT_PROFILE_HOME/litigation-legal/inbound/[slug]/triage.md`。 ```markdown 【工作成果标题 — per plugin config ## Outputs — 按角色不同；见 `## Who's using this`】 > **保密义务持续适用。** 本分诊报告派生自收到的律师函和案件日志，记录了我们对实质的初步判断和回应姿态。这些内部分析属于律师-客户保密信息和/或内部工作成果。将本分诊报告分发至保密义务适用范围之外——包括未标注即分享给业务负责人、与相对方分享、或未经处理即附于保险理赔通知——可能导致保密信息泄露。根据《律师法》（2026修正）第41条，律师保密义务持续有效。存储时应置于保密案件材料中，按团队保密惯例一致标注，并审慎决定分发范围。 # 收到律师函 — 分诊报告 > **阅读目的为分诊，非意见。** 本文档是受理扫描和选项分析——而非法律实质意见。下面的"分诊评级"是对律师函进行路由的结构化研读，用于支持律师决定如何处理该催告。它不是实质问题的建议，不能替代案件具体法律分析。每条引用的法条、规则或案例均标记为需SME核实；每项实质判断均由律师做出，非本技能。 **Slug:** [slug] **收到日期:** [YYYY-MM-DD] **收件人:** [主体/人员] **收文文件:** [path] --- ## 律师函概况 **发函方:** [主体、签署人、代理律师] **催告类型:** [类型] **具体要求:** [列表] **对方声明的期限:** [日期] **和解通讯标注:** [已标注/实质符合/未标注/不明确] — *保护依附于行为和情境，而非标注；需对照送达地适用规则进行`[SME VERIFY]`* ## 主张的事实 [对方版本，一段话] ## 引用的法律依据 [引文——每条内联标注`[SME VERIFY: 适用性/时效性/管辖权]`，未经独立核实不得依赖任何引文] ## 对方声明的威胁/下一步行动 [列表] --- ## 案件组合交叉检查 **直接匹配:** [如存在填写slug，或"无"] **类型匹配/参考案例:** [列表或"无"] **主体重叠:** [列表或"无"] **建议:** [新开案件/归入现有/通过related_matters关联/独立收文] --- ## 实质评估 **事实:** [与我方版本的对应情况；差异] **法律依据:** [适用性，附标记] **对方若起诉的诉请:** [一段话] **我方抗辩:** [一段话] **损害赔偿比例评估:** [评估] **威胁可信度:** [会起诉吗？有能力吗？惯诉方吗？] **分诊评级:** [有实质性依据/有争议/依据薄弱/无理取闹] — *用于路由的结构化研读，非实质意见；`[SME VERIFY: 依赖前请律师确认]` --- ## 回应选项 ### A. 实质性回应 [理由、权衡、下一步] ### B. 暂缓函/收悉确认函 [理由、权衡、下一步] ### C. 和解回应 [理由、权衡、下一步——注意《民诉法解释》第107条保护范围仅覆盖诉讼中] ### D. 忽略+保全 [理由、权衡、下一步——注意诉外沉默不构成自认] **建议:** [A/B/C/D] — [两句说明原因] — `[SME VERIFY: 执行前请律师确认]` --- ## 截止日期 - **对方声明的期限:** [日期] - **我方内部决定期限:** [日期] - **法律期限:** [诉讼时效（普通3年，特别时效注意）、补救期限、程序要求——附日期] --- ## 即时行动清单 - [ ] 证据保全/证据保存通知已发出 — [是/否] — 如否，运行 `/legal-hold [slug] --issue` - [ ] 案件已在日志中创建 — [是/否/待定] - [ ] 已指定律师 — [谁] - [ ] 保险理赔通知 — [是/否/不适用] - [ ] 内部升级（总法律顾问/财务总监/业务负责人）— [谁/何时] ``` ### Step 7: 移交 根据建议和用户确认： - 创建案件 → 移交给 `/matter-intake`，附：相对方、类型、`source: demand-letter`（收文）、初始理论框架为防御性、预填充 - 反向回应作为对外催告 → 移交给 `/demand-intake`，附：相对方、分诊报告背景、期望结果作为回应 - 关联至现有案件 → 更新该案件在 `_log.yaml` 中的 `related_matters`；在其 `history.md` 中追加事件 - 独立处理 → 保留在 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/inbound/`；不对案件组合做变更 ## 以下一步骤决策树结束 根据 CLAUDE.md `## Outputs` 以下一步骤决策树结束。根据本技能刚生成的内容定制选项——五个默认分支（起草X、升级、获取更多事实、观望等待、其他）是起点而非锁定。树是输出；律师选择。 ## 本技能不做什么 - **验证引用法律。** 标记引文供用户通过引证核查工具（通过元典法规案例检索接口和工具）核实是否为现行有效法律，或交外部律师核实。在收文催告上编造法律分析是执业风险。 - **发送回复。** 起草在 `demand-draft` 中完成；本技能止于分诊决定。 - **最终决定实质问题。** 评级是分诊研读；正式实质意见由外部律师或更彻底的分析做出。 - **做出案件创建决定。** 呈现建议；用户决定。 --- ## 附录：中国法特殊注意事项 ### A. 中国法对应概念速查 | 美国法概念 | 中国法对应 | 备注 | |-----------|-----------|------| | FRE 408 | 《民诉法解释》第107条 | ⚠️仅覆盖诉讼中，诉前和解通讯不自动受保护 | | Attorney-client privilege | 《律师法》（2026修正）第41条 | 律师保密义务 | | Privilege waiver | 保密义务边界审查 | 中国无"弃权"概念 | | Privilege inheritance | 保密义务持续适用 | 根据《律师法》（2026修正）第41条，分诊报告属于保密信息 | | Attorney work product | 内部工作成果 | 中国无对等制度 | | Accord and satisfaction | 《民法典合同编通则解释》第27-28条 + 《民法典》第557条 | 以物抵债 | | Account stated | 拟制自认 | ⚠️仅限诉讼中，诉外沉默不构成自认（《民事诉讼证据规定》第4条） | | Legal hold | 证据保全（《民诉法》第84条）+企业内部证据保存通知 | 中国无法定"legal hold"义务，但有证据保全申请权 | | Spoliation / adverse inference | 《民事诉讼证据规定》第95条 + 第48条 + 《民诉法》第111条 | 不利推定 | | Statute of limitations | 诉讼时效 | 《民法典》第188条：3年普通时效 | | Settlement-communication framing | 和解通讯保护状态 | 依据《民诉法解释》第107条 | | Without prejudice | 无对等制度 | 最接近做法：注明"本函仅为调解/和解协商目的" | | Fee-shifting | 无一般规则 | 仅特定法定情形 | | Certified mail | 公证送达或EMS邮寄+保留凭证 | | ### B. 中国特有检查项 收到律师函后还需检查： 1. **仲裁条款** — 合同是否约定仲裁？如存在有效仲裁协议，可能排除法院管辖 2. **管辖权检查** — 合同是否约定管辖法院/仲裁机构？是否属于专属管辖？ 3. **诉前调解可能性** — 是否适合通过调解解决？（人民调解、商事调解、行业调解） 4. **诉讼时效核查** — 《民法典》第188条3年普通时效，是否存在特别时效规定（如合同法、金融类1年等） 5. **证据保全需求** — 是否有必要申请证据保全（《民事诉讼法》第84条）？ ### C. 来源标注规范 | 标注 | 含义 | |------|------| | `[元典法规]` | 通过元典法规案例检索接口和工具获取 | | `[网络搜索—核实]` | 通过网络搜索获取，使用前需核对原始来源 | | `[模型知识—核实]` | 从模型训练数据中回忆，使用前需核实 | | `[对方提供]` | 律师函本身提供的引文 | | `[SME VERIFY]` | 需由领域专家（律师）核实 | ⚠️ 标注为"核实"的引文具有较高错误风险，应优先核对。