已有完整 demand intake 时，按权限/FRE…

当用户说“draft the demand”“write the [type] letter”或已有完成的 demand intake，需要将其转为可发送的催告函草稿时使用。

适用场景

解决思路

1. 加载 `~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md`；若缺失或重大 demand 的 strategic block 为空则拒绝继续。
2. 加载 `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md`，读取 demand-letter practice、house style、seed-doc table。
3. 按工作流和参考文档执行。
4. 运行 pre-draft gate：privilege filter、admission risk、accord-and-satisfaction、FRE 408 posture、waiver scan、tone、factual accuracy；每一项都未处理前不得继续。
5. 模板选择：若 `CLAUDE.md` 提供 seed doc 则使用；否则按 demand type 使用 soft template。
6. 先在聊天中起草供审阅；迭代直到用户批准。
7. 用 docx skill 写入 `~/.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. 按启发式评估 materiality，并提议创建 matter；若同意，交给 `matter-intake`，预填字段。
10. 逐字引用必须逐字：除非眼前有准确段落，否则不要把归属于对方、对方律师、证人或任何文件的话放进引号。
11. 若想不逐字描述：不加引号改写，并加占位符：'Your [date] email stated X `[verify exact quote — email cite pending]`.'
12. 绝不要填空补缺口；demand letter 中误引合同条款会在第一轮失去对方律师信任。
13. 每个 `[verify exact quote]` 在信件发出前必须在 reviewer note 中标出。
14. pinpoint cites 必须支撑整个命题；若某 cite 只覆盖义务、触发或期限之一，就拆分 cite（如 'Section 4.2 (payment obligation); Section 4.3 (30-day window)'）或收窄命题。
15. 合同 cite 只支撑部分 demand 会让对方回复完整文本并反转姿态。
16. 当法律或记录不利于某论点时，不要把它包装成稳固。
17. 当 demand 中某论点弱（合同语言含糊、权威相反、损害理论牵强）时，向发送者标明。
18. 给出弱论点处理选项：(a) 坚持并用 `[alternative framing]` 包装；(b) 放弃并依赖更强 claim；(c) 保留作为 hook 但 hedging 语言；并标注 `[review — strategic call]`。
19. 过度断言会招致逐项反击、转移杠杆并烧掉下一轮；最强 demand letter 会承认弱处，使对方无从反击。
20. 若 matter 有先前通信，echo 关键术语——同一 breach 定性、同一核心义务框架、同一交易名称；不要整句照搬。
21. demand letter 若像先前信件的 copy-paste，会表明没有进展；新信应推进姿态（新事实、新 deadline、新后果），而非复述。
22. External deliverable：发出的 demand letter 不含 `PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT — PREPARED AT THE DIRECTION OF COUNSEL` header；post-send checklist 和 intake file 是内部工作成果，才带该 header。
23. 阅读 practice profile 的 `## Side`。
24. Plaintiff/claimant（该 skill 默认）：demand-draft 与姿态一致；tone、后果语言、请求救济均按 plaintiff-side playbook。
25. Defense/respondent：防御方较少发 demand，但可能发 counter-demand、contribution demand 或无关 matter 的 demand；起草前确认：“你默认 defense，但本 matter 是 plaintiff-posture（你在主张 claim）还是不同 posture？”
26. Both/varies：每次起草询问适用 posture；草稿 tone 和默认 signer 可能不同。
27. 对于收 demand 多于发 demand 的 in-house defense，改用 `demand-received`。
28. 在 pre-draft gate 前确认 matter-level posture；demand-letter tone 和 terms 是 case-by-case，不是 practice default。
29. 确认 tone：measured / assertive / aggressive？取决于关系、金额、是否可能诉讼。
30. 确认 response window：payment demands 常 14 days；cure 30 days；cease-and-desist 7 days；但合同或 protocol 可能另定。
31. 确认 marking：是否需要 'without prejudice' 或 'without prejudice save as to costs'？settlement communications 需要；assertions of claim 常不需要；jurisdiction 有关，不确定就问。
32. 确认 signer：你、客户、GC、instructed solicitor/counsel？
33. 不要假设；若 matter file 有先前 demand correspondence，阅读它以确定 register。
34. 这些答案驱动 tone verb、后果语言、`Without prejudice` header（或其缺失）、signature block、compliance deadline。
35. 若 intake 未捕获 posture，在此捕获；不要退回 practice-level default。
36. 草稿假定 intake 中识别的 jurisdiction 和该 forum 的 settlement-communication rule（联邦 FRE 408，否则州等效规则）。
37. 法律规则、deadlines、fee-shifting、statutory hooks 因 jurisdiction 差异很大；若事实涉及不同 forum、对方 home state 或 choice-of-law 问题，草稿可能不适用，发送前确认。
38. 必须加载 `.../intake.md`；缺失则拒绝继续。
39. 加载 `.../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）。
40. 注意：tone、compliance period、marking、signer 来自 `## Posture for this matter`，是 matter-level 而非 practice-level。
41. 加载 `.../matters/_log.yaml`，检查同一 counterparty 的已有相关 matters，并提议 cross-link。
42. 若 intake 有 `strategic_block: skipped` 或 `partial`，在运行 pre-draft gate 前提示用户。
43. 提示内容：intake 跳过[全部/部分] strategic block（leverage、BATNA、tone、privilege filters）；现在起草会得到可用信但 strategic sections 会泛化并标记 `[SME VERIFY]`。
44. 提供选项：Complete strategic block now——暂停，返回 `/demand-intake [slug] --resume-strategic`；或 Proceed anyway——继续 pre-draft gate，下游 sections 标记。
45. 若选 proceed anyway，每个依赖被跳过 strategic question 的草稿 section 内联加 `[SME VERIFY: [specific question]]`。
46. `--skip-gate`：绕过 pre-draft checklist；可用但会记录；仅当 checklist 已另行运行并有文档时使用。
47. `--version=N`：起草为 `draft-vN.docx`（默认下一个版本号）。
48. pre-draft gate 在任何起草前运行；若用户不 engage，就停止。
49. 1. Privilege filter：按 intake privilege filters 列出；确认 none 会出现在草稿？[y/n]。
50. 2. Admission risk：按 intake admission risk 列出；逐项确认 phrasing 受控或已移除？[y/n per item]。
51. 3. Accord-and-satisfaction：按 intake 的 flagged risk（如有）；确认 demand 是否无意满足或接受另一独立 claim？[y/n]。
52. 4. Settlement-communication posture：研究 forum 适用的 settlement-communication protections（联邦 FRE 408，否则州等效）；注意 protection 来自 conduct and context，不只来自 labeling。intake 说 protected / not protected / case-by-case；草稿将 include/omit settlement-communication markers，并让 substance——不只 label——支持 posture；确认。
53. 5. Privilege waiver scan：草稿中任何句子是否会揭示内部法律分析的 substance（不只是结论）？[y/n]；若是，起草前改写。
54. 6. Tone posture：intake 说 relationship-preserving / measured / scorched-earth；这会驱动动词选择、framing、后果语言；确认。
55. 7. Factual accuracy：草稿中每个事实都必须 verified，不是 'probably true'；列出尚未 verified 的事实，并内联标记 `[VERIFY: ___]`。
56. 只有当用户 engage 每项后才继续；空白确认的 checklist 比没有 checklist 更糟。
57. Step 1 Seed doc：查 `CLAUDE.md` → Demand-letter practice → seed-doc table 中 intake 的 demand type。
58. 若提供 seed doc：阅读它；匹配结构、tone、signature block、privilege markings、典型 section ordering；seed doc 就是模板。
59. 若无 seed doc：使用下面的 soft template。
60. Payment demand skeleton：1 双方与关系背景（1段）；2 事实——义务及来源（合同 § / invoice / order）、日期；3 default——欠什么、何时到期、发生了什么或未发生；4 Demand——具体金额、期限、付款方式；5 后果——转交律师、利息、费用、collections、诉讼；6 Preservation notice（如相关）；7 Signature block。
61. Breach / cure notice skeleton：1 双方与协议（识别合同——生效日期、双方）；2 被指违反的义务——合同 section、plain language；3 breach——具体事实、日期、可用的 evidence；4 Cure——具体什么能 cure；cure period（来自合同或合理）；5 未能 cure 的后果——终止、损害赔偿、合同中的具体 remedies；6 Preservation of rights；7 Signature block。
62. Cease & desist skeleton：1 双方与我们的权利（trademark/copyright/contract/common law——识别权利）；2 infringement / violation——具体行为、日期、evidence；3 Demand——立即停止、移除、account for past use、书面确认 compliance；4 Compliance deadline；5 不遵守的后果——诉讼、injunctive relief、statutory damages（如适用）、fees；6 Preservation demand（与所指控行为相关的 documents、metadata、systems）；7 Signature block。
63. Employment separation demand skeleton：1 双方与关系背景（前员工、雇佣日期）；2 义务——被违反的离职后义务（confidentiality、non-solicit、non-compete、IP assignment）；引用协议；3 所指控的具体行为；4 Demand——停止、返还 property/IP、确认 compliance、如适用重申 non-disparagement；5 后果——诉讼、injunctive relief、协议中的 fee-shifting；6 如战略上适当，提供非正式解决；7 Preservation demand；8 Signature block。
64. Preservation demand skeleton：1 双方与背景——预期什么争议；2 Scope——documents、data、systems、communications 的类别；3 Custodians——预计有相关材料的具名个人；4 Date range；5 Affirmative preservation obligation——暂停 auto-delete、保留 metadata、保留 devices；6 Spoliation 的后果——adverse inference、sanctions、fee-shifting；7 Acknowledgment request；8 Signature block。
65. 0. Multi-lot goods disputes 的 installment-contract default：任何涉及 multi-delivery goods contract under U.C.C. 的 breach-of-contract demand（多次 shipments、lots 或 deliveries over time），默认使用 U.C.C. § 2-612 的 installment-contract framework——'substantial impairment of the value of the installment'——而非 § 2-601 的 perfect-tender rule 或 § 2-711 的 single-delivery buyer's-remedies framework。
66. Perfect tender under § 2-601 适用于 single-delivery goods contracts；不干净地迁移到 installment contracts，因 § 2-612 修改规则：buyer 只能在 nonconformity substantially impairs the value of that installment 且不能 cure 时拒绝非 conforming installment；只有在 nonconformity substantially impairs whole contract 时才能把整个合同视为 breached。
67. 为 multi-lot goods breach 起草 demand letter 时：引用 `[CITE: U.C.C. § 2-612 — installment contracts; substantial impairment of the installment]` 作为主要框架，而非 § 2-601。
68. 引用 § 2-711 和 § 2-712（cover）作为从 breach 流出的 remedies，但以 § 2-612 术语陈述 breach standard。
69. 在草稿上方 `[SIGNER NOTE:]` block 中向 signer 标明：'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.'
70. 若 intake 中合同交付结构不清楚（例如 intake 说 'three lots delivered' 但未确认合同是否要求 separate lot deliveries 还是 single shipment split for convenience），标记 `[VERIFY: is this an installment contract under § 2-612, or a single-delivery contract split into lots by shipping convenience?]`；不要静默断言 § 2-612 适用。
71. Single-delivery breach：用 § 2-601 perfect-tender framing。Installment：用 § 2-612。不要混同。
72. 1. Specificity over adjectives：'On March 14, 2026, you sent X' 优于 'You repeatedly and improperly sent X'；形容词是事实单薄的标志。
73. 2. Facts traceable to sources：每个事实断言映射到 document、date 或 witness；尚不可验证则 `[VERIFY: specific claim]`。
74. 3. Citations as placeholders：法律权威处写 `[CITE: statute/section/case]`；不要发明引用；若用户 in intake 提供了 authorities，忠实使用。
75. 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].'
76. 5. Inline alternative phrasings：tone 可能变化处，草稿包含紧凑替代；格式：> *The attached invoice of $X remains unpaid.* [or more assertive: *You have failed to pay the attached invoice of $X, due [date].*]
77. 6. No settlement discussion on the record unless intended：若 intake 标记该 communication 在 forum 中不享有 settlement-communication protection，草稿不包含任何 offer to compromise、'without prejudice' framing 或任何可被定性为 settlement communication 的语言；记住 protection 来自 conduct and context，labeling 本身不是 cure。
78. 7. Privilege markings per house style：严格应用 `CLAUDE.md` privilege conventions。
79. Primary output：用 `docx` skill 生成 letter-formatted .docx 到 `.../demand-letters/[slug]/draft-v[N].docx`。
80. docx 内容包含：Letterhead / sender address block；Date；Recipient address block；Re: line（简洁；不泄露 privileged strategy）；Salutation；Body（按 template + drafting rules）；Closing；Signature block per intake。
81. In-chat review：把草稿作为可读 plain text 给用户审阅和请求编辑；在写最终 .docx 前迭代；批准后写盘。
82. Send gate（草稿结尾注）：在 in-chat presentation 和任何 internal preview 中，与正文分开附加 reviewer-facing note，发送前从信件中 strip：'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.'
83. Citation verification：每个 `[CITE:___]` placeholder——以及从 intake 或 seed doc 拉来的任何 citation——在人类用 citator 跑过前都是 unverified；发送前运行 verification pass：对每个 case、statute、regulation 用 legal research tool（Westlaw、CourtListener、Trellis、Descrybe 或 firm platform）检查 accuracy、good law status、subsequent history；sent demand letters 和 filed documents 中 fabricated 或 misquoted citations 会导致 sanctions。
84. Source attribution：给草稿中每个 citation 标记来源：`[Westlaw]`、`[CourtListener]`、`[Trellis]`、`[Descrybe]` 或通过 legal research connector 检索到的具体 MCP tool name；web search 得来标 `[web search — verify]`；模型训练知识回忆标 `[model knowledge — verify]`；intake 或 seed doc 提供标 `[user provided]`；标 verify 的 citation 比 tool-retrieved 有更高 fabrication risk，应先检查；绝不要 strip 或 collapse tags——它们是 signer 在发送前要验证哪些 citations 的最快信号。
85. No silent supplement：若对配置的 legal research tool（Westlaw、CourtListener、Trellis、Descrybe 或 firm platform）的 research query 对草稿需要的 authority 返回 few/no results，报告找到了什么并停止；不要在未询问时用 web search 或 model knowledge 填补。说：'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?'；由律师决定是否接受较低置信来源，skill 不替其决定。
86. 写入 `.../demand-letters/[slug]/checklist.md`，post-send checklist 包括 work-product header（按 plugin config ## Outputs，因 role 而异；内部 checklist file 带该 header；outgoing letter 不带）。
87. checklist 头部：Draft version sent: [v1 / v2 / etc.]；Sent date: [YYYY-MM-DD — filled in after send]；Signer: [name]。
88. Pre-send（信件发出前）：Final read-through by signer。
89. Pre-send：Factual accuracy: all [VERIFY] flags resolved。
90. Pre-send：Citations: all [CITE] placeholders filled and run through a citator (verify it is good law) if live law cited。
91. Pre-send：Privilege markings applied per house style——注意这是 external deliverable；发送给对方的版本不要包含 `PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT` header。
92. Pre-send：Settlement-communication markers [present / absent] as intake specified, and substance aligns with posture。
93. Pre-send：Internal copies cleared (per intake distribution list)。
94. Pre-send：Insurance tender sent (if required per house practice)。
95. Pre-send：Conflicts confirmed (if not yet cleared)。
96. Before the letter is sent（consequential act）：读 `.../CLAUDE.md` 的 `## Who's using this`；若 Role 是 Non-lawyer：发送 demand letter 有法律后果——创建 record、可触发 statutes 和 counterclaims、可能 waiver privileges 或构成 admissions；问是否已与 attorney 审阅；yes 则 proceed；no 则生成 1-page summary 给 attorney。
97. Non-lawyer 的 1-page summary 包括：counterparty and dispute、the demand and deadline、tone posture、FRE 408 / settlement-communication status、pre-draft gate 标出的 privilege and admission risks、what could go wrong、what to ask the attorney before sending。
98. 若需找 licensed attorney、solicitor、barrister 或其他 authorised legal professional：从职业监管机构的 referral service 开始（美国 state bar、英格兰与威尔士 SRA/Bar Standards Board、苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚 Law Society，或司法辖区等效机构）。
99. 没有 explicit yes，不要标记 sent，不要执行 Send mechanics。
100. Send mechanics：Delivery method executed: [certified / email / both]。
101. Send mechanics：Proof of delivery retained (certified receipt, email read-receipt, courier confirmation)。
102. Send mechanics：Copies sent per distribution list。
103. After send：Compliance deadline calendared: [YYYY-MM-DD]。
104. After send：Escalation plan if no response: [next step + date]。
105. After send：Follow-up check-in calendared: [date — typically deadline + 2 business days]。
106. After send：Matter created in `_log.yaml`: [yes / no — see materiality below]。
107. Materiality call：记录 heuristic says: [material / immaterial]；Reason: [demand type / exposure / counterparty type]；Your call: [material → create matter] [immaterial → demand-letters record only]。
108. 若 material：运行 `/litigation-legal:matter-intake`，用该 intake 预填 `source: demand-letter`。
109. 起草并写 checklist 后，按 heuristic 评估 materiality。
110. 默认 yes 若任一：Demand type 是 `cease-desist`、`breach-cure`、`employment-separation` 或 `preservation`；Desired outcome $$ ≥ `CLAUDE.md` medium-severity band；Counterparty 是 customer、competitor 或 frequent adversary per landscape。
111. 否则默认 no。
112. 向用户呈现：Materiality heuristic: [result]. [One-sentence reason.] Create a tracked matter in `.../matters/_log.yaml`? (default: [yes/no])。
113. 若用户接受：触发 `matter-intake`，从 intake 预填 fields（counterparty、type、jurisdiction、`source: demand-letter`、initial theory、internal stakeholders）；用户审阅预填字段并确认。
114. 若用户拒绝：更新 intake `status: drafted`（之后用户确认时 `sent`）；记录只留在 `.../demand-letters/`。
115. 不要覆盖已发送的 draft；发送后修订则 `draft-v2.docx`；sent-version history 本身就是对方收到内容的记录。
116. 不发送信件；只起草，用户发送。
117. 不研究 citations；`[CITE:___]` placeholders 保持 placeholder；若用户 in intake 提供 authorities 则使用；否则留空；发明引用是 malpractice exposure。
118. 不绕过 pre-draft gate；即使 `--skip-gate`，skill 也在 draft file 中注明 gate 被跳过及原因。
119. 不重写 intake；若 intake 单薄，把用户送回 `demand-intake`；draft 只和它读取的 intake 一样好。
120. 不决定 materiality；heuristic 提供默认，用户决定才是 record。

适用边界 · 注意事项

• 没有完整的 intake，或重大 demand 的 strategic block 为空时，不要使用；先补齐 intake/strategic block。
• 未由持照律师或合格法律专业人士审阅前，不要发送草稿；非律师角色尤其不要未确认就执行发送。
• 涉及多交付货物合同但交付结构未确认时，不要直接套 U.C.C. § 2-612；先标记 VERIFY。