| name | demand-received |
| description | 来函分流处理——提取关键字段、交叉检索案件组合、评估实质理由、 提出响应方案并附建议，必要时转交案件登记或律师函起草。 当用户说"收到一封律师函"、"审查这个来函"或附上来函要求评估时使用。
|
| argument-hint | [来函文件路径] [--slug=自定义代号] |
/demand-received
- 读取提供的来函文件。
- 加载
~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml 用于案件组合交叉检索。
- 加载
~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 风险校准、执业背景、律师函实务惯例。
- 按以下工作流操作。
- 提取关键字段；交叉检索案件组合；评估实质理由；提出方案并附建议。
- 写入
~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md。将来函复制或链接至 ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/incoming.[ext]。
- 按用户选择转交：
- 创建案件 → 预填充的
/matter-intake
- 回复律师函 → 预填充的
/demand-intake
- 关联既有案件 → 更新日志中的
related_matters
- 独立归档 → 无需进一步操作
收函处理
目的
来函是法务诉讼实务中的常规工作。极少数需要升级；大多数可以通过结构化回复或暂时搁置信函处理。本技能进行分流、交叉检索案件组合，并提供选项。
加载上下文
- 来函文件（用户提供路径或在会话中发送）
~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml —— 扫描关联案件（相同对方、通过实体关系关联的对方、或同类案件类型+近期日期）~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 风险校准（用于实质理由评估）、执业背景（发函方是否为经常性对手？）、律师函实务惯例（事务所语调和回复默认策略）
工作流
步骤1：审读来函
从来函中提取：
- 发函方 —— 主体、签署人、代理律师（如由外部律所签署）
- 收函方 —— 我方哪个主体/人员
- 送达方式 —— 快递、电子邮件、当面送达（影响期限计算）
- 签收日期 vs. 签署日期
- 来函类型 —— 付款催告、违约整改、停止侵权通知、证据保全要求、和解要约、其他
- 具体要求 —— 对方要求什么、要求何时完成
- 主张事实 —— 对方关于事实的版本
- 法律依据 —— 援引的法律法规、合同条款、理论
- 威胁内容 —— 如不按要求履行的后果
步骤2：案件组合交叉检索
在 _log.yaml 中检索：
- 直接匹配 —— 相同对方的案件（对方简称匹配发函方）
- 类型匹配 —— 与该对方此前同类案件（已结案件仍需关注——形成对方行为模式）
- 事项重叠 —— 争议主题可能相同的案件（同一合同、同一产品、同一项目）
呈现检索结果：
- 如直接匹配 + 进行中： 几乎可以确认是同一案件；建议将来函归入既有案件，不开新案。如系边缘关联，更新
related_matters。
- 如直接匹配 + 已结： 注意——对方回头了。可能是新争议（开新案）或旧事重提（重新立案或修改原案）。用户决定。
- 如类型匹配： 注明为先例/背景参考；大概率是独立案件，但可为回复策略提供信息。
- 如无匹配： 新事项。按新案处理。
步骤3：实质理由评估
并非法律意见——是结构化的初步判断：
- 事实 —— 对方主张的事实与我方掌握的是否一致？偏差在哪里？
- 法律基础 —— 援引的法条/合同条款是否真正适用？（标注引用供用户核实——不自行验证法律。）
- 对方胜算 —— 如果对方明天起诉，ta的诉讼逻辑是什么？
- 我方抗辩 —— 我们可能的抗辩事由是什么？
- 索赔金额 vs. 合理判赔 —— 对方的请求与其胜诉后法院可能支持的金额是否成比例？
- 筹码与压力 —— 对方是否真的准备起诉？是否有诉讼能力？是否属于
~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 中记录的常发性对手？
输出分流评级：有实质根据 / 有争议空间 / 较弱 / 无依据。直说——用户在做分流，不是在写代理词。
步骤4：回复方案
提出3-4个方案并附利弊分析：
方案A —— 实质性回复
- 适用：来函有实质根据或至少存在争议空间；理性的回复能保护我方书面记录
- 权衡：在书面中固定了我方立场
- 下一步：
/demand-intake，预填充回函起草字段
方案B —— 暂搁置信函
- 适用：需要时间调查；不希望承认任何事项或触发对方期限计算
- 权衡：不解决任何问题；争取2-4周时间
- 下一步：起草简短确认函
方案C —— 和解回复
- 适用：早期和解成本低于诉讼；愿意在不承认的前提下讨论
- 权衡：需要和解谈判姿态——注意诉讼时效中断风险（《民法典》第195条）。
[法条原文]
- 下一步：
/demand-intake，类型为 type: settlement-response
方案D —— 不回复 + 保留证据
- 适用：来函无实质根据，或对方设定的期限不产生法律上的不利后果
- 权衡：沉默在某些情况下可能对我不利（如账目确认）；仍需考虑证据保全
- 下一步：如尚未发出，通过
/legal-hold --issue 发出证据保全通知；记录来函并搁置
推荐一个方案，具体说明理由。
步骤5：期限分流
- 对方宣告的期限 —— 注意，但对我方无约束力
- 我方内部决策期限 —— 必须做出决定的日期（通常：对方期限减去5个工作日用于起草+审批）
- 法定期限 —— 诉讼时效、合同约定的补正期、程序性要求
标注任何紧迫的法定期限，列入日程。
不沉默补充。 如来函引用的法规、案例或法条需核实，且向配置的法律研究工具的查询返回零条或极少结果，报告已找到的内容并停止。不要不询问就从联网搜索或模型知识填补空白。说："搜索从[工具]返回了[N]条结果。[引用/法律问题]的覆盖范围似乎很薄。选项：(1)扩大搜索查询，(2)尝试其他研究工具，(3)搜索网络——结果将标注[联网检索——需复核]，依赖前应核实，(4)标注[需审查]并在此停止。您希望选哪个？"由律师决定是否接受较低可信度的来源。
来源标注。 为分流意见中的每个引用——包括发函方援引的法律依据、我方回复方案的理由、以及实质理由评估中调取的研究——标注来源：[yuandian检索]用于通过检索连接器获取的引用；[联网检索——需复核]用于联网搜索引用；[模型知识——需验证]用于模型知识回忆的引用；[用户提供]用于来函中援引的法规。标注需验证的引用具有较高的编造风险，应首先核验。不得删除或压缩标签。
步骤6：撰写分流意见
输出：~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md。
[工作成果标头——根据插件配置 ## 输出——因角色不同；见 `## 使用者`]
# 来函分流——[对方名称]
> **用于分流判断，并非法律意见。** 本文件是登记审查和方案分析——不是法律实质意见。以下分流评级是支持律师决定如何路由来函的结构化判断，不是对实质问题的推荐意见，不替代特定案件的法律分析。每条援引的法规、规则或案例均标注供核实；每个实质判断属于律师，不属于本技能。
**代号：** [slug]
**收函日期：** [YYYY-MM-DD]
**收函主体：** [实体/人员]
**来函文件：** [路径]
---
## 来函概要
**发函方：** [主体、签署人、代理律师]
**来函类型：** [类型]
**具体要求：** [列表]
**对方设定的期限：** [日期]
## 主张事实
[对方版本，一段]
## 援引的法律依据
[引用——每条内联标注 `[需审查：法律适用性/时效性/管辖地]` —— 未经独立核对，不得依赖此处的任何引用]
## 威胁/声明的后续措施
[列表]
---
## 案件组合交叉检索
**直接匹配：** [如有，注明代号；否则"无"]
**类型匹配/先例：** [列表或"无"]
**事项重叠：** [列表或"无"]
**建议：** [新案 / 归入既有案件 / 通过 related_matters 关联 / 独立归档]
---
## 实质理由评估
**事实：** [与我方版本的一致性；分歧点]
**法律基础：** [适用性，附标注]
**对方诉讼前景：** [一段]
**我方抗辩：** [一段]
**索赔合理性：** [评估]
**威胁可信度：** [对方是否会起诉？是否有诉讼能力？是否为常发性对手？]
**分流评级：** [有实质根据 / 有争议空间 / 较弱 / 无依据] —— *用于路由的结构化判断，并非实质意见；`[需审查：律师确认后信赖]`*
---
## 回复方案
### A. 实质性回复
[理由、权衡、下一步]
### B. 暂搁置信函
[理由、权衡、下一步]
### C. 和解回复
[理由、权衡、下一步]
### D. 不回复 + 保留证据
[理由、权衡、下一步]
**推荐：** [A/B/C/D] —— [两句话说明理由] —— `[需审查：律师确认后执行]`
---
## 期限
- **对方设定的期限：** [日期]
- **我方内部决策期限：** [日期]
- **法定期限：** [诉讼时效、补正期、程序性要求——附日期]
---
## 即时行动
- [ ] 证据保全通知是否已发出——[是/否]——如否，运行 `/legal-hold [slug] --issue`
- [ ] 案件是否已在日志中创建——[是/否/待定]
- [ ] 承办律师是否已指定——[谁]
- [ ] 是否已通知保险——[是/否/不适用]
- [ ] 内部上报（法务负责人/CFO/业务负责人）——[谁/何时]
步骤7：转交
基于推荐意见和用户确认：
- 创建案件 → 转交
/matter-intake：预填充对方、类型、source: demand-letter（收函），初始理论以防御姿态构建。
- 回复律师函 → 转交
/demand-intake：预填充对方、分流上下文、期望回复结果。
- 关联既有案件 → 更新该案件在
_log.yaml 中的 related_matters；追加事件至其 history.md。
- 独立归档 → 保留在
~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/；不更新案件组合。
以下一步决策树收尾
以 CLAUDE.md ## 输出 中的下一步决策树收尾。根据本技能刚产生的内容自定义选项——五个默认分支（起草X、上报、获取更多事实、观察等待、其他选择）是起点而非锁定项。决策树本身就是输出；由律师选择。
本技能不做什么
- 验证被引用的法律。 标注引用供用户核对（确认是否为有效法律）或与外聘律师核实。对来函自行发明法律分析是执业风险敞口。
- 发送回复。 回复函在
demand-draft 中起草；本技能停留在分流决定。
- 对实质问题做出最终判断。 分流评级是用于路由的判断；正式的实质法律意见应由外聘律师或更深入的分析完成。
- 替用户决定是否创建案件。 呈现推荐意见；用户决定。
