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：阅读诉求函

从来函中提取以下信息：

• 发件人 — 实体、签署人、律师（如由外部律所签署）
• 收件人 — 我方公司的哪个实体／人员
• 送达方式 — 挂号信、电子邮件、快递（影响截止日期计算）
• 收件日期与签署日期
• 诉求类型 — 付款、违约／补救、停止侵权函、证据保全、和解或其他
• 具体要求 — 对方要求什么、截止时间
• 指称事实 — 对方对事发经过的说法
• 法律依据 — 对方引用的法律条文、合同条款、法律理论
• 威胁 — 对方称若我方不遵从将采取何种行动
• 和解沟通定性 — 调查适用于相关司法管辖区的和解沟通保护规则（联邦适用《联邦证据规则》第 408 条，其他情形适用相应的州法规则）。记录该诉求函是否标注为和解沟通，但请记住：保护效力取决于行为和情境，而非仅凭标签。记录标签（如有），并初步判断其内容实质上是否属于妥协协商。

步骤 2：交叉核查案件组合

在 _log.yaml 中搜索：

• 直接匹配 — 存在对方当事人相同的案件（其 slug 与发件人匹配）
• 类型匹配 — 过去与该对方当事人存在类似案件类型（已结案件也要考虑，它们有助于了解对方的模式）
• 主题重合 — 主题可能属于同一争议的案件（例如同一合同、同一产品、同一项目）

说明核查结果：

• 如果直接匹配 + 正在进行：指出几乎可以确定是同一案件；建议将来函添加到现有案件，而非新建案件。如果是旁支事项，则更新 related_matters。
• 如果直接匹配 + 已结案：指出对方当事人再次出现。可能是新的争议（新建案件），也可能是旧争议复起（重开或修订案件）。由用户决定。
• 如果类型匹配：说明其可作为先例／背景参考；这可能是不同案件，但会影响回复策略。
• 如果无匹配：属于新情况。按全新案件处理。

Step 3: 实质评估

这不是法律意见，而是结构化分析：

• 事实 — 所指称的事实是否与我们已知的信息一致？出入在哪里？
• 法律依据 — 引用的条款／法规是否确实适用？（标记引用内容，供用户核实——不要自行尝试验证法律。）
• 对方的优势 — 如果对方明天就上法庭，他们会怎么陈述案情？
• 我方的优势 — 我方可能有哪些抗辩？
• 索赔金额与可能获判金额 — 如果对方胜诉，索赔是否与法院可能判给的金额相称？
• 筹码与施压 — 对方是否真的准备起诉？是否有相应能力？根据 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md，对方是否是反复提起诉讼的对手？

给出初步评级：理由充分 / 存疑 / 理由薄弱 / 无理取闹。直言不讳。用户是在做初步筛查，不是在起草诉状。

Step 4: 回复选项

列出 3–4 种选项及其利弊：

选项 A — 实质性回复

• 适用情形：对方的主张理由充分或至少存疑；有理有据地回复有助于保护案卷记录
• 代价：以书面形式表明我方立场
• 下一步：使用预填字段起草反提案函，运行 /demand-intake

选项 B — 暂缓函

• 适用情形：需要时间调查；不想作出任何让步，也不想触发对方计算期限
• 代价：不能解决任何问题；可争取 2–4 周时间
• 下一步：起草简短的确认函

选项 C — 和解回复

• 适用情形：尽早解决比诉讼成本更低；愿意在不承认责任的前提下协商
• 代价：需要采用和解沟通的方式——研究适用规则（FRE 408 或州法对应规则），并确保回复的实质内容，而不只是标签，符合和解讨论的要求。务必避免放弃任何请求权。
• 下一步：运行 /demand-intake，并设置 type: settlement-response

选项 D — 不予回复并保留证据

• 适用情形：对方的要求毫无依据，或该期限不会造成法律上的不利后果
• 代价：在某些情境下（例如账目确认），沉默可能被对方拿来对我方不利；仍须实施法律保全
• 下一步：如尚未执行，通过 /legal-hold --issue 发起法律保全；记录该要求后继续处理其他事项

推荐其中一种。具体说明理由。

第 5 步：截止日期分级处理

• 对方提出的截止日期——记录下来，但它对我们不具约束力
• 我们的内部截止日期——我们必须作出决定的时间（通常为：对方提出的截止日期减去 5 个工作日，用于起草和审批）
• 法律截止日期——诉讼时效、合同补救期限、程序要求

标出时间紧迫的法律截止日期，并记入日历。

不得擅自补充。 如果对方来函援引了需要核实的规则、判例或法条，而对已配置的法律研究工具（Westlaw、CourtListener、Trellis、Descrybe 或律所平台）发起的研究查询针对某项依据返回的结果很少或没有结果，应报告已找到的内容并停止。未经询问，切勿通过网络搜索或模型知识填补空缺。请这样说明：“从 [工具] 返回了 [N] 条结果。对于 [引文／法律原则]，覆盖似乎有限。可选方案：(1) 扩大搜索范围，(2) 尝试其他研究工具，(3) 搜索网络——结果将标记为 [web search — verify]，依赖这些结果前应对照一手资料核实，或 (4) 保留 [SME VERIFY] 标记并在此停止。您希望选择哪种？” 是否接受可信度较低的来源，由律师决定；此技能不代其决定。

来源归属。 对分级处理中引用的每一项引文都标注其来源——包括发件人引用的依据、我方回应方案的理由，以及为评估案件依据而检索的内容——使用以下标签：[Westlaw]、[CourtListener]、[Trellis]、[Descrybe]，或从法律研究连接器检索引文时使用 MCP 工具名称；网络搜索所得引文标记为 [web search — verify]；从训练数据中回忆的引文标记为 [model knowledge — verify]；需求函本身提供的引文标记为 [user provided]。带有 verify 标签的引文伪造风险较高，应优先核实。切勿删除或合并这些标签。

第 6 步：撰写分级处理报告

输出：~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md。

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> **Privilege inheritance.** This triage is derived from the inbound demand and from the portfolio log, and it records our first-pass merit read and response posture. Those internal analyses are attorney-client and/or work-product material. Distributing this triage beyond the privilege circle — including forwarding it to the business lead without marking, sharing with the counterparty, or attaching to an insurance tender without scrubbing — can waive protection over both this document and the reasoning inside it. Store with privileged matter material, mark consistently with house privilege conventions, and make distribution decisions deliberately.

# Demand Received — Triage

> **READ FOR TRIAGE, NOT OPINION.** This document is an intake scan and an options analysis — not a legal merit opinion. The `Triage rating` below is a structured read to support the counsel's decision on how to route the demand. It is not a recommendation on the merits and does not substitute for case-specific legal analysis. Every cited statute, rule, or case is flagged for SME verification; every merit call is the counsel's, not this skill's.

**Slug:** [slug]
**Received:** [YYYY-MM-DD]
**Received by:** [entity / person]
**Incoming file:** [path]

---

## The demand

**Sender:** [entity, signer, counsel]
**Demand type:** [type]
**Specific asks:** [list]
**Their stated deadline:** [date]
**Settlement-communication framing:** [labeled / substantively / neither / ambiguous] — *protection turns on conduct and context, not the label; `[SME VERIFY]` against the forum's applicable rule*

## Facts alleged

[their version, in one paragraph]

## Legal basis cited

[citations — each inline-flagged with `[SME VERIFY: applicability / currency / jurisdiction]` — do not rely on any citation here without independent check]

## Threats / next steps they state

[list]

---

## Portfolio cross-check

**Direct match:** [slug if exists, or "none"]
**Type match / precedent:** [list or "none"]
**Subject overlap:** [list or "none"]
**Recommendation:** [new matter / add to existing / link via related_matters / standalone inbound]

---

## Merit assessment

**Facts:** [alignment with our version; disconnects]
**Legal basis:** [applicability, with flags]
**Their case if litigated:** [one paragraph]
**Our defenses:** [one paragraph]
**Damages proportionality:** [assessment]
**Credibility of threat:** [will they sue? capacity? repeat litigant?]

**Triage rating:** [substantial / debatable / weak / frivolous] — *structured read for routing, not a merit opinion; `[SME VERIFY: counsel to confirm before relying on this]`*

---

## Response options

### A. Substantive response
[Rationale, tradeoffs, next step]

### B. Holding letter
[Rationale, tradeoffs, next step]

### C. Settlement response
[Rationale, tradeoffs, next step]

### D. Ignore + preserve
[Rationale, tradeoffs, next step]

**Recommendation:** [A/B/C/D] — [two sentences why] — `[SME VERIFY: counsel to confirm before executing]`

---

## Deadlines

- **Their stated deadline:** [date]
- **Our internal decision deadline:** [date]
- **Legal deadlines:** [SoL, cure periods, procedural — with dates]

---

## Immediate actions

- [ ] Legal hold issued — [yes/no] — if no, run `/legal-hold [slug] --issue`
- [ ] Matter created in log — [yes/no/TBD]
- [ ] Counsel assigned — [who]
- [ ] Insurance tendered — [yes/no/N-A]
- [ ] Internal escalation (GC/CFO/business lead) — [who/when]

第 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 的 ## Outputs 要求，以“后续步骤”决策树结尾。根据此技能刚刚生成的内容定制选项——五个默认分支（起草 X、升级处理、补充事实、观察等待、其他事项）只是起点，并非固定选项。决策树就是输出；由律师选择。

此技能不做什么

• 核实引用的法律依据。 标记引文，供用户通过引证查询工具核查其是否仍为有效法律依据，或向外部律师咨询。对来函擅自编造法律分析会带来失职风险。
• 发送回应。 草稿应在 demand-draft 中起草；此技能止于分级处理决定。
• 最终判定案件依据。 此评分仅用于分级处理；正式的案件依据意见应由外部律师出具，或通过更全面的分析得出。
• 决定是否创建事项。 提出建议；由用户决定。