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 中记录的常发性对手？