demand-intake

/demand-intake

1. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 索赔函实务、整体情况、风险校准。
2. 遵循下方的工作流和参考内容。
3. 执行自适应信息收集（始终包含核心 8 项；如事项重大或使用 --full，则加入策略模块）。
4. 根据标题 + 对方当事人 + 年-月生成 slug。
5. 写入 ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md。
6. 向用户确认：“信息收集已保存。准备好后运行 /litigation-legal:demand-draft [slug]。”

---

索赔信息收集

目的

起草工作在后续进行。价值在于起草前的准备——提出草率信函会跳过的问题：谈判筹码、BATNA、对不利结果的承受能力、特权筛查、实际受众。发送索赔函前不考虑这些问题，还不如不发。

加载背景信息

• ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 索赔函实务（保险理赔通知时机、创建事项的实质性门槛、任何种子文档模板）、整体情况（对方当事人类型、惯常对手模式）、风险校准（用于预估重要性）、本所风格。语气、回应期限、标注和签署人都不是实务层面的默认设置——应在下方的 ## 本事项的立场 步骤中针对每个事项分别确定。

标记

• --full → 无论重要性启发式判断如何，都执行完整的信息收集（适用于每次都希望全面收集的律师）

信息收集

本事项的立场（先询问，再进行核心信息收集）

本事项的立场。 索赔函的语气和条款应逐案确定，不应采用实务层面的默认设置。询问：

• 语气： 克制 / 坚定 / 强硬？（取决于双方关系、金额以及诉讼可能性）
• 回应期限： 根据索赔情况，合理期限是多少？（付款要求通常为 14 天；补救通常为 30 天；停止侵权通知通常为 7 天，但合同或规程可能另有规定）
• 标注： 是否需要标注“无损权利”或“无损权利，但诉讼费用除外”？（和解沟通需要；主张权利通常不需要；具体取决于司法管辖区——如不确定，请询问）
• 签署人： 你、客户、总法律顾问，还是受委托的律师？ 不要自行假定。如事项文件中有之前的索赔往来函件，请先阅读——这些函件可以确立行文风格。

在 ## 当事方 之前，将答案记录在信息收集文档的 ## 立场 部分。这些答案决定后续的信息收集和起草内容——如用户有任何一项未填写，不要采用实务层面的默认设置，而应再次询问。

核心信息 — 始终询问（8 个问题）

1. 需求类型 payment | breach-cure | cease-desist | employment-separation | preservation | other

2. 各方

• 发件方： 我方公司（如涉及多个实体，请注明具体实体）
• 收件方： 交易对手方——姓名、实体、地址
• 收件对象： 实际阅读的人是谁（总法律顾问？CEO？个人？内部法务？）
• 关系： customer | vendor | ex-employee | competitor | third-party | other

3. 触发事件

• 发生了什么，以及何时发生（日期很重要——诉讼时效、通知期限）
• 可用证据（合同、电子邮件、记录、证人）

种子文档机会：“如果您能提供相关合同、往来函件或证据，草稿的针对性会显著提升。提供文件路径即可。”

4. 法律／合同依据

• 相关条款——如适用，请注明具体合同条款
• 管辖法律（司法管辖区、法律选择条款）
• 所依据的法规或规则（可使用占位符——草稿会标注 [CITE:___]）

5. 期望结果

• 具体要求。不要只写“解决争端”——应明确要求在 Y 日期前支付 $X；停止特定活动 Z；在 N 天内补救；返还特定财产。
• 如有多项要求，请排序（主要要求与备选要求）

6. 截止期限

• 推动此事的外部期限（诉讼时效、持续损害的时间窗口、业务事件）
• 要求履行的截止期限——给予收件方多长时间。使用上文 ## 本事项的立场 中记录的回复期限；不要采用实践层面的默认期限。

7. 先前联系

• 是否曾非正式地提出此事？何时、由谁、以何种方式提出？
• 目前是否收到任何回复？
• 为什么现在要升级为发出正式催告函？

8. 发送范围

• 送达方式（询问；不采用实践层面的默认方式）
• 签署人——已记录在上文 ## 本事项的立场 中
• 抄送对象——内部相关方、保险承保人（如根据实践层面的提出索赔时限规则在正式催告前提交索赔）、律师

战略 — 在判断事项是否重大，或使用 --full 时询问

重大性判断规则：如果符合以下任一条件，就询问战略部分。

• 需求类型为 cease-desist、breach-cure、employment-separation 或 preservation
• 期望结果的金额 ≥ ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 风险校准中中等严重程度区间的下限
• 根据 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 中的态势评估，对方是客户、竞争对手或经常与我们对立的一方
• 用户使用了 --full

明确的跳过选项。 触发战略部分时，用户可以选择不回答。请直接说明：

根据判断规则，这是一项重大需求。战略部分（筹码、BATNA、语气、特权筛选）包含了起草前的大部分价值。跳过会使草稿内容更单薄。

• 现在回答 — 完成战略部分（5-7 分钟）
• 部分回答 — 完成你觉得有把握回答的部分
• 跳过 — 仅根据核心部分继续起草；我会在 intake 中标记 strategic_block: skipped

如果用户选择跳过，intake 文件会记录这一选择：

strategic_block: skipped        # answered | partial | skipped
skipped_reason: string | null   # captured if user provided one

起草技能会遵循此选择 — 仍会运行起草前检查关卡，但依赖战略部分答案的章节会标注 [SME VERIFY: leverage/tone/privilege not captured in intake]。/demand-draft 命令还会再次询问，确认用户是否想在起草前完成战略部分。

9. 谈判筹码和 BATNA

• 我们有什么谈判筹码（合同权利、事实优势、声誉、商业利益）
• 如果对方拒绝，我们怎么办 — 准备诉讼吗？公开此事吗？接受较小的结果吗？
• 对方可能的 BATNA 是什么 — 他们最好的替代方案是什么？（如果他们认为我们不会起诉，这项要求就缺乏力度。）

10. 对下行风险的容忍度

• 事件公开后可能造成的声誉影响
• 先例风险 — 这封信是否会形成影响其他事项的处理模式？
• 监管 / 披露影响（这类争议是否可能需要在 10-Q 中披露？）
• 保险影响 — 未先提交保险索赔就发送信函，是否会导致放弃承保权益？

11. 语气立场

• 已在上文的 ## Posture for this matter 中记录。此处需探讨用户选择的语气若比事实似乎支持的更强硬或更温和，会带来哪些取舍。
• 值得明确指出：强硬的语气会损害关系。如果你希望维持商业关系，同时保护法律立场，通常应选择 measured。

12. 和解沟通立场

• 调研适用于相关司法管辖区的和解沟通保护规则（联邦案件适用 FRE 408，其他情况适用州级对应规则）。这封信是否属于应受保护的和解沟通？还是属于不应受保护的权利主张？
• 如果受保护：草稿会加入和解沟通标记，并进行相应结构安排，确保支持这一立场的是实质内容（即对妥协方案的讨论），而不仅仅是标签。
• 保护取决于行为和上下文，而不只是标注。添加标记是额外的保险措施。

13. 特权筛选

• 我们的内部分析中有哪些内容绝不能出现在信中？（尚未核实的事实、我们对己方案件的疑虑、战略推理、此前的和解讨论）
• 一句措辞不当的话就可能导致相关分析的特权被放弃。请明确说明哪些内容必须排除。

14. 承认事实与以清偿为目的达成和解的风险

• 信中是否有任何内容可能被对方日后描述为对事实或责任的承认？
• 此项要求是否可能无意中满足（或被视为接受）另一项独立索赔？（以清偿为目的达成和解：兑现注明“全额付款”的支票，可能会了结存在争议的债务。）

编写 intake

Slug

[type]-[counterparty-short]-[yyyy-mm]。请在 ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/ 中确认其唯一性。

~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md

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

# Demand Intake: [title]

**Slug:** [slug]
**Demand type:** [type]
**Drafted by:** [counsel]
**Opened:** [YYYY-MM-DD]
**Status:** intake | ready-to-draft | drafted | sent | closed
**Strategic block:** answered | partial | skipped
**Skipped reason:** [if applicable]

---

## Posture

- **Tone:** [measured / assertive / aggressive — with one-line rationale tied to the relationship and the amount]
- **Response window:** [N days — tied to the claim / contract / protocol]
- **Marking:** [none / without prejudice / without prejudice save as to costs / other — with rationale]
- **Signer:** [name / role — you / client / GC / instructed counsel]

*This is the per-matter posture captured at intake. The draft skill reads from here.*

---

## Parties

- **Sender:** [our entity]
- **Recipient:** [counterparty, entity, address]
- **Recipient audience:** [who reads]
- **Relationship:** [type]

## Triggering event

[What happened, when, evidence]

## Legal / contractual basis

[Provisions, governing law, statutes]

## Desired outcome

[Specific asks in priority order]

## Deadlines

- **External:** [SoL, ongoing harm window]
- **Compliance:** [how long we give them]

## Prior outreach

[History, most recent first]

## Distribution

- **Delivery:** [method]
- **Signer:** [name/role]
- **Copies:** [list]

---

## Strategic (if applicable)

### Leverage & BATNA

[Our power, their likely response]

### Downside tolerance

[Reputational, precedent, regulatory, insurance]

### Tone posture

[relationship-preserving / measured / scorched-earth — with rationale]

### Settlement-communication posture

[Protected or not in the forum — with reasoning. Cite primary source per the applicable rule (FRE 408 or state equivalent).]

### Privilege filters

[What CANNOT appear in the draft]

### Admission / accord-and-satisfaction risk

[Specific risks flagged]

---

## Seed documents

| Doc | Path |
|---|---|
| [underlying contract] | [path or "not shared"] |
| [prior correspondence] | [path or "not shared"] |
| [evidence] | [path or "not shared"] |

---

## Materiality assessment

**Auto-heuristic says:** [material / immaterial — with reasoning]
**User call:** [material / immaterial / TBD at post-send]

写入前确认

向用户展示 intake 草稿。指出内容单薄之处：

这是 intake。我注意到 [单薄之处]。保存之前，还有什么要补充的吗？

移交起草

结尾写上：

Intake 已保存。准备好后，运行：/litigation-legal:demand-draft [slug]

以“下一步”决策树收尾

按照 CLAUDE.md ## Outputs 中的要求，以“下一步”决策树收尾。根据此技能刚刚生成的内容定制选项——五个默认分支（起草 X、升级处理、补充事实、观望、其他）只是起点，并非固定选项。决策树就是输出；由律师选择。

此技能不做什么

• 不起草信函。这是 demand-draft 的工作——这两个步骤有意分开，以便律师在起草前暂停，征求业务部门意见、咨询外部律师或提交保险索赔。
• 不决定是否发送信函。有些 intake 最后会得出“其实别发了——直接谈判吧”的结论。这是有效的结果；intake 记录仍有价值。
• 不进行利益冲突检查。如果对方是客户或已知实体，应提醒在发送前先完成利益冲突检查（参见 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md）——但检查本身属于 matter-intake 工作流，或在此技能之外进行。