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 に引き継ぎます。

---

請求書の草稿作成

目的

記入済みの受付情報を基に、送付可能な草稿を作成します。この作業の価値の大半は、秘匿特権、権利放棄、認諾、和解に関するコミュニケーションの位置付けを慎重に確認するまで、草稿作成に着手しないことにあります。誰も立ち止まって確認しなかった結果、秘匿特権を放棄したり、認諾を構成したりする書簡になってしまうことが、避けるべき失敗です。

記録の忠実な反映 — 引用とピンポイント引用

請求書は主張を提示する文書です。契約書、メール、過去のやり取りから引用した一文一文が、相手方に検証される主張になります。プラグインの CLAUDE.md にある共通のガードレールの基本方針を、ここでも繰り返します。

逐語引用は一字一句そのままでなければなりません。 相手方、その代理人、証人、または文書に帰属させる文言は、実際の該当箇所を目の前で確認できない限り、決して引用符で囲まないでください。正確な文言を確認せずに内容を説明する場合は、次のようにします。

• 引用符を使わずに言い換え、プレースホルダーを付けます。「貴社の[日付]のメールには X と記載されていました [正確な引用を確認 — メールの引用箇所は未確認]」
• 空白を推測で埋めないでください。 請求書で契約条項を誤って引用することは、最初のやり取りで相手方の代理人からの信用を失う最も手っ取り早い方法です。
• [verify exact quote] はすべて、書簡を送付する前にレビュアー向けの注記で明示してください。

ピンポイント引用は、主張全体を裏付けるものでなければなりません。 請求で「第4.2条により、請求書の受領後30日以内の支払いが義務付けられています」と主張するなら、引用した条項が義務、支払いの起算点、期間のすべてを裏付けている必要があります。一部しか裏付けていない場合は、引用箇所を分ける（例：「第4.2条（支払義務）；第4.3条（30日の期間）」）か、主張の範囲を狭めてください。請求の一部しか裏付けない契約条項を引用すると、相手方が全文を示して立場を逆転させることになります。

弱い主張について率直に伝える

法律または記録が主張に不利な場合、それを確かな主張であるかのように装わないでください。請求書の主張が弱い場合（契約文言が曖昧、法的根拠が逆の結論を示す、損害賠償の理論に無理があるなど）は、送付者にその旨を伝えてください。

「ここでの[請求／理論]は、[法的根拠／事実]により弱いものです。選択肢：（a）[別の表現方法] として構成し、主張を続ける、（b）その主張を取り下げ、[より強い請求]に基づく、（c）足掛かりとして残しつつ、断定を避ける。[要確認 — 戦略上の判断]」

主張しすぎる請求書を送ると、相手方は行き過ぎた主張を一つ残らず列挙する回答を送り、交渉上の優位性を逆転させ、次のやり取りの機会を損ないます。最も強い請求書とは、弱い点を認めることで、相手方にそこを突かせないものです。

エコーと繰り返し

本件に関する過去のやり取りがある場合は、主要な用語を踏襲してください。すなわち、違反の性質を同じように表現し、中核となる義務を同じように位置づけ、取引を同じ名称で呼びます。文全体をそのまま流用してはいけません。以前の文書をコピー＆ペーストしたような要求書では、何も変わっていないという印象を与えます。新しい書簡では、同じ内容を繰り返すのではなく、新たな事実、新たな期限、新たな結果などを示して、交渉上の立場を前進させてください。

外部向け成果物： 作成した要求書は相手方に送付します。送付する書簡に 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」の表示は必要ですか？（和解に関する連絡には付けますが、請求の主張には付けないことが多く、法域によって異なります。不明な場合は確認してください）
• 署名者： あなた、クライアント、法務責任者（GC）、指示を受けた弁護士の誰ですか？ 推測してはいけません。本件ファイルに過去の要求書に関するやり取りがある場合は確認してください。文書の文体や調子を把握できます。

回答内容によって、動詞の選択を含む口調、結果を示す表現、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. に基づく複数回の商品引渡し契約（複数の出荷、ロット、または期間をおいて行われる引渡し）に関する契約違反の請求では、§ 2-601 の完全履行ルールや § 2-711 の単回引渡しにおける買主救済の枠組みではなく、分割履行契約の枠組みである U.C.C. § 2-612 の「当該分割履行分の価値を実質的に損なうこと」をデフォルトとして適用します。

§ 2-601 の完全履行ルールは、単回引渡しの商品契約には適切に適用されます。しかし、§ 2-612 によってルールが変更される分割履行契約には、そのまま適用できません。不適合が当該分割履行分の価値を実質的に損ない、かつ是正できない場合に限り、買主は不適合の分割履行分を拒絶できます。また、不適合が契約全体の価値を実質的に損なう場合に限り、契約全体が違反されたものとして扱うことができます。

複数ロットの商品に関する契約違反の請求書を作成する際は、次のとおりとします。

• § 2-601 ではなく、主たる枠組みとして [CITE: U.C.C. § 2-612 — installment contracts; substantial impairment of the installment] を引用します。
• § 2-711 および § 2-712（代替購入）は契約違反から生じる救済として引用しますが、契約違反の基準は § 2-612 の用語で記載します。
• ドラフトの上にある [SIGNER NOTE:] ブロックで、署名者に次の点を明示します。「本書は U.C.C. § 2-612（分割履行契約）に基づいて作成されており、§ 2-601（完全履行ルール）に基づくものではありません。この2つでは契約違反の基準が大きく異なります。送付前に、契約の引渡し構造が分割履行契約としての分類を裏付けることを確認してください。」
• インテーク情報から契約の引渡し構造が不明な場合（例：「3ロットが引き渡された」とあるものの、契約でロットごとの個別引渡しが定められていたのか、便宜上1回の出荷をロットに分けたのかが確認できない場合）は、[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 の請求書を支払っていません。]

6. 意図しない限り、記録上の和解協議を含めません。 インテークで、当該法域では本通信に和解協議としての保護が適用されないと示されている場合、ドラフトには和解の申し出、「without prejudice」とする文言、または和解協議と見なされる可能性のある表現を含めません。保護の適用は行為や状況によって決まり、単にラベルを付けても問題は解消されないことに留意してください。

7. 社内スタイルに従って秘匿特権の表示を行います。 秘匿特権に関する規則は ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md に厳密に従います。

出力

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

docx スキルを使用して、書簡形式の .docx を作成します。

• レターヘッド／差出人住所ブロック
• 日付
• 受取人住所ブロック
• Re: の行（簡潔にし、秘匿特権のある戦略を明かさない）
• 宛名
• 本文（テンプレートと起草ルールに従う）
• 結び
• インテークに基づく署名ブロック

チャット内での確認

ユーザーが確認して編集を依頼できるよう、ドラフトを読みやすいプレーンテキストで表示します。最終版の .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.

Matter の自動作成の提案

チェックリストの下書きを作成して記入した後、次のヒューリスティックに基づいて重要性を評価します。

• 以下のいずれかに該当する場合、デフォルトで「はい」：
  • 要求の種類が cease-desist、breach-cure、employment-separation、または preservation
  • 希望する結果の $$ ≥ ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md の中程度の重大度の基準
  • ランドスケープ上、相手方が顧客、競合他社、または頻繁に対立する相手方
• それ以外の場合はデフォルトで「いいえ」

次のように確認します。

重要性のヒューリスティック：［結果］。［理由を1文で記載。］ ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml に追跡対象の Matter を作成しますか？（デフォルト：［はい／いいえ］）

ユーザーが承諾した場合：インテークの情報（相手方、種類、管轄区域、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 に戻るよう案内します。下書きの品質は、読み取る情報の品質に左右されます。
• 重要性の判断。 ヒューリスティックがデフォルトを提示しますが、ユーザーの判断が記録となります。