demand-draft

/demand-draft

1. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md。如果文件缺失，或（对于重大索赔）战略部分为空，则拒绝继续。
2. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 索取函业务规范、内部风格指南、种子文档表。
3. 按照以下工作流和参考内容执行。
4. 运行起草前检查：特权过滤、承认风险、和解及清偿、FRE 408 立场、权利放弃扫描、语气、事实准确性。逐项完成检查后方可继续。
5. 选择模板：若 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 中提供了种子文档，则使用该文档；否则使用相应索赔类型的简易模板。
6. 在聊天中起草供审阅。反复修改，直至用户批准。
7. 使用 docx 技能写入 ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/draft-v[N].docx。
8. 写入 ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/checklist.md（发送后检查清单）。
9. 根据启发式规则评估重要性；提出是否创建事项。如同意：将已预填字段的内容移交给 matter-intake。

---

索取函起草

目的

接收已完成的 intake，并生成可发送的草稿。大部分价值在于：只有在审慎处理特权、权利放弃、承认以及和解沟通立场后，才开始起草——常见失误就是无人停下来检查，导致函件放弃特权或构成承认。

记录忠实度——引文与定位引用

索取函具有主张性质。对合同、电子邮件或先前沟通的每一句引文，都会成为对方要核实的陈述。规范性说明见插件 CLAUDE.md 中的共享防护规则；此处重申。

**逐字引文必须准确无误。**除非你手头有准确原文，否则绝不要给归于对方、其律师、证人或任何文件的文字加引号。在没有准确原文时，应这样描述：

• 转述时不要加引号，并加入占位符：“你方 [日期] 的电子邮件称 X [verify exact quote — email cite pending]。”
• **绝不要自行补全。**索取函中错误引用合同条款，是在第一轮沟通中最容易失去对方律师信任的方式。
• 每一处 [verify exact quote] 都必须在函件发出前的审阅者备注中标明。

**定位引用必须支持整个主张。**如果索取函声称“第 4.2 条要求在收到发票后 30 天内付款”，所引条款必须涵盖付款义务、触发条件和期限。如果只涵盖其中一项，就应拆分引用（例如，“第 4.2 条（付款义务）；第 4.3 条（30 天期限）”），或缩小主张范围。合同引用只支持部分索赔时，对方就可能以完整条文回应，扭转局势。

坦诚说明薄弱论点

如果法律依据或记录不支持某个观点，不要把它包装成扎实的论点。如果索取函中的论点较弱——例如合同措辞含糊、法律依据倾向相反，或损害赔偿理论牵强——应提醒发件人：

“此处的 [claim / theory] 较弱，因为 [authority / fact]。可选方案：(a) 继续主张，并将其表述为 [alternative framing]；(b) 放弃该主张，依赖 [stronger claim]；(c) 保留该主张作为切入点，但弱化措辞。[review — strategic call]。”

过度主张的索取函会招致对方逐一列出所有夸大之处的回复，转移谈判优势，并损害下一轮沟通。最有力的索取函会主动承认薄弱之处，使对方无从借题发挥。

呼应与重复

如果此事此前有往来函件，请呼应其中的关键术语——对违约行为的描述保持一致，对核心义务的表述保持一致，对交易的称谓也保持一致。不要整句照搬。要求函如果读起来像是把先前的函件复制粘贴了一遍，就会显得毫无进展；新函应推动事态发展（提出新事实、新期限、新后果），而不是重复旧内容。

对外文件： 起草好的要求函会发送给交易对方。请勿在发出的函件上加注 PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT — PREPARED AT THE DIRECTION OF COUNSEL 标题。发送后的检查清单和受理文件属于内部工作成果，应加注该标题。

侧面背景

起草要求函本质上是在提出主张——发件人是在主张权利。请查阅执业档案中的 ## Side：

• 原告／权利主张方（此技能的默认立场）：要求函的起草应与该立场一致。函件本身就是主张。语气、后果措辞以及所要求的救济，均应遵循原告方的策略。
• 被告／答辩方：被告方较少起草要求函，但也确有此类情况——被告方执业者可能会发出反向要求、要求分担责任的函件，或在无关事项中发出要求函。起草前请确认：“您说默认立场是被告方。这件事对您而言是否属于原告方立场（即由您提出主张），还是属于另一种立场？”
• 两者兼有／视情况而定：每次起草时都要询问适用哪种立场。草稿的语气和默认签署人可能会有所不同。

对于主要接收而非发送要求函的企业内部被告方执业者，请转用 demand-received；该技能用于处理收到要求函后的分流。

本事项的立场

在起草前确认环节开始之前，先确认本事项层面的立场。要求函的语气和条款应按具体案件确定，而非沿用执业层面的默认设置。请向用户确认（如受理材料中有 ## Posture 部分，则先阅读；如没有，则询问）：

本事项的立场。 要求函的语气和条款应按具体案件确定，而非沿用执业层面的默认设置。请询问：

• 语气： 克制／坚定／强硬？（取决于双方关系、金额以及是否可能诉讼）
• 回复期限： 根据索赔情况，合理期限是多久？（付款要求通常为 14 天；补救通常为 30 天；停止侵害要求通常为 7 天——但合同或规程可能另有规定）
• 标注： 是否需要标注“without prejudice”或“without prejudice save as to costs”？（和解沟通需要；提出权利主张通常不需要；这取决于司法管辖区——如不确定，请询问）
• 签署人： 您、客户、总法律顾问，还是受委托的律师／法律顾问？ 不要自行假设。如事项档案中有此前的要求函往来，请阅读——这能确立行文基调。

用户的回答将决定语气用词、后果措辞、是否加上 Without prejudice 标题、签名栏以及履行期限。凡是受理时未记录的事项立场，都应在此处记录——不得退回执业层面的默认设置。

司法管辖区假设

本草稿以受理材料中确定的司法管辖区及法院适用的和解沟通规则为前提（联邦案件适用 FRE 408，其他案件适用相应的州级规则）。法律规则、期限、费用转移以及法定依据因司法管辖区而有重大差异。如果相关事实涉及不同的法院、交易对方的住所州，或法律选择问题，草稿可能无法直接适用——发送前请予以确认。

加载上下文

• ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md — 必需；若缺失则拒绝继续
• ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 索赔函业务实践（种子文档路径、保险通知时限、创建事项的实质性门槛）、内部风格（特权标记、供语气参考的外部律师指令格式）。语气、合规期限、标记和签署人均取自 ## Posture for this matter — 这些属于事项级，而非业务实践级。
• ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml — 检查是否已有相关事项（相同交易对手），并提供交叉链接

跳过战略部分时的处理

如果 intake 中的 strategic_block: skipped 或 partial，请在运行起草前检查关卡之前提示用户：

intake 跳过了战略部分的[全部／部分]（杠杆、BATNA、语气、特权筛选）。现在起草仍会生成可用的函件，但战略部分将较为通用，并标记为 [SME VERIFY]。

• 现在补全战略部分 — 暂停，返回 /demand-intake [slug] --resume-strategic
• 仍然继续 — 继续进行起草前检查关卡；下游部分将带有标记

如果用户选择“仍然继续”，草稿中每个依赖于已跳过战略问题的部分都要内联标记 [SME VERIFY: [specific question]]。

标记

• --skip-gate → 跳过起草前清单。此选项可用，但会记录；仅当清单已单独运行并记录时使用。
• --version=N → 将草稿保存为 draft-vN.docx（默认使用下一个版本号）

起草前检查关卡

此步骤必须在任何起草工作之前运行。如果用户未参与其中，请停止。

PRE-DRAFT CHECKLIST — [slug]

1. Privilege filter
   Per intake privilege filters: [list]
   Confirm: none of these will appear in the draft?  [y/n]

2. Admission risk
   Per intake admission risk: [list]
   For each, is the phrasing controlled or removed?  [y/n per item]

3. Accord-and-satisfaction
   Per intake: [flagged risk, if any]
   Does the demand inadvertently satisfy or accept a separate claim?  [y/n]

4. Settlement-communication posture
   Research the settlement-communication protections applicable in the forum
   (FRE 408 in federal, the state equivalent otherwise). Note that protection
   attaches from conduct and context, not merely from labeling the communication.
   Intake says: [protected / not protected / case-by-case]
   Draft will [include / omit] settlement-communication markers, and will be
   structured so the substance — not just the label — supports the posture.
   Confirm.

5. Privilege waiver scan
   Will any sentence in the draft reveal the substance of our internal legal analysis (not just the conclusion)?  [y/n]
   If yes, rephrase before drafting.

6. Tone posture
   Intake says: [relationship-preserving / measured / scorched-earth]
   This will drive verb choice, framing, and consequence language. Confirm.

7. Factual accuracy
   Every fact in the draft must be verified. Not "probably true" — verified. List any facts that are not yet verified, and they will be flagged [VERIFY: ___] inline.

仅当用户已逐项参与后才能继续。用户空白确认的清单还不如没有清单。

模板选择

步骤 1：种子文档

在 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 索赔函业务实践 → 种子文档表格中，查找与 intake 索赔类型对应的条目。

• **已提供种子文档：**阅读该文档。匹配其结构、语气、签署栏、特权标记和常见章节顺序。种子文档即为模板。
• **未提供种子文档：**使用下方对应索赔类型的简化模板。

第 2 步：软模板（仅在没有种子文档时使用）

每个模板都是一个框架，包含标题和预期内容。事实需要时可偏离。

付款催告框架：

1. 当事方及关系背景（1 段）
2. 事实——债务及其来源（合同 § / 发票 / 订单）、日期
3. 违约情况——欠款金额、到期时间、发生了什么（或未发生什么）
4. 催告——具体金额、期限、付款方式
5. 后果——移交律师处理、利息、费用、催收、诉讼
6. 证据保全通知（如相关）
7. 签名栏

违约 / 补救通知框架：

1. 当事方及协议（注明合同——生效日期、当事方）
2. 被指称违反的义务——合同条款、通俗表述
3. 违约行为——具体事实、日期、现有证据
4. 补救措施——具体补救方式；补救期限（按合同约定或合理期限）
5. 未能补救的后果——终止、损害赔偿、合同中的具体救济措施
6. 保留权利
7. 签名栏

停止侵权及停止行为通知框架：

1. 当事方及我方权利（商标 / 版权 / 合同 / 普通法——明确权利）
2. 侵权 / 违规行为——具体行为、日期、证据
3. 要求——立即停止、移除、说明过往使用情况、书面确认已遵守要求
4. 合规期限
5. 不合规的后果——诉讼、禁令救济、适用时的法定损害赔偿、费用
6. 保全要求（与被指称行为相关的文件、元数据、系统）
7. 签名栏

雇佣关系终止催告框架：

1. 当事方及关系背景（前员工、雇佣日期）
2. 义务——被违反的离职后义务（保密、禁止招揽、竞业禁止、知识产权转让）；引用协议
3. 被指称的具体行为
4. 要求——停止行为、归还财物 / 知识产权、确认已遵守要求；适用时重申不得诋毁的义务
5. 后果——诉讼、禁令救济、协议中约定的律师费转付
6. 提出非正式解决方案（如在策略上适宜）
7. 保全要求
8. 签名栏

证据保全要求框架：

1. 当事方及背景——预计发生什么争议
2. 范围——文件、数据、系统、通信的类别
3. 保管人——预计持有相关材料的具名人员
4. 日期范围
5. 积极履行保全义务——暂停自动删除、保留元数据、保留设备
6. 证据毁损的后果——不利推定、制裁、律师费转付
7. 确认请求
8. 签名栏

起草规则

0. 多批次货物争议默认采用分批交付合同框架。 对于涉及《统一商法典》（U.C.C.）项下多次交付货物合同（即随时间分批发运、分批交付或多次交付）的任何违约索赔，默认采用分批交付合同框架，即 U.C.C. § 2-612 的“实质性损害该批次的价值”标准，而非 § 2-601 的完全符合规则或 § 2-711 针对单次交付的买方救济框架。

§ 2-601 的完全符合规则适用于单次交付货物合同。该规则并不能直接适用于分批交付合同；§ 2-612 对其作了调整：只有在不符情形实质性损害该批次的价值且无法补救时，买方才能拒收不符的批次；只有在不符情形实质性损害整个合同的价值时，买方才能认定整个合同遭到违约。

起草多批次货物违约的索赔函时：

• 将 [CITE: U.C.C. § 2-612 — installment contracts; substantial impairment of the installment] 作为主要法律框架，而非 § 2-601。
• 将 § 2-711 和 § 2-712（替代购买）列为违约后可采取的救济，但应使用 § 2-612 的标准表述违约认定标准。
• 在草稿上方的 [SIGNER NOTE:] 区块中提醒签署人：“本函依据 U.C.C. § 2-612（分批交付合同）起草，而非 § 2-601（完全符合规则）。两者的违约认定标准存在实质差异。发送前，请确认合同的交付安排足以认定其属于分批交付合同。”
• 如果从受理信息中无法明确合同的交付安排（例如，受理信息称“已交付三批货物”，但未确认合同是否约定分别交付各批货物，还是仅为方便运输而将一次发货拆分成多批），请标注 [VERIFY: is this an installment contract under § 2-612, or a single-delivery contract split into lots by shipping convenience?]——不要擅自断言 § 2-612 适用。

单次交付违约：采用 § 2-601 的完全符合框架。分批交付：采用 § 2-612。不得混为一谈。

1. 具体胜于形容。“2026 年 3 月 14 日，你寄送了 X”胜过“你屡次不当寄送 X”。形容词暴露出起草人掌握的事实不足。

2. 事实须能追溯至来源。 每项事实陈述都应对应一份文件、一个日期或一名证人。若尚无法核实：[VERIFY: specific claim]。

3. 将引文作为占位符。 在所有需要引用法律依据之处使用 [CITE: statute/section/case]。不得编造引文。如果用户在受理信息中提供了法律依据，应忠实使用。

4. 后果措辞应符合语气立场。

   • relationship-preserving：“我们希望不必采取进一步行动即可解决此事。”
   • measured：“若未能在 [N] 天内补救，我们将考虑采取包括诉讼在内的可选措施。”
   • scorched-earth：“若未能在 [N] 天内补救，我们将立即采取法律行动，包括寻求[具体救济]。”

5. 提供文内替代表述。 语气可能调整时，草稿中应附上简短的替代表述。格式：

   所附发票上的 $X 款项仍未支付。 [或更强硬的表述：你尚未支付所附发票上的 $X 款项，该款项应于 [date] 到期。]

6. 除非确有意图，否则不要在正式记录中讨论和解。 如果受理信息指出，在相关司法管辖区内，该沟通不受和解沟通保护，则草稿不得包含任何妥协提议、任何“without prejudice”表述，或任何可能被认定为和解沟通的措辞。请记住，保护是否适用取决于行为和语境；仅靠标签无法补救。

7. 按内部规范标注特权内容。 严格遵循 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 中关于特权内容的规范。

输出

主要文件：~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/draft-v[N].docx

使用 docx 技能生成信函格式的 .docx：

• 信头／发件人地址栏
• 日期
• 收件人地址栏
• 主题行（简洁，不透露受保密特权保护的策略）
• 称呼
• 正文（遵循模板和起草规则）
• 结尾敬语
• 按照信息收集表填写签名栏

在聊天中审阅

以便于阅读的纯文本形式展示草稿，供用户审阅并提出修改意见。先迭代修改，再写入最终版 .docx。获得批准后，写入磁盘。

发送门槛（草稿结尾说明）

在聊天展示内容和任何内部预览中，将以下说明另行附在正文之后。此说明仅供审阅者参考，并非信函正文；正式寄出前须将其删除：

这是一封供律师审阅的催告函草稿，并非可直接寄出的信函。寄出可能构成律师通信，产生 FRE 408（或州法中的对应规定）相关影响，并启动争议、反诉和诉讼时效的时钟。必须由持有执照的律师审阅和修改，并在寄出前承担专业责任。未经审阅，不得寄出此草稿。

引文核验

每个 [CITE:___] 占位符，以及从信息收集表或种子文档中提取的任何引文，在人工通过引文检索工具核验前均未经过验证。寄出前，必须进行核验：使用法律研究工具（Westlaw、CourtListener、Trellis、Descrybe 或律所平台）检查每个判例、法规和规章的准确性、效力状态及后续历史。催告函和提交的文书中若包含捏造或误引的引文，可能导致制裁。

来源标注。 在草稿中为每条引文标注来源：[Westlaw]、[CourtListener]、[Trellis]、[Descrybe]，或通过法律研究连接器获取引文时所用的具体 MCP 工具名称；对于通过网络搜索找到的引文，标注 [web search — verify]；对于模型根据训练数据回忆的引文，标注 [model knowledge — verify]；对于信息收集表或种子文档中提供的引文，标注 [user provided]。带有 verify 标签的引文捏造风险较高，应优先核验。绝不要删除或合并这些标签——它们能让签署人最快判断出哪些引文需要在寄出前核验。

不得无提示地补充来源。 如果对已配置的法律研究工具（Westlaw、CourtListener、Trellis、Descrybe 或律所平台）发起研究查询后，针对草稿所需的某项权威依据返回的结果很少或没有结果，请报告已找到的内容并停止。未经询问，不得用网络搜索或模型知识填补缺口。请说：“搜索从 [tool] 返回了 [N] 条结果。关于 [issue] 的资料似乎有限。可选方案：(1) 扩展搜索查询；(2) 尝试其他研究工具；(3) 搜索网络——结果将标记为 [web search — verify]，依赖前应与一手来源核对；或 (4) 保留 [CITE:___] 占位符并在此停止。您希望怎么做？”是否接受置信度较低的来源，由律师决定；技能不得代为决定。

~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/checklist.md — 寄出后的清单

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`. This header applies to the internal checklist file; the outgoing letter does NOT carry it.]

# Post-Send Checklist — [slug]

**Draft version sent:** [v1 / v2 / etc.]
**Sent date:** [YYYY-MM-DD — filled in after send]
**Signer:** [name]

## Pre-send (before the letter goes out)

- [ ] Final read-through by signer
- [ ] Factual accuracy: all [VERIFY] flags resolved
- [ ] Citations: all [CITE] placeholders filled and run through a citator (verify it is good law)d (if live law cited)
- [ ] Privilege markings applied per house style — note: this is an external deliverable; do not include the `PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT` header in the version sent to counterparty
- [ ] Settlement-communication markers [present / absent] as intake specified, and substance aligns with posture
- [ ] Internal copies cleared (per intake distribution list)
- [ ] Insurance tender sent (if required per house practice)
- [ ] Conflicts confirmed (if not yet cleared)

**Before the letter is sent (the consequential act):** Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md`. If the Role is Non-lawyer:

> Sending this demand letter has legal consequences — it creates a record, can trigger statutes and counterclaims, and may waive privileges or constitute admissions. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
>
> [Generate a 1-page summary: counterparty and dispute, the demand and deadline, tone posture, FRE 408 / settlement-communication status, privilege and admission risks flagged in the pre-draft gate, what could go wrong, what to ask the attorney before sending.]
>
> If you need to find a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not mark as sent — do not execute the Send mechanics below — without an explicit yes.

## Send mechanics

- [ ] Delivery method executed: [certified / email / both]
- [ ] Proof of delivery retained (certified receipt, email read-receipt, courier confirmation)
- [ ] Copies sent per distribution list

## After send

- [ ] Compliance deadline calendared: [YYYY-MM-DD]
- [ ] Escalation plan if no response: [next step + date]
- [ ] Follow-up check-in calendared: [date — typically deadline + 2 business days]
- [ ] Matter created in `_log.yaml`: [yes / no — see materiality below]

## Materiality call

**Heuristic says:** [material / immaterial]
**Reason:** [demand type / exposure / counterparty type]
**Your call:** [material → create matter] [immaterial → demand-letters record only]

If material: `/litigation-legal:matter-intake` with `source: demand-letter` pre-populated from this intake.

物质性事项创建建议

起草并填写清单后，根据以下启发式规则评估事项的重大性：

• 满足以下任一条件时，默认选择“是”：
  • 需求类型为 cease-desist、breach-cure、employment-separation 或 preservation
  • 预期结果 $$ ≥ ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 中严重程度为 medium 的区间
  • 根据态势分析，对方是客户、竞争对手或经常交锋的对手
• 否则默认选择“否”

给出判断：

重大性启发式判断：[结果]。[一句话理由。] 是否在 ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml 中创建跟踪事项？（默认：[是/否]）

如果用户接受：使用已预填接收信息的字段（对方、类型、司法管辖区、source: demand-letter、初步理论、内部利益相关方）触发 matter-intake。用户审核预填字段并确认。

如果用户拒绝：将接收信息更新为 status: drafted（用户确认后，之后更新为 sent）。记录仅保留在 ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/ 中。

版本管理

切勿覆盖已发送的草稿。发送后如需修改，使用 draft-v2.docx。已发送版本的历史记录本身就是对方收到内容的记录。

此技能不会执行的操作

• 发送信函。 仅负责起草，由用户发送。
• 检索引文。 [CITE:___] 占位符保持原样。如果用户在接收信息中提供了相关依据，就会使用；否则留空。捏造引文会带来执业过失风险。
• 绕过起草前检查。 即使使用 --skip-gate，技能也会在草稿文件中注明检查已跳过及原因。
• 改写接收信息。 如果接收信息不充分，请让用户返回 demand-intake。草稿质量取决于所读取的信息。
• 决定事项的重大性。 启发式规则只提供默认建议；用户的判断才是记录。