Demand Received

/demand-received

1. 读取提供的来函文件。
2. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml 用于案件组合交叉检索。
3. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 风险校准、执业背景、律师函实务惯例。
4. 按以下工作流操作。
5. 提取关键字段；交叉检索案件组合；评估实质理由；提出方案并附建议。
6. 写入 ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md。将来函复制或链接至 ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/incoming.[ext]。
7. 按用户选择转交：
   • 创建案件 → 预填充的 /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 中起草；本技能停留在分流决定。
• 对实质问题做出最终判断。 分流评级是用于路由的判断；正式的实质法律意见应由外聘律师或更深入的分析完成。
• 替用户决定是否创建案件。 呈现推荐意见；用户决定。