李律师是上海的一名民商事诉讼律师，代理了一起货款纠纷案：苏州某制造企业被供应商拖欠120万货款，谈判僵持三个月，现在需要正式发一封催告函施压，同时为后续起诉做准备。
从律师函到立案，这件事涉及多个步骤：信息采集、策略研判、函件起草、证据保全、时间线整理、最终出庭准备。每一步都可以用 AI 辅助。但问题不是"Claude能不能做"，而是"一套法律 AI 插件是如何把这些步骤组织起来的，每个步骤里又藏着多少层设计"。
Anthropic出品的 claude-for-legal 的诉讼插件（litigation-legal）是一个可以回答这个问题的具体例子。我们来拆开来看。
一个插件不只是一堆文件
litigation-legal 的目录结构大概是这样的：
litigation-legal/
├── CLAUDE.md ← 执业档案，插件的"大脑"
├── .mcp.json ← 7个外部连接器声明
├── skills/ ← 20个技能文件
│ ├── demand-intake/
│ │ └── SKILL.md
│ ├── demand-draft/
│ │ └── SKILL.md
│ ├── matter-intake/
│ │ └── SKILL.md
│ ├── claim-chart/
│ │ ├── SKILL.md
│ │ └── references/
│ │ └── element-templates.md ← 外置知识库
│ └── chronology/
│ └── SKILL.md
├── agents/
│ └── docket-watcher.md ← 后台守夜的 Agent
├── matters/
│ ├── _log.yaml ← 案件台账
│ └── _README.md
└── demand-letters/ ← 催告函数据目录
└── _README.md
CLAUDE.md 是持久化的执业档案，所有 Skill 启动时都先读它——事务所风险标准、当事方立场、风格规范，问一次，到处用。 skills/ 里每一个 SKILL.md 是一个可独立触发的技能单元。 references/ 是某些 Skill 的外置知识库，知识和流程分开放，各自迭代。 agents/ 里跑着后台自动任务。 .mcp.json 声明了插件能访问的外部系统。
demand-draft：最值得解剖的那个 Skill
demand-draft 是催告函起草，有350行，是这套体系里流程控制最密集的 Skill 之一。它的复杂性不在于代码，而在于它把"一个律师在起草函件前应该想清楚的所有事情"全部变成了可执行的检查节点。
先看它最顶部的 YAML frontmatter：
name: demand-draft
description: Draft a demand letter from a completed intake, gated on a privilege /
FRE 408 / waiver / admission checklist, with a .docx output, post-send checklist,
and an offer to create a matter. Use when the user says "draft the demand",
"write the [type] letter", or has a finished demand intake ready to turn into
a sendable draft.
argument-hint: "[slug] [--skip-gate] [--version=N]"
三行 YAML 做了三件事：告诉系统这个 Skill 叫什么、什么时候触发、支持哪些参数。 argument-hint 里的 --skip-gate 意味着理论上可以跳过安全检查，但我们后面会看到，即使用了这个参数，系统也会在草稿文件里留下一条"前置门已跳过"的永久记录。跳不干净。
YAML 下面是 9 步执行序列，相当于 Skill 的目录：
加载案件信息文件（ intake.md ）——不存在则拒绝执行
加载执业档案（ CLAUDE.md ）——读取风险标准、种子文档路径、风格规范
检查策略块是否完整——缺失则警告并询问
运行前置门（7项强制检查）——全部确认才能继续
选择模板——种子文档优先，其次软骨架
在对话中生成草稿——用户审改直至确认
将确认版本写入 .docx 文件
写入 checklist.md （发送前后的操作清单）
评估案件是否达到立案标准，如果是则移交 matter-intake
这 9 步只是目录。每一步背后展开来才是真正的设计。
进门检查：第一道硬拦截
Skill 的第一步是找 intake.md 。这个文件是上一个 Skill demand-intake 写入的，包含了当事人信息、案件事实、金额、证据材料、诉求。
文件不存在， demand-draft 直接停止，没有退路。
李律师必须先走 /demand-intake 把苏州制造企业案的基本情况录入AI，才能触发 /demand-draft 。这不是提示，是硬性前置条件。
策略块检查：透明的降级
demand-intake 录入时有一块"策略块"，包含杠杆分析、最坏情况预案（BATNA）、特权过滤。可以跳过，但不能静默跳过。
如果李律师当时选择了跳过策略块， intake.md 里会写入：
strategic_block: skipped
skipped_reason: "时间紧，先走核心信息"
demand-draft 读到这个标记不会假装没看见，而是先停下来问：草稿里策略相关的部分将全部打上 [SME VERIFY] 标记，你要现在回去补填，还是就这样继续？选择继续，每一处依赖策略信息的段落都带着这个标记，直到律师手动确认。
前置门：7项强制检查
这是 demand-draft 最核心的设计。7项检查，每项都需要律师真实作答，没有"全部同意"按钮：
特权过滤： 草稿里有没有会暴露我方内部法律分析的句子？
自认风险： 函件里有没有可能被对方拿来当"你方自认"的表述？
和解条款问题： 这封函有没有可能"意外满足"了对方的另一项主张？
和解通信定性： 函件的结构和措辞，与预定的证据规则保护定性是否一致？ 保护来自行为和语境，不仅来自标签。
特权放弃扫描： 有没有句子会透露我方内部分析的实质，而不只是结论？
语气定调： 关系维护型、稳健型，还是强硬型？ 这决定整篇草稿的动词选择和后果语言。
事实核实： 哪些事实已核实，哪些没有？ 未核实的每一处都打 [VERIFY: ___] 。
对于李律师的案子，这意味着他在"写催告函"之前，必须先想清楚：这封函算不算和解通信？谁来签、什么语气？有没有句子会让对方拿来当证据反打？如果对方完全不回，下一步是什么？
系统在这里说了一句很直接的话：一份走了流程但没有实质作答的清单，比没有清单还危险。
references：Skill 的外置知识库
claim-chart （诉讼要素图）的目录里有一个 references/ 文件夹，里面只有一个文件： element-templates.md 。
这个文件是什么？60多种常见诉因和抗辩事由的构成要件清单——违约、过失侵权、不当得利、商业秘密、专利侵权、欺诈……每一种诉因列出"根据《第二次合同法重述》/CACI陪审指引"的要素基线，以及管辖区差异的注意事项。
把这些知识放在单独的 references/ 文件而不是直接写进 SKILL.md，有两个原因。 element-templates.md 需要随法律更新而迭代，Skill 的执行逻辑不需要跟着动。另外，Skill 用这个文件时不是直接用，而是先呈现给用户确认：你的法域有没有增删或改写？文件开头就写清楚了——这是基线，不是控制性法律，你的法域永远优先。
对于李律师的案子，到诉讼阶段需要整理要素表时， claim-chart 从 element-templates.md 读取合同违约的基线要素（合同成立、我方履行或免责事由、对方违约、因果关系、损害赔偿），然后逐项问他：目前的证据材料里，哪些要素有支撑，哪些是缺口，缺口能不能通过后续取证填补？输出是一张 Excel，每格标注来源。
数据层：谁写、谁读、谁传给谁
理解一套 Skill 系统，看数据流动最直接：
_log.yaml 是整个系统的案件台账，记录每个案件的ID、类型、当事方立场、管辖地、状态、冲突检查结果、风险评级、内部负责人、关键日期……
这个台账有一个副产品： claim-chart 和 chronology 在开始工作前，都会先查台账，确认这个案件是否已经走过冲突检查。没有的话，直接拒绝，让你先去走 matter-intake 。这是一道贯穿所有 Skill 的门，没法绕过。
六个命令，一条完整的线
这些组件怎么配合，在李律师的案子上最清楚。
第一次用插件时先走 /cold-start-interview 。系统问：律所律师、企业内法还是个人执业？主要代理原告方还是被告方？风险标准是什么？上海的法院诉讼最常走哪几个？李律师的回答写进 CLAUDE.md ，这步只走一次，之后每个 Skill 启动时自己去读，不再重复询问。
然后是 /demand-intake 苏州货款案-2026 。谁发、发给谁、什么类型的函，金额多少，法律依据在哪，以前有没有非正式沟通，语气是强硬还是给对方台阶下。120万触发了"实质性"阈值，系统追问策略块：谈判底线是什么？如果对方不回函，真的准备起诉吗？李律师说没时间细聊，选择跳过，系统记录在案，继续走。
接着 /demand-draft 苏州货款案-2026 。7项前置检查，逐一确认。通过之后，系统找到李律师在 CLAUDE.md 里提供的以前发过的货款催告函样本——种子文档——匹配格式和语气，生成草稿。凡是需要引用具体法律条文的地方，全部留 [CITE: 合同法第xxx条] 占位符，不自动填充。草稿末尾附上一段只有律师能看到的提示：这是草稿，未经持牌律师最终确认不得发送。
对方在14天期限内没有任何回应。李律师决定立案，走 /matter-intake 苏州货款案-2026 ：冲突检查结果、风险评级、保全通知是否发出。案件写入 _log.yaml ， matter.md 创建。 demand-draft 完成时已经评估过立案标准，预填了大部分字段，李律师只需要确认。
/chronology 苏州货款案-2026 ：合同、发票、往来邮件、微信记录截图、银行流水一并上传或给出路径。系统提取每一个有日期的事件——签约、交货、开票、付款逾期、多次催收——按原告视角打上重要性标记（🔴 锁定违约要件；🟡 支持诉求但可能受到质疑；⚪ 背景信息）。时间线输出为 chronology.md ，以后每次有新文件加入增量更新，版本号递增，保留每个版本。
最后 /claim-chart --civil --count 合同违约 苏州货款案-2026 ：从 element-templates.md 读取合同违约的基线要素，在证据材料里逐项映射，每个要素标注来源文件和页码，缺口列明。
立案之后，docket-watcher 自动开始轮询相关法院的案件系统，有新的文书送达、开庭通知、裁定下达立刻推送到 Slack。距开庭14天内有重要交付物还没准备好，🔴标记。这个 Agent 一直在后台跑，不需要李律师触发。
往期相关内容回顾
法律人学Claude｜第一期：桌面版已经很好用了，为什么我还是力推 VSCode 插件版？
法律人学Claude｜第二期：半小时装好 VSCode + Claude Code
法律人学Claude｜第四期：你的项目助理—CLAUDE.md使用指南