demand-intake

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/demand-intake

/demand-intake

  1. Load
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    → demand-letter practice, landscape, risk calibration.
  2. Follow the workflow and reference below.
  3. Run the adaptive intake (core 8 always; strategic block if material or
    --full
    ).
  4. Generate slug from title + counterparty + year-month.
  5. Write
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/[slug]/intake.md
    .
  6. Confirm with user: "Intake saved. Run
    /litigation-legal:demand-draft [slug]
    when ready."

  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]
    。"

Demand Intake

需求函信息收集

Purpose

目的

The drafting is downstream. The value is in the pre-writing — forcing the questions a careless letter skips. Leverage, BATNA, downside tolerance, privilege filters, the actual audience. A demand letter sent without thinking about those is worse than no letter.
起草是后续环节,核心价值在于起草前的工作——提出那些粗心的函件会忽略的问题:谈判筹码、BATNA、风险承受能力、保密信息过滤、实际受众。未考虑这些因素就发出的需求函还不如不发。

Load context

加载背景信息

  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    → Demand-letter practice (insurance-tender timing, materiality threshold for matter creation, any seed-doc templates), landscape (counterparty type, repeat-adversary patterns), risk calibration (to pre-estimate materiality), house style. Tone, compliance period, marking, signer are NOT practice-level defaults — they are set per matter in the
    ## Posture for this matter
    step below.
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    → 需求函实务(保险通知时限、事项成立的重要性阈值、任何种子文档模板)、行业情况(对方主体类型、重复对手模式)、风险校准(预先评估重要性)、内部风格。语气、合规期限、标记、签署人不属于实务层面默认设置——需在下方
    ## 本次事项定位
    步骤中按个案设置。

Flags

参数

  • --full
    → run the complete intake regardless of materiality heuristics (for counsel who wants thorough every time)
  • --full
    → 无论重要性启发式判断结果如何,均运行完整信息收集流程(适用于每次都要求详尽的律师)

The intake

信息收集流程

Posture for this matter (ask FIRST, before the core)

本次事项定位(先于核心问题询问)

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.
Record the answers in the intake under a
## Posture
section before
## Parties
. These answers govern the rest of the intake and the downstream draft — do not fall back to a practice-level default if the user left any of them blank; ask again.
本次事项定位。需求函的语气和条款需按个案确定,而非实务默认设置。需询问:
  • 语气:稳健/坚定/强硬?(取决于双方关系、金额大小以及诉讼可能性)
  • 回复期限:考虑诉求性质,合理期限是多久?(付款要求通常为14天;整改要求为30天;停止侵权通知为7天——但合同或协议可能另有规定)
  • 标记:是否需要标注"without prejudice"(无损害)或"without prejudice save as to costs"(无损害但保留费用主张)?(和解沟通需标注;权利主张通常无需标注;管辖地会影响要求——如有疑问请询问)
  • 签署人:您、客户、法务总监、受托律师? 请勿主观假设。若事项文件中有过往需求函往来记录,请查阅——这将确立沟通基准。
## 各方主体
之前,将答案记录在信息收集文件的
## 定位
部分。这些答案将指导后续所有信息收集工作及下游起草环节;若用户未填写任何一项,请再次询问,不要退而求其次使用实务层面默认设置。

Core — always asked (8 questions)

核心问题——必问(8项)

1. Demand type
payment | breach-cure | cease-desist | employment-separation | preservation | other
2. Parties
  • Sender: our company (and any specific entity if multi-entity)
  • Recipient: counterparty — name, entity, address
  • Recipient audience: who actually reads (GC? CEO? individual? in-house legal?)
  • Relationship:
    customer | vendor | ex-employee | competitor | third-party | other
3. Triggering event
  • What happened and when (dates matter — statute-of-limitations, notice periods)
  • Evidence available (contracts, emails, records, witnesses)
Seed doc opportunity: "If you can share the underlying contract, correspondence, or evidence, the draft will be materially sharper. Paths work."
4. Legal / contractual basis
  • Which provisions — specific contract sections if applicable
  • Governing law (jurisdiction, choice-of-law clause)
  • Statutes or rules relied on (placeholders OK — the draft will flag
    [CITE:___]
    anyway)
5. Desired outcome
  • Specific asks. Not "resolution" — payment of $X by date Y; cessation of specific activity Z; cure within N days; return of specific property.
  • If multiple asks, order them (primary vs. fallback)
6. Deadlines
  • External deadline driving this (SoL, ongoing harm window, business event)
  • Demand compliance deadline — how long we give the recipient. Use the response window captured in
    ## Posture for this matter
    above; do not fall back to a practice-level default.
7. Prior outreach
  • Has this been raised informally? When, by whom, in what form?
  • Any response so far?
  • Why is escalation to a demand letter happening now?
8. Distribution
  • Delivery method (ask; no practice-level default)
  • Signer — captured in
    ## Posture for this matter
    above
  • Copies — internal stakeholders, insurance carrier (if tendering pre-demand per practice-level tender-timing rule), counsel
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日内整改;归还特定财产。
  • 若有多项诉求,请排序(主要诉求vs备选诉求)
6. 截止期限
  • 驱动本次需求的外部截止期限(诉讼时效、持续损害窗口期、商业事件)
  • 需求合规期限——给予收件方的回复时长。使用
    ## 本次事项定位
    中收集的回复期限;不要使用实务层面默认设置。
7. 过往沟通
  • 是否已进行非正式沟通?时间、沟通人、沟通形式?
  • 目前是否收到任何回复?
  • 为何现在要升级为发送需求函?
8. 分发安排
  • 交付方式(询问用户;无实务层面默认设置)
  • 签署人——取自
    ## 本次事项定位
    中的收集信息
  • 抄送对象——内部利益相关方、保险公司(若按实务层面通知时限要求需在发函前通知)、律师

Strategic — asked if material, or if
--full

战略问题——若事项重要或使用
--full
则询问

Materiality heuristic: ask the strategic block if any of the following are true.
  • Demand type is
    cease-desist
    ,
    breach-cure
    ,
    employment-separation
    , or
    preservation
  • Desired outcome dollar value ≥ the medium-severity band from
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    risk calibration
  • Counterparty is a customer, competitor, or frequent adversary per
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    landscape
  • User ran with
    --full
Explicit skip option. When the strategic block is triggered, the user can decline to answer it. Ask plainly:
This is a material demand by the heuristic. The strategic block (leverage, BATNA, tone, privilege filters) is where most of the pre-writing value lives. Skipping it produces a thinner draft.
  • Answer now — walk the strategic block (5-7 min)
  • Answer partial — walk the subset you feel prepared for
  • Skip — proceed to draft with only the core block; I'll flag
    strategic_block: skipped
    in the intake
If the user chooses Skip, the intake file records it:
yaml
strategic_block: skipped        # answered | partial | skipped
skipped_reason: string | null   # captured if user provided one
The draft skill honors the skip — pre-draft gate runs regardless, but sections that depend on strategic-block answers get
[SME VERIFY: leverage/tone/privilege not captured in intake]
markers. The
/demand-draft
command also prompts a second time, asking whether the user wants to complete the strategic block before drafting.
9. Leverage and BATNA
  • What gives us negotiating power (contractual rights, factual leverage, reputational, commercial)
  • What if they refuse — are we prepared to litigate? Go public? Accept a smaller outcome?
  • Their likely BATNA — what's their best alternative? (If they don't think we'll sue, the demand is weak.)
10. Downside tolerance
  • Reputational exposure if this becomes public
  • Precedent risk — does this letter set a pattern that affects other matters?
  • Regulatory / disclosure implications (is this the kind of dispute that becomes a 10-Q item?)
  • Insurance implications — does sending without tendering waive coverage?
11. Tone posture
  • Already captured in
    ## Posture for this matter
    above. Here, probe the trade-off if the user chose a stronger tone than the facts seem to warrant, or a weaker tone than the facts seem to warrant.
  • Worth naming explicitly: aggressive tone burns the relationship. If you want to keep the business relationship but need to protect the legal position,
    measured
    is usually the right call.
12. Settlement-communication posture
  • Research the settlement-communication protections applicable in the forum (FRE 408 in federal, the state equivalent otherwise). Is this letter a settlement communication that should be protected? Or an assertion of rights that shouldn't be?
  • If protected: the draft will include the settlement-communication marker and will be structured so the substance (a discussion of compromise) — not just the label — supports the posture.
  • Protection attaches from conduct and context, not merely from labeling. The marker is a belt-and-suspenders choice.
13. Privilege filters
  • What's in our internal analysis that must NOT appear in the letter? (Facts we haven't verified, our doubts about our case, strategic reasoning, prior settlement discussions)
  • A single badly-worded sentence can waive privilege on related analysis. Be explicit about what stays out.
14. Admission and accord-and-satisfaction risk
  • Anything in the letter that the counterparty could later characterize as an admission of fact or liability?
  • Does this demand risk inadvertently satisfying (or purporting to accept) a separate claim? (Accord-and-satisfaction: cashing a check marked "payment in full" can end a disputed debt.)
重要性启发式判断:若满足以下任一条件,则询问战略模块问题。
  • 需求类型为
    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分钟)
  • 部分回答——仅回答您已准备好的部分
  • 跳过——仅基于核心问题进行起草;我会在信息收集文件中标记
    strategic_block: skipped
若用户选择跳过,信息收集文件将记录:
yaml
strategic_block: skipped        # answered | partial | skipped
skipped_reason: string | null   # 若用户提供则记录
起草技能将尊重跳过选择——预起草检查仍会进行,但依赖战略模块答案的部分会标记
[SME VERIFY: leverage/tone/privilege not captured in intake]
/demand-draft
命令还会再次提示用户,询问是否要在起草前完成战略模块问答。
9. 谈判筹码与BATNA
  • 我方的谈判优势是什么(合同权利、事实筹码、声誉、商业因素)
  • 若对方拒绝,我方是否准备好诉讼?公开事件?接受更小的结果?
  • 对方可能的BATNA——他们的最佳替代方案是什么?(若他们认为我方不会起诉,需求函将缺乏力度。)
10. 风险承受能力
  • 若事件公开,我方的声誉风险
  • 先例风险——本函件是否会形成影响其他事项的模式?
  • 监管/披露影响(是否属于需纳入10-Q报告的争议类型?)
  • 保险影响——未提前通知保险公司就发送函件是否会导致保险 coverage 被撤销?
11. 语气定位
  • 已在
    ## 本次事项定位
    中收集。此处需进一步探讨:若用户选择的语气与事实情况不符(过强或过弱),需权衡利弊。
  • 需明确说明:强硬语气会破坏双方关系。若希望维持业务关系但需保护法律立场,
    稳健
    通常是最佳选择。
12. 和解沟通定位
  • 研究管辖地适用的和解沟通保护规则(联邦适用FRE 408,州适用对应规则)。本函件是否属于需受保护的和解沟通?还是无需保护的权利主张?
  • 若需保护:起草的函件将包含和解沟通标记,并调整结构,使实质内容(妥协讨论)而非仅标签支持该定位。
  • 保护效力源于行为和背景,而非仅标签。标记是双重保障措施。
13. 保密信息过滤
  • 我方内部分析中有哪些内容绝对不能出现在函件中?(未核实的事实、我方对案件的疑虑、战略推理、过往和解讨论)
  • 一句措辞不当的话可能导致相关分析的保密特权被放弃。请明确说明哪些内容需排除在外。
14. 自认与和解清偿风险
  • 函件中是否存在可能被对方日后认定为事实或责任自认的内容?
  • 本次需求是否存在无意中满足(或声称接受)另一项主张的风险?(和解清偿:兑现标注"全额付款"的支票可能终结有争议的债务。)

Writing the intake

撰写信息收集文件

Slug

Slug

[type]-[counterparty-short]-[yyyy-mm]
. Confirm uniqueness in
~/.claude/plugins/config/claude-for-legal/litigation-legal/demand-letters/
.
格式为
[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

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

markdown
[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]
markdown
[工作产品页眉 — 按插件配置## 输出内容 — 因角色而异;请查阅`## 使用者`]

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]

Slug: [slug] 需求类型: [type] 起草人: [律师] 创建日期: [YYYY-MM-DD] 状态: intake | ready-to-draft | drafted | sent | closed 战略模块: answered | partial | skipped 跳过原因: [若适用]

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.

  • 语气: [稳健/坚定/强硬 — 附与双方关系及金额相关的一句话理由]
  • 回复期限: [N天 — 与诉求/合同/协议相关]
  • 标记: [无/without prejudice/without prejudice save as to costs/其他 — 附理由]
  • 签署人: [姓名/职位 — 您/客户/法务总监/受托律师]
此为信息收集阶段确定的个案定位。起草技能将从此处读取信息。

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

谈判筹码 & 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).]
[管辖地是否受保护 — 附理由。引用适用规则的原始依据(FRE 408或州对应规则)。]

Privilege filters

保密信息过滤

[What CANNOT appear in the draft]
[绝对不能出现在草稿中的内容]

Admission / accord-and-satisfaction risk

自认/和解清偿风险

[Specific risks flagged]

[明确标记的具体风险]

Seed documents

种子文档

DocPath
[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]
undefined
自动启发式判断: [重要/不重要 — 附理由] 用户判断: [重要/不重要/发件后待定]
undefined

Confirm before writing

撰写前确认

Show the user the draft intake. Flag anything thin:
Here's the intake. I notice [thin spots]. Before I save, anything to add?
向用户展示信息收集草稿。标记内容薄弱的部分:
这是信息收集草稿。我注意到[内容薄弱点]。保存前是否有补充内容?

Handoff to drafting

移交至起草环节

End with:
Intake saved. When ready:
/litigation-legal:demand-draft [slug]
结尾说明:
信息收集已保存。准备就绪时运行:
/litigation-legal:demand-draft [slug]

Close with the next-steps decision tree

以下一步决策树收尾

End with the next-steps decision tree per CLAUDE.md
## Outputs
. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.
根据CLAUDE.md
## 输出内容
中的下一步决策树收尾。根据本技能生成的内容自定义选项——五个默认分支(起草X、升级、补充事实、观望、其他)为起点,而非固定选项。决策树为输出内容,由律师选择。

What this skill does not do

本技能不提供的功能

  • Draft the letter. That's
    demand-draft
    — the two steps are intentionally separate so counsel can pause for business input, outside counsel consult, or insurance tender before drafting.
  • Decide whether to send the letter. Some intake sessions end with "actually, don't send — let's negotiate directly." That's a valid outcome; the intake record still has value.
  • Run the conflicts check. If the counterparty is a customer or known entity, flag that this should clear conflicts (per
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    ) before sending — but the check itself lives in the matter-intake workflow or outside this skill.
  • 起草函件。该功能由
    demand-draft
    提供——两个步骤故意分离,以便律师在起草前暂停,获取业务输入、外部律师咨询或保险通知。
  • 决定是否发送函件。部分信息收集会话可能以"实际上不发送——我们直接谈判"收尾。这是有效结果;信息收集记录仍有价值。
  • 进行冲突检查。若对方主体为客户或已知实体,需标记发送前应完成冲突检查(按
    ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md
    要求)——但检查本身属于事项信息收集工作流或本技能之外的流程。