Back to Details

demand-draft

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/demand-draft

/demand-draft

  1. Load 
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md
    . Refuse if missing or strategic block empty (for material demands).
  2. Load 
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    → demand-letter practice, house style, seed-doc table.
  3. Follow the workflow and reference below.
  4. Run the pre-draft gate: privilege filter, admission risk, accord-and-satisfaction, FRE 408 posture, waiver scan, tone, factual accuracy. Do not proceed until each is engaged.
  5. Template select: seed doc if provided in 
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    ; else soft template for the demand type.
  6. Draft in-chat for review. Iterate until user approves.
  7. Write 
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/draft-v[N].docx
    using the docx skill.
  8. Write 
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/checklist.md
    (post-send checklist).
  9. Assess materiality per heuristic; offer to create a matter. If yes: hand off to 
    matter-intake
    with pre-populated fields.
  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
    模块。

Demand Draft

需求函起草

Purpose

目的

Take a completed intake and produce a sendable draft. Most of the value is in refusing to draft until privilege, waiver, admission, and settlement-communication posture have been consciously addressed — the failure mode is a letter that waives privilege or constitutes an admission because no one paused to check.
基于已完成的信息采集生成可发送的草稿。核心价值在于，在未明确处理保密特权、弃权、自认和和解沟通立场前拒绝起草——失败模式为函件因未事先检查而导致保密特权放弃或构成自认。

Record fidelity — quotes and pinpoints

记录准确性——引用与精准标注

Demand letters are advocacy, and every quoted line from a contract, an email, or a prior communication becomes an assertion the counterparty will test. Canonical statement in the plugin's 
CLAUDE.md
shared guardrails; repeated here.
Verbatim quotes must be verbatim. Never put quotation marks around words attributed to the counterparty, their counsel, a witness, or any document unless you have the exact passage in front of you. When you want to characterize without the exact words:
  • Paraphrase without quotation marks, with a placeholder: "Your [date] email stated X 
    [verify exact quote — email cite pending]
    ."
  • Never fill the gap. A misquoted contract provision in a demand letter is the fastest way to lose credibility with opposing counsel on the first round.
  • Every 
    [verify exact quote]
    must be flagged in the reviewer note before the letter leaves.
Pinpoint cites must support the whole proposition. If the demand asserts "Section 4.2 requires payment within 30 days upon invoice receipt," the cited section must cover the obligation AND the trigger AND the window. If it only covers one, split the cite (e.g., "Section 4.2 (payment obligation); Section 4.3 (30-day window)") or narrow the proposition. A contract cite that backs part of the demand is how the counterparty replies with the full text and flips the posture.
需求函属于辩护文书，从合同、邮件或过往沟通中引用的每一句话都会成为对方将质疑的主张。插件
CLAUDE.md
中的共享准则有明确说明；此处再次强调。
**逐字引用必须完全准确。**除非你能看到确切原文，否则切勿将归属于对方、对方律师、证人或任何文档的内容加上引号。若你想概括而非使用确切原文：
  • 不加引号进行转述，并添加占位符：“你方[日期]邮件称X 
    [核实确切引用——邮件引用待补充]
    。”
  • **切勿自行填补空白。**需求函中错误引用合同条款是在第一轮沟通中失去对方律师信任的最快方式。
  • 所有
    [核实确切引用]
    标记必须在函件发出前的审核说明中予以标注。
**精准标注必须支撑完整主张。**若需求函主张“第4.2条要求发票收到后30天内付款”，则所引用的条款必须涵盖付款义务、触发条件和期限。若仅涵盖其中一项，则拆分引用（例如：“第4.2条（付款义务）；第4.3条（30天期限）”）或缩小主张范围。仅支持部分需求的合同引用会让对方以完整文本回应并扭转局势。

Candor about weak arguments

坦诚对待薄弱论点

When the law or the record is against a point, don't dress it up as solid. When an argument in the demand is weak — the contract language is ambiguous, the authority cuts the other way, the damages theory is a stretch — flag it for the sender:
"The [claim / theory] here is weak because [authority / fact]. Options: (a) press it and frame as 
[alternative framing]
, (b) drop it and rely on [stronger claim], (c) keep it as a hook but hedge the language. 
[review — strategic call]
."
A demand letter that over-asserts gets a response that catalogs every overreach, shifts leverage, and burns the next round. The strongest demand letter is the one that concedes what's weak so the counterparty can't.
当法律或记录不利于某一论点时，切勿将其包装为坚实论据。若需求函中的某一论点较为薄弱——合同语言模糊、法律依据相悖、损害赔偿理论牵强——需向发件人标注：
“此处的[主张/理论]较为薄弱，原因是[法律依据/事实]。可选方案：(a) 坚持该主张并以
[替代表述]
进行框架构建，(b) 放弃该主张并依赖[更有力的主张]，(c) 将其作为钩子保留但使用模糊语言。
[审核——策略决策]
。”
过度主张的需求函会收到对方罗列所有过度主张的回应，转移优势并破坏后续沟通。最有力的需求函会主动承认薄弱点，让对方无机可乘。

Echo vs repeat

呼应而非重复

If the matter has prior correspondence, echo the key terms — the same characterization of the breach, the same framing of the core obligation, the same name for the transaction. Don't lift whole sentences. A demand letter that reads like a copy-paste of the prior one signals that nothing has changed; the new letter should advance the posture (new facts, new deadline, new consequence), not restate it.
External deliverable: the drafted demand letter is sent to counterparty. Do NOT include a 
PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT — PREPARED AT THE DIRECTION OF COUNSEL
header on the outgoing letter. The post-send checklist and the intake file are internal work product and do carry the header.
若案件存在过往沟通，需呼应关键术语——对违约的相同描述、对核心义务的相同框架、对交易的相同命名。切勿照搬整句。与过往函件高度雷同的需求函表明毫无进展；新函件应推进立场（新增事实、新期限、新后果），而非重复表述。
外部交付物：起草的需求函将发送给对方。对外发出的函件不得添加
PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT — PREPARED AT THE DIRECTION OF COUNSEL
（保密且机密——律师工作成果——按律师指示准备）页眉。发送后检查清单和信息采集文件属于内部工作成果，需添加该页眉。

Side context

立场背景

Drafting a demand letter is inherently an assertion — the sender is making a claim. Read 
## Side
in the practice profile:
  • Plaintiff / claimant (default for this skill): demand-draft aligns with the posture. The letter is the claim. Tone, consequence language, and relief demanded all flow from the plaintiff-side playbook.
  • Defense / respondent: demand-drafts are less common from defense but do happen — a defense practitioner may send a counter-demand, a demand for contribution, or a demand letter in an unrelated matter. Confirm before drafting: "You said defense is your default. Is this matter plaintiff-posture for you (you're asserting a claim), or is this a different posture?"
  • Both / varies: ask per-draft which posture applies. The draft's tone and default signer may differ.
For in-house defense practitioners who receive demand letters more than they send them, route to 
demand-received
instead — that skill handles the inbound-triage case.
起草需求函本质是一种主张——发件人提出诉求。阅读实践档案中的
## Side
部分：
  • 原告/索赔人（本技能默认）：需求函起草需符合原告立场。函件即为索赔主张。语气、后果表述和要求的救济均遵循原告策略手册。
  • 被告/被索赔人：被告方发送需求函的情况较少，但确有发生——被告律师可能发送反索赔函、分摊需求函或无关案件的需求函。起草前需确认：“你方称默认立场为被告。本次案件你方是原告立场（提出索赔），还是其他立场？”
  • 两者/多变：每次起草前询问适用的立场。草稿的语气和默认签署人可能有所不同。
对于接收需求函多于发送需求函的内部被告律师，应转至
demand-received
模块——该技能处理 inbound-triage（ inbound分诊）场景。

Posture for this matter

本次案件立场

Before the pre-draft gate, confirm the matter-level posture. Demand-letter tone and terms are case-by-case, not a practice default. Confirm with the user (reading the intake's 
## Posture
section if present; asking if not):
Posture for this matter. Demand-letter tone and terms are case-by-case, not a practice default. Ask:
  • Tone: measured / assertive / aggressive? (depends on the relationship, the amount, and whether litigation is likely)
  • Response window: what's reasonable given the claim? (14 days is common for payment demands; 30 days for cure; 7 days for cease-and-desist — but the contract or protocol may set it)
  • Marking: does this need a "without prejudice" or "without prejudice save as to costs" marking? (settlement communications do; assertions of claim often don't; jurisdiction matters — ask if unsure)
  • Signer: you, the client, the GC, instructed solicitor/counsel? Don't assume. Read the prior demand correspondence in the matter file if there is any — it establishes the register.
The answers drive tone verb choice, the consequence language, the 
Without prejudice
header (or its absence), the signature block, and the compliance deadline. A posture that wasn't captured in intake gets captured here — do not fall back to a practice-level default.
在草稿前审核前，需确认案件层面的立场。需求函的语气和条款因案而异，并非实践默认。需与用户确认（若信息采集文件中有
## Posture
部分则阅读该部分；若没有则询问）：
**本次案件立场。**需求函的语气和条款因案而异，并非实践默认。请确认：
  • **语气：**温和/坚定/强硬？（取决于双方关系、索赔金额以及诉讼可能性）
  • **回应期限：**考虑到索赔内容，合理期限是多久？（付款需求通常为14天；整改需求通常为30天；停止侵权需求通常为7天——但合同或惯例可能另有规定）
  • **标记：**是否需要添加“without prejudice”（无损权利）或“without prejudice save as to costs”（除费用外无损权利）标记？（和解沟通需添加；索赔主张通常无需添加；取决于司法管辖区——若不确定请询问）
  • **签署人：**你方、客户、总法律顾问、受托律师？ 切勿假设。若案件文件中有过往需求函，请阅读——其确立了沟通基调。
上述答复将决定语气用词、后果表述、
Without prejudice
页眉（或省略）、签名栏和合规期限。信息采集未涵盖的立场需在此处确认——切勿依赖实践层面的默认设置。

Jurisdiction assumption

司法管辖区假设

This draft assumes the jurisdiction identified in the intake and the forum's applicable settlement-communication rule (FRE 408 in federal, the state equivalent otherwise). Legal rules, deadlines, fee-shifting, and statutory hooks vary materially by jurisdiction. If the underlying facts touch a different forum, a different counterparty's home state, or a choice-of-law question, the draft may not apply as written — confirm before sending.
本草稿假设适用信息采集文件中指定的司法管辖区及其适用的和解沟通规则（联邦法院适用FRE 408，州法院适用对应州规则）。法律规则、期限、费用转移和法定依据因司法管辖区而异。若基础事实涉及其他管辖地、对方所在州或法律选择问题，则草稿可能无法直接适用——发送前需确认。

Load context

加载上下文

  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md
    — required; refuse to proceed if missing
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    → Demand-letter practice (seed-doc paths, insurance-tender timing, materiality threshold for matter creation), house style (privilege markings, outside counsel directive format for tone reference). Tone, compliance period, marking, and signer come from 
    ## Posture for this matter
    — they are matter-level, not practice-level.
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml
    — to check for existing related matters (same counterparty) and offer cross-link
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md
    — 必填；若缺失则拒绝执行
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    → 需求函实践规范（种子文档路径、保险 tender 时机、创建案件的重要性阈值）、内部格式（保密标记、外部律师指示格式供语气参考）。语气、合规期限、标记和签署人来自
    ## 本次案件立场
    ——属于案件层面，而非实践层面。
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml
    — 检查是否存在相关现有案件（同一对方）并提供交叉链接选项

Strategic-block skipped handling

策略模块跳过处理

If the intake has 
strategic_block: skipped
or 
partial
, prompt the user before running the pre-draft gate:
The intake skipped [all / some] of the strategic block (leverage, BATNA, tone, privilege filters). Drafting now will produce a usable letter but the strategic sections will be generic and flagged with 
[SME VERIFY]
.
  • Complete strategic block now — pause, return to 
    /demand-intake [slug] --resume-strategic
  • Proceed anyway — continue to pre-draft gate; downstream sections flagged
If "proceed anyway," every section of the draft that depends on a skipped strategic question gets 
[SME VERIFY: [specific question]]
inline.
若信息采集文件中有
strategic_block: skipped
或
partial
标记，在执行草稿前审核前需提示用户：
信息采集跳过了[全部/部分]策略模块（杠杆、BATNA、语气、保密特权筛选）。现在起草将生成可用函件，但策略部分将为通用内容并标记
[SME VERIFY]
（专家审核）。
  • 立即完成策略模块 — 暂停，返回至
    /demand-intake [slug] --resume-strategic
  • 继续执行 — 进入草稿前审核；下游部分将标记提示
若用户选择“继续执行”，则草稿中所有依赖已跳过策略问题的部分将添加
[SME VERIFY: [具体问题]]
内联标记。

Flags

标记

  • --skip-gate
    → bypass the pre-draft checklist. Available but logged; use only when the checklist was run separately and documented.
  • --version=N
    → draft as 
    draft-vN.docx
    (default: next version number)
  • --skip-gate
    → 跳过草稿前检查清单。该选项可用但会记录日志；仅当检查清单已单独执行并记录时使用。
  • --version=N
    → 生成
    draft-vN.docx
    草稿（默认：下一个版本号）

The pre-draft gate

草稿前审核

This runs before any drafting. If the user doesn't engage with it, stop.
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.
Only proceed when the user has engaged with each item. A blank-acknowledged checklist is worse than no checklist.
此步骤在任何起草工作前执行。若用户未参与审核，则停止操作。
PRE-DRAFT CHECKLIST — [slug]

1. Privilege filter
   依据信息采集的保密特权筛选条件：[列表]
   确认：这些内容均不会出现在草稿中？  [是/否]

2. Admission risk
   依据信息采集的自认风险：[列表]
   对于每项风险，表述是否已受控或移除？  [每项是/否]

3. Accord-and-satisfaction
   依据信息采集：[标记的风险（如有）]
   需求函是否会无意中满足或接受其他主张？  [是/否]

4. Settlement-communication posture
   研究管辖地适用的和解沟通保护规则
  （联邦法院适用FRE 408，州法院适用对应州规则）。请注意，保护基于行为和上下文，而非仅靠标记沟通类型。
   信息采集显示：[受保护/不受保护/视情况而定]
   草稿将[包含/省略]和解沟通标记，且结构将确保实质内容——而非仅标签——符合立场。
   请确认。

5. Privilege waiver scan
   草稿中是否有任何语句会泄露我方内部法律分析的实质内容（而非仅结论）？  [是/否]
   若有，起草前需重新表述。

6. Tone posture
   信息采集显示：[维护关系/温和/强硬]
   这将决定用词、框架构建和后果表述。请确认。

7. Factual accuracy
   草稿中的每个事实必须经过核实。并非“可能真实”——必须核实。列出所有尚未核实的事实，它们将在草稿中标记为[VERIFY: ___]。
仅当用户已参与每项审核后才可继续。空白确认的检查清单比没有检查清单更糟糕。

Template selection

模板选择

Step 1: Seed doc

步骤1：种子文档

Check 
~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
→ Demand-letter practice → seed-doc table for the intake's demand type.
  • Seed doc provided: read it. Match structure, tone, signature block, privilege markings, typical section ordering. The seed doc is the template.
  • No seed doc: use the soft template below for the demand type.
查看
~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
→ 需求函实践规范 → 种子文档表，找到对应需求类型的种子文档。
  • **提供种子文档：**阅读该文档。匹配结构、语气、签名栏、保密标记、典型章节顺序。种子文档即为模板。
  • **无种子文档：**使用以下对应需求类型的软模板。

Step 2: Soft templates (used only when no seed doc)

步骤2：软模板（仅在无种子文档时使用）

Each is a skeleton — headings and expected content. Deviate when the facts require.
Payment demand skeleton:
  1. Parties and relationship context (1 paragraph)
  2. Facts — the obligation and its source (contract § / invoice / order), dates
  3. The default — what's owed, when due, what happened (or didn't)
  4. Demand — specific amount, deadline, method of payment
  5. Consequences — referral to counsel, interest, fees, collections, litigation
  6. Preservation notice (if relevant)
  7. Signature block
Breach / cure notice skeleton:
  1. Parties and agreement (identify the contract — effective date, parties)
  2. The obligation alleged breached — contract section, plain language
  3. The breach — specific facts, dates, evidence available
  4. Cure — what specifically would cure; cure period (from contract or reasonable)
  5. Consequences of failure to cure — termination, damages, specific remedies in the contract
  6. Preservation of rights
  7. Signature block
Cease & desist skeleton:
  1. Parties and our rights (trademark/copyright/contract/common law — identify the right)
  2. The infringement / violation — specific acts, dates, evidence
  3. Demand — cease immediately, remove, account for past use, confirm compliance in writing
  4. Compliance deadline
  5. Consequences of non-compliance — litigation, injunctive relief, statutory damages if applicable, fees
  6. Preservation demand (documents, metadata, systems related to the alleged conduct)
  7. Signature block
Employment separation demand skeleton:
  1. Parties and relationship context (ex-employee, dates of employment)
  2. The obligation — post-employment obligations breached (confidentiality, non-solicit, non-compete, IP assignment); cite the agreement
  3. The specific conduct alleged
  4. Demand — cease, return property/IP, confirm compliance, non-disparagement reinforcement if applicable
  5. Consequences — litigation, injunctive relief, fee-shifting if in the agreement
  6. Offer of informal resolution (if strategically appropriate)
  7. Preservation demand
  8. Signature block
Preservation demand skeleton:
  1. Parties and context — what dispute is anticipated
  2. Scope — categories of documents, data, systems, communications
  3. Custodians — named individuals expected to have relevant material
  4. Date range
  5. Affirmative preservation obligation — suspend auto-delete, preserve metadata, preserve devices
  6. Consequences of spoliation — adverse inference, sanctions, fee-shifting
  7. Acknowledgment request
  8. Signature block
每个模板为框架——包含标题和预期内容。根据事实需要可调整。
付款需求框架：
  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. 签名栏

Drafting rules

起草规则

  1. Installment-contract default for multi-lot goods disputes. For any breach-of-contract demand involving a multi-delivery goods contract under the U.C.C. (multiple shipments, lots, or deliveries over time), default to the installment-contract framework of U.C.C. § 2-612 — "substantial impairment of the value of the installment" — rather than § 2-601's perfect-tender rule or § 2-711's single-delivery buyer's-remedies framework.
Perfect tender under § 2-601 applies cleanly to single-delivery goods contracts. It does NOT transfer cleanly to installment contracts, where § 2-612 modifies the rule: a buyer can reject a nonconforming installment only when the nonconformity substantially impairs the value of that installment and cannot be cured; and can treat the whole contract as breached only when the nonconformity substantially impairs the value of the whole contract.
When drafting the demand letter for a multi-lot goods breach:
  • Cite 
    [CITE: U.C.C. § 2-612 — installment contracts; substantial impairment of the installment]
    as the primary framework, not § 2-601.
  • Cite § 2-711 and § 2-712 (cover) as remedies flowing from breach, but state the breach standard in § 2-612 terms.
  • Flag for the signer in a 
    [SIGNER NOTE:]
    block above the draft: "This letter is drafted under U.C.C. § 2-612 (installment contracts), not § 2-601 (perfect tender). The two have materially different breach standards. Confirm the contract's delivery structure supports installment-contract characterization before sending."
  • If the contract's delivery structure is unclear from the intake (e.g., the intake says "three lots delivered" but doesn't confirm whether the contract called for separate lot deliveries or a single shipment split for convenience), flag it 
    [VERIFY: is this an installment contract under § 2-612, or a single-delivery contract split into lots by shipping convenience?]
    — do not silently assert § 2-612 applies.
Single-delivery breach: use § 2-601 perfect-tender framing. Installment: use § 2-612. Do not conflate them.
  1. Specificity over adjectives. "On March 14, 2026, you sent X" beats "You repeatedly and improperly sent X." Adjectives are the draftsperson's tell that the facts are thin.
  2. Facts traceable to sources. Every factual assertion maps to a document, date, or witness. If not verifiable yet: 
    [VERIFY: specific claim]
    .
  3. Citations as placeholders. 
    [CITE: statute/section/case]
    wherever legal authority goes. Do not invent citations. If the user provided authorities in the intake, use them faithfully.
  4. Consequence language matches tone posture.
    • relationship-preserving
      : "We hope to resolve this without further action."
    • measured
      : "If not cured within [N] days, we will consider our options, including litigation."
    • scorched-earth
      : "Failure to cure within [N] days will result in immediate legal action, including [specific relief]."
  5. Inline alternative phrasings. Where tone could shift, the draft includes a compact alternative. Format:
    The attached invoice of $X remains unpaid. [or more assertive: You have failed to pay the attached invoice of $X, due [date].]
  6. No settlement discussion on the record unless intended. If the intake flagged the communication as not carrying settlement-communication protection in the forum, the draft does not include any offer to compromise, any "without prejudice" framing, or any language that could be characterized as a settlement communication. Remember that protection attaches from conduct and context; labeling alone is not a cure.
  7. Privilege markings per house style. Apply 
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    privilege conventions exactly.
  1. 多批次货物争议的分期合同默认规则。对于涉及《统一商法典》（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: 此为§ 2-612下的分期合同，还是为装运便利拆分的单次交付合同？]
    ——切勿默认断言§ 2-612适用。
单次交付违约：使用§ 2-601完美交付框架。分期交付：使用§ 2-612框架。切勿混淆。
  1. 具体性优先于形容词。“2026年3月14日，你方发送了X”优于“你方多次不当发送X”。形容词表明起草人事实依据薄弱。
  2. **事实可追溯至来源。**每个事实主张均对应文档、日期或证人。若尚未核实：标注
    [VERIFY: 具体主张]
    。
  3. **引用作为占位符。**法律依据处使用
    [CITE: statute/section/case]
    。切勿编造引用。若用户在信息采集文件中提供了法律依据，请如实使用。
  4. 后果表述匹配语气立场。
    • 维护关系
      ：“我们希望无需进一步行动即可解决此事。”
    • 温和
      ：“若[X]日内未整改，我们将考虑包括诉讼在内的所有选项。”
    • 强硬
      ：“[X]日内未整改将立即引发法律行动，包括[具体救济]。”
  5. **内联替代表述。**若语气可能变化，草稿包含简洁的替代表述。格式：
    附件中的X美元发票仍未支付。 [或更坚定表述：你方未支付附件中的X美元发票，该发票已于[日期]到期。]
  6. **除非有意，否则不在记录中讨论和解。**若信息采集文件标记该沟通在管辖地不受和解沟通保护，则草稿不得包含任何妥协提议、“without prejudice”框架或可能被定性为和解沟通的表述。请记住，保护基于行为和上下文；仅靠标签无法获得保护。
  7. **按内部格式添加保密标记。**严格按照
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    中的保密规范执行。

Output

输出

Primary: 
~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/draft-v[N].docx

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

Use the 
docx
skill to produce a letter-formatted .docx:
  • Letterhead / sender address block
  • Date
  • Recipient address block
  • Re: line (concise; does not reveal privileged strategy)
  • Salutation
  • Body (per template + drafting rules)
  • Closing
  • Signature block per intake
使用
docx
技能生成信函格式的.docx文件：
  • 信头/发件人地址块
  • 日期
  • 收件人地址块
  • 主题行（简洁；不得泄露保密策略）
  • 称呼
  • 正文（遵循模板+起草规则）
  • 结尾
  • 信息采集文件指定的签名栏

In-chat review

聊天窗口审核

Show the draft as readable plain text for the user to review and request edits. Iterate before writing the final .docx. Once approved, write to disk.
以可读纯文本形式展示草稿供用户审核并请求修改。生成最终.docx文件前反复迭代。一旦获得批准，写入磁盘。

Send gate (closing note on the draft)

发送审核（草稿结尾备注）

Append the following, set apart from the body, to the in-chat presentation and to any internal preview — it is a reviewer-facing note, not letter text, and is stripped before the letter goes out:
This is a draft demand letter for attorney review, not a letter ready to send. Sending it may constitute an attorney communication, create FRE 408 (or state-equivalent) implications, and start the clock on disputes, counterclaims, and statutes. A licensed attorney reviews, edits, and takes professional responsibility before sending. Do not send this draft unreviewed.
在聊天窗口展示内容和任何内部预览中添加以下内容，与正文分开——此为审核人员可见的备注，非信函文本，发送前需删除：
此为供律师审核的需求函草稿，并非可直接发送的信函。发送此草稿可能构成律师沟通，引发FRE 408（或州对应规则）相关影响，并启动争议、反索赔和诉讼时效的计时。需经持牌律师审核、修改并承担专业责任后方可发送。切勿未经审核发送此草稿。

Citation verification

引用核实

Every 
[CITE:___]
placeholder — and any citation pulled from the intake or the seed doc — is unverified until a human runs it through a citator. Before sending, run a verification pass: check each case, statute, and regulation against a legal research tool (Westlaw, CourtListener, Trellis, Descrybe, or your firm's platform) for accuracy, good law status, and subsequent history. Fabricated or misquoted citations in sent demand letters and filed documents have resulted in sanctions.
Source attribution. Tag every citation in the draft with where it came from: 
[Westlaw]
, 
[CourtListener]
, 
[Trellis]
, 
[Descrybe]
, or the specific MCP tool name for citations retrieved via a legal research connector; 
[web search — verify]
for citations surfaced by web search; 
[model knowledge — verify]
for citations the model recalled from training data; 
[user provided]
for citations supplied in the intake or seed doc. Citations tagged 
verify
carry higher fabrication risk than tool-retrieved citations and should be checked first. Never strip or collapse the tags — they are the signer's fastest signal about which citations to verify before the letter goes out.
No silent supplement. If a research query to the configured legal research tool (Westlaw, CourtListener, Trellis, Descrybe, or firm platform) returns few or no results for an authority the draft needs, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [issue]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged 
[web search — verify]
and should be checked against a primary source before relying, or (4) leave the 
[CITE:___]
placeholder and stop here. Which would you like?" A lawyer decides whether to accept lower-confidence sources; the skill does not decide for them.
每个
[CITE:___]
占位符——以及从信息采集文件或种子文档中提取的任何引用——在人工通过引证工具核实前均为未核实状态。发送前需执行核实步骤：通过法律研究工具（Westlaw、CourtListener、Trellis、Descrybe或你方律所平台）检查每个案例、法规和条例的准确性、有效性和后续历史。发送的需求函和提交的文件中存在编造或错误引用的情况已导致制裁。
**来源归因。**为草稿中的每个引用标记来源：
[Westlaw]
、
[CourtListener]
、
[Trellis]
、
[Descrybe]
，或通过法律研究连接器检索的引用对应的特定MCP工具名称；
[web search — verify]
表示通过网页搜索获取的引用；
[model knowledge — verify]
表示模型从训练数据中回忆的引用；
[user provided]
表示信息采集文件或种子文档中提供的引用。标记为
verify
的引用比工具检索的引用存在更高的编造风险，应优先检查。切勿删除或合并这些标记——它们是签署人快速识别需优先核实引用的信号。
**切勿自行补充。**若对配置的法律研究工具（Westlaw、CourtListener、Trellis、Descrybe或律所平台）的研究查询返回的草稿所需法律依据结果极少或无结果，需报告发现的内容并停止操作。切勿未经询问就通过网页搜索或模型知识填补空白。应告知用户：“从[工具]检索到[N]条结果。[问题]的覆盖范围较窄。可选方案：(1) 扩大搜索查询范围，(2) 尝试其他研究工具，(3) 网页搜索——结果将标记为
[web search — verify]
，依赖前需对照原始来源检查，或(4) 保留
[CITE:___]
占位符并停止操作。你希望选择哪种方案？”律师决定是否接受低可信度来源；本技能不得自行决定。

~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/checklist.md
— the post-send checklist

~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/checklist.md
— 发送后检查清单

markdown
[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.]
markdown
[工作成果页眉 — 按插件配置## Outputs — 因角色而异；请查看`## Who's using this`。此页眉适用于内部检查清单文件；对外发出的信函**不得**添加此页眉。]

Post-Send Checklist — [slug]

发送后检查清单 — [slug]

Draft version sent: [v1 / v2 / etc.] Sent date: [YYYY-MM-DD — filled in after send] Signer: [name]
发送的草稿版本： [v1 / v2 / 等] 发送日期： [YYYY-MM-DD — 发送后填写] 签署人： [姓名]

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.
  • 签署人最终通读
  • 事实准确性：所有[VERIFY]标记已解决
  • 引用：所有[CITE]占位符已填充并通过引证工具核实（若引用现行法律，需确认其有效性）
  • 按内部格式添加保密标记——注意：此为外部交付物；发送给对方的版本不得包含
    PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT
    页眉
  • 和解沟通标记[存在/不存在]符合信息采集文件要求，且实质内容符合立场
  • 内部副本已清理（按信息采集文件中的分发列表）
  • 已发送保险 tender（若内部实践要求）
  • 已确认无利益冲突（若尚未确认）
**信函发出前（关键行为）：**阅读
~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
中的
## Who's using this
。若角色为非律师：
发送此需求函具有法律后果——它将创建记录，可能触发法规和反索赔，并可能导致特权放弃或构成自认。你是否已与律师审核此函件？若是，请继续。若否，请将以下摘要提交给律师：
[生成1页摘要：对方及争议、需求及期限、语气立场、FRE 408/和解沟通状态、草稿前审核中标记的特权和自认风险、可能出现的问题、发送前需向律师询问的事项。]
若你需要在所在司法管辖区寻找持牌律师、事务律师、大律师或其他授权法律专业人士：你所在行业监管机构的推荐服务是最快的起点（美国为州律师协会，英格兰及威尔士为SRA/律师标准委员会，苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚为律师协会，或你所在司法管辖区的对应机构）。
未获得明确同意前，不得标记为已发送——不得执行以下发送操作。

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]
  • 已将合规期限添加至日历：[YYYY-MM-DD]
  • 已制定无回应时的升级计划：[下一步行动+日期]
  • 已将跟进检查添加至日历：[日期——通常为期限+2个工作日]
  • 已在
    _log.yaml
    中创建案件：[是/否——见下方重要性评估]

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.
undefined
启发规则结果：[重要/不重要] 原因：[需求类型/风险敞口/对方类型] 你的决定：[重要→创建案件] [不重要→仅保留需求函记录]
若重要：执行
/litigation-legal:matter-intake
，并从本次信息采集文件中预填充
source: demand-letter
字段。用户审核预填充字段并确认。
undefined

Matter auto-creation offer

自动创建案件提议

After drafting and writing the checklist, assess materiality per heuristic:
  • Default yes if ANY of:
    • Demand type is 
      cease-desist
      , 
      breach-cure
      , 
      employment-separation
      , or 
      preservation
    • Desired outcome $$ ≥ 
      ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
      medium-severity band
    • Counterparty is a customer, competitor, or frequent adversary per landscape
  • Default no otherwise
Present the call:
Materiality heuristic: [result]. [One-sentence reason.] Create a tracked matter in 
~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml
? (default: [yes/no])
If user accepts: trigger 
matter-intake
with fields pre-populated from the intake (counterparty, type, jurisdiction, 
source: demand-letter
, initial theory, internal stakeholders). User reviews pre-filled fields and confirms.
If user declines: update intake 
status: drafted
(later 
sent
when user confirms). The record stays in 
~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/
only.
起草并生成检查清单后，根据启发规则评估重要性：
  • 默认“是”的情况（满足任一）：
    • 需求类型为
      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/matters/_log.yaml
中创建跟踪案件？（默认：[是/否]）
若用户同意：触发
matter-intake
模块，从信息采集文件中预填充字段（对方、类型、司法管辖区、
source: demand-letter
、初始理论、内部利益相关方）。用户审核预填充字段并确认。
若用户拒绝：将信息采集文件的
status
更新为
drafted
（用户确认发送后更新为
sent
）。记录仅保留在
~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/
中。

Versioning

版本控制

Never overwrite a draft that has been sent. If revising after send, 
draft-v2.docx
. The sent-version history is itself the record of what the counterparty received.
切勿覆盖已发送的草稿。若发送后修订，需生成
draft-v2.docx
。发送版本历史本身就是对方收到内容的记录。

What this skill does not do

本技能不执行的操作

  • Send the letter. Drafting only. The user sends.
  • Research citations. 
    [CITE:___]
    placeholders stay as placeholders. If the user provided authorities in the intake, they're used; otherwise, blanks. Inventing cites is malpractice exposure.
  • Bypass the pre-draft gate. Even with 
    --skip-gate
    , the skill notes in the draft file that the gate was skipped and why.
  • Rewrite the intake. If the intake is thin, send the user back to 
    demand-intake
    . The draft is only as good as what it reads from.
  • Decide materiality. The heuristic offers a default; the user's call is the record.
  • **发送信函。**仅负责起草。由用户发送。
  • 研究引用。
    [CITE:___]
    占位符保持原样。若用户在信息采集文件中提供了法律依据，则使用该依据；否则留空。编造引用会引发职业过失风险。
  • **跳过草稿前审核。**即使使用
    --skip-gate
    ，技能也会在草稿文件中记录审核已跳过及原因。
  • **重写信息采集文件。**若信息采集内容薄弱，将用户转回
    demand-intake
    模块。草稿质量取决于信息采集内容。
  • **决定重要性。**启发规则提供默认选项；用户的决定为最终记录。