chronology

/chronology

1. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md → 诉讼理论、转折事实、关键事实。
2. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 文档存储来源、默认事项文件夹模式。
3. 按照下方工作流和参考内容操作。
4. 按顺序确定来源：用户在本次会话提供的路径、默认事项文件夹、~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md 中声明的来源。
5. 对可读取的来源：提取有日期的事件。对无法访问的来源：在「缺口」中注明。
6. 去重，并为每个事件合并来源列表。
7. 根据事项诉讼理论标注重要性（🔴/🟡/⚪）。
8. 写入 ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md（或根据标志使用相应的格式变体）。
9. 如果已有先前版本：递增版本号，并向用户展示差异摘要。
10. 定稿前确认：“这是我整理的内容。请检查 🔴 条目——有没有哪些判断不准确？”

---

时间线

披露文件的使用限制

处理一组诉讼文件前，请先询问：“这些文件中是否有通过法律诉讼程序中的披露或证据开示获得的文件？”如果有：

• 英格兰和威尔士（CPR 31.22）： 通过披露获得的文件受默示承诺约束——除非法院许可、披露方同意，或该文件已在公开庭审中宣读，否则只能用于披露该文件的诉讼程序。未经许可，将其用于其他事项、其他索赔或商业目的，属于藐视法庭。
• 美国： 保护令和 Rule 26(c) 可能施加类似限制。请查阅相关命令。
• 其他司法管辖区： 通常也适用类似限制。请查阅当地规定。

请确认：“本次使用属于披露这些文件的诉讼程序，或我已获得许可／同意，或这些文件现已公开。”如果未确认，请标记：“⚠️ 披露文件可能存在使用限制。继续之前，请确认本次使用符合规定。”

目的

事实按顺序发生。时间线是所有叙述所依托的骨架——简报中的事实陈述、准备金备忘录、和解备忘录、证词准备、证人准备。手工整理时间线很慢，而 AI 擅长结构化提取。关键在于：输入垃圾，输出也会是垃圾。这项技能会从配置中声明的来源以及用户上传的内容中提取信息。

模式

这项技能适用于两种执业场景。根据插件配置 CLAUDE.md 中用户的 ## Role 选择默认模式；用户也可以在每次运行时通过标志覆盖默认设置。

• --matter 模式（公司内部诉讼律师的默认模式）。 侧重事项历史。读取事项的案件诉讼理论和关键事实（来自 matter.md），从已声明的文档存储来源中提取信息（Google Drive、SharePoint、Gmail、iManage、CLM——具体取决于 CLAUDE.md 的 ## Landscape 部分），并将 history.md 视为持续更新的内部日志（记录决策、保留通知、准备金备忘录——有意不纳入时间线）。输出以事项为中心：梳理争议期间发生的事情，并标注其在诉讼主张中的用途。
• --documents 模式（律师事务所助理／律师助理的默认模式）。 侧重已提交的文件。读取配置中的案件诉讼理论，然后从电子证据开示导出文件、保管人文件集或带 Bates 编号的文件中提取信息。输出以已提交的文件为中心：说明文件揭示的内容，附上 Bates 引用，并根据案件诉讼理论进行标注。

两种模式最终采用相同的输出结构（时间线、🔴/🟡/⚪ 重要性标签、缺口、SoF 变体）。区别在于来源类型和重要性判断依据。

如果 ## Role 为 solo 或 other，则默认使用 --matter，但首次运行时应介绍两种模式并让用户选择。

侧面框定（重要性标签）

同一事件的重要性会因从业者是在证明还是反驳某项主张而有所不同。请阅读实践配置文件中的 ## Side（如果具体事项覆盖了默认设置，也请阅读该事项的立场）：

• 原告（进攻性框定） — 🔴 标记能够确立主张要件（责任、因果关系、损害、通知）、弥合辩方试图制造的缺口，或对原告有利地启动诉讼时效的事件。🟡 标记支持主张但可能遭到质疑的事件。⚪ 为背景信息。
• 辩方（防御性框定） — 🔴 标记能够破坏主张要件（因果关系、通知、信赖关系不成立）、开启诉讼时效或管辖权抗辩，或支持积极抗辩（免责、弃权、自愿承担风险、比较过失）的事件。🟡 标记削弱原告叙事的事件。⚪ 为背景信息。
• 双方 / 视情况而定 — 请用户针对每份时间线指定应用哪一方的框定来设置重要性标签。底层时间线不区分立场；只有重要性解读会变化。

请在输出顶部注明所应用的框定：Significance tags applied from [plaintiff / defense] perspective. 生成事实陈述变体时，除非用户另有指定，否则使用默认立场。

加载上下文

通用：

• 插件配置 CLAUDE.md → 案件理论上下文（内部律师：文档来源使用 ## Landscape；律所助理：平台和保管人使用 ## Case theory 和 ## Document review）、工作成果标题使用 ## Outputs、特权标记规则使用 ## Decision posture。
• 如果存在本事项的先前 chronology.md。
• 用户上传的任何文件，或用户在本次会话中提供的路径。

--matter 模式还会读取：

• ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md → 案件理论、关键事实、转折事实（用于重要性标记）、关键日期。
• CLAUDE.md 中的默认事项文件夹模式 → 此 slug 对应的文档所在位置。

--documents 模式还会读取：

• 如果连接器可用，则读取电子取证平台元数据（Everlaw、Relativity、DISCO、Aurora）——按保管人和日期范围筛选。
• 如果用户指定 Bates 编号范围清单或制作索引，则读取相应内容。

冲突审查关卡——不可绕过（--matter 模式）。 在编制时间线之前，检查 ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml 中是否有该事项的 slug。如果 _log.yaml 中没有该事项，请拒绝并转交：

"I don't see [matter slug] in the matter log. Run /litigation-legal:matter-intake first so the conflicts check runs and the matter workspace is set up. I won't build a chronology on a matter that hasn't been intaken — the conflicts check is the gate."

不得继续处理尚未完成接收的事项。事项接收会执行冲突审查，并写入此技能所读取的 _log.yaml 行。--documents 模式（针对没有事项 slug 的临时文档集运行）不受此关卡限制，但其输出应视为事项建立前的研究成果，不得作为事项工作成果归档。

工作流

步骤 0：特权门控（每次运行时首先执行）

编制时间线会从文档中提取信息。文档通常受特权保护（律师—客户特权、工作成果、共同利益、联合辩护）——内部案件文件通常默认受保护；电子取证制作材料，尤其是分批制作或共同利益制作材料，也常包含受特权保护或尚未审查的内容。从受特权保护的文档中提取内容，放入之后会共享的时间线，可能导致特权放弃；具体取决于接收对象以及适用的法律原则（共同利益、联合辩护、Kovel 和工作成果保护可能适用）。特权放弃分析因具体事实而异——分发前应取得律师批准。

在用户选择特权处理方式前，此技能不会提取内容：

开始提取前：来源经过了怎样的特权审查？

• A. 所有来源均已排除特权问题 — 你已完成筛查。我会提取内容，不添加特权标记。输出采用可用于证据开示的处理方式；但仍标记为工作成果。

• B. 来源混杂或尚未筛查 — 我会提取内容，并为每条记录添加 priv 标记：ok（来源明确不受特权保护）、flag（来源可能受特权保护——律师—客户特权、工作成果或共同利益）或 review（来源不明确）。输出中会以视觉方式标记相关记录；事实陈述版本默认会将其过滤掉。

• C. 取消——先进行筛查 — 暂停此技能。先筛查来源，然后返回并重新运行。

在时间线标题中将选择记录为 privilege_posture: A-cleared | B-mixed | C-aborted。如果选择 B 或 C，请简要记录理由。

**为什么要设置门控，而不只是发出警告：**警告看过一次就容易被忘记。门控会将处理方式决定纳入记录，这意味着每个时间线文件都带有自己的来源信息——之后阅读的人都能知道记录是否源自经过特权筛查的材料。

步骤 1：识别文档来源

--matter 模式：

1. 用户提供的路径 — 本次会话中提供的所有内容（文件路径、云盘链接、电子邮件导出文件）。
2. 默认案件文件夹 — 根据 CLAUDE.md 中的文档存储模式，为此 slug 展开路径（例如，G:/Legal/Matters/acme-v-us-2026）。
3. 已声明的来源 — CLAUDE.md 中的 Document storage 表格，筛选出此案件可能涉及的来源（例如，发件方通信的 Gmail 存档、SharePoint 法律文件夹）。
4. 询问 — 如果来源看起来不够全面，请提示：“我可以根据现有材料编制，但时间线会不完整。还有其他材料可以提供给我吗？例如关键电子邮件、合同、内部备忘录或制作函？”

--documents 模式：

1. 制作材料导出文件／Bates 编号集 — 用户指定制作文件目录或清单；技能按 Bates 编号范围和日期读取。
2. 电子取证连接器 — 如果有 MCP 连接器可用（Everlaw、Relativity、DISCO、Aurora），则按保管人和日期范围提取。
3. 保管人文件 — 如果用户提供原始保管人邮箱或云盘导出文件，也读取这些材料。
4. 询问 — 如果关键保管人或日期范围的覆盖看起来不够全面，请提示用户。

步骤 2：提取并阅读

对于包含可读取文件的每个来源：

• PDF、电子邮件（.eml）、.docx、.txt — 直接阅读。
• 电子邮件存档（Gmail、Outlook） — 如果 MCP 连接器已通过身份验证，则按日期范围和对方 / 关键术语查询；否则由用户将相关邮件线程导出到文件夹。
• 电子取证平台（Everlaw、Relativity、DISCO、Aurora） — 如果有可用的连接器，则按保管人和日期范围提取；否则由用户提供导出文件。

如果该技能无法访问已声明的来源，请在输出的 Gaps 部分明确列出该来源，而不是默默继续。

不得默默补充。 如果某一阶段的案件来源覆盖不足——文档数量少于所称时间窗口的预期、无法访问某位保管人的邮箱、尚未收到某批制作材料——请报告已找到的内容并停止。未经询问，不得通过网络搜索、公开记录搜索或模型对该案件的了解来填补空白。请这样说：“来源为 [period / custodian] 返回了 [N] 个事件。覆盖范围似乎不足。可选方案：(1) 指引我查阅其他来源（Bates 编号、文件夹、邮箱），(2) 如果已配置其他 MCP 连接器，则尝试使用该连接器，(3) 搜索网络以查找此时间段内的公开记录事件——结果会标记为 [web search — verify]，依赖前应与一手来源核对，或 (4) 到此为止并注明缺口。您希望如何处理？” 律师决定是否接受置信度较低的来源；该技能不替他们作决定。

来源归属。 为每条时间线记录标注事件来源：对于从已检索文档中提取的事件，注明文件路径、Bates 编号、MCP 连接器或已声明的文档存储来源（这些信息已记录在 Sources 列中）。对于任何无法追溯到已检索文档的事件或日期——例如从模型训练数据中回忆的事实、通过网络搜索发现的公开记录事件——请在行内标注：[web search — verify]、[model knowledge — verify] 或用户在当前会话中陈述事实时使用 [user provided]。标记为 verify 的记录比来源于文档的记录更容易出现编造，应优先核查。绝不要删除或合并这些标记——这是律师在将记录纳入诉状或 SoF 前，快速识别哪些内容需要核查的最佳方式。

凡是陈述法律结论、期限或计算日期的部分，都必须标注来源——不只是时间线记录。 时间线依据文档来源。Gaps 部分、Key events 部分、Theory tie lines，以及任何有关时效限制、中止时效事件、诉讼时限、证据开示截止日期或特权认定的陈述，都是该技能根据模型知识撰写的法律分析，除非另有来源。每一项此类陈述都必须带有来源标记：[computed from: <rule cited with tag>]、[model knowledge — verify]、[user provided]，或者本次会话中检索到的研究连接器标记。未标注来源的诉讼时效期限，默认标记为 [model knowledge — verify]。描述事实法律意义的“关键事件”记录属于分析，也必须带有来源标记。规则很简单：如果陈述的是法律，而不是文档内容，就必须像时间线记录一样带有来源标记。如果无法连接研究连接器，而该技能正在计算期限或引用规则，请将其记录在审阅者备注的 Sources: 行中（参见插件 CLAUDE.md 的 ## Outputs）——不要单独输出横幅。

步骤 3：提取事件

对于每份文档，识别有日期的事件：

• 电子邮件：[date] [sender] told [recipient] [subject/content]
• 会议：[date] [attendees] met about [topic]（根据日历条目或笔记）
• 决定：[date] [decision-maker] decided [what]（根据记录决定的文档）
• 文件提交／诉状：[date] [party] filed [motion/complaint/response]
• 外部事件：[date] [thing happened]（签署合同、产品发布、监管机构采取行动、事件达到某个门槛）

通常每份文档对应一个事件。偶尔为零个（无日期或无法确定事件）。有时会有多个（涵盖数项决定的会议摘要）。

仅当 privilege_posture == B-mixed 时，才为每条目标注特权状态。三状态规则——绝不默默判定某项主观特权测试不成立：

• priv: ok — 明确可确认来源不受特权保护（诉状、监管往来、公开文档、不涉及我方律师的对方当事人通信）。仅在不存在合理特权依据时使用。
• priv: flag — 明确或很可能受特权保护的来源（与律师的通信、工作成果备忘录、受特权保护的草稿、共同抗辩材料）。任何不确定的情况都默认归入此类——如果主要目的的判断较难，或对是否已开始考虑诉讼存在疑问，或内容混杂，则应归入此类，而不是 ok。
• priv: review — 来源表面上不明确，且该技能完全无法判断（没有发件人／收件人元数据、内容无法读取等）。

标记为 priv: flag 或 priv: review 时，内联添加 [SME VERIFY: privilege status]，以便律师在审阅时看到。标记不足会导致特权被放弃（单向门）；标记过多可由律师在审阅时更正（双向门）。优先选择可补救的错误。

步骤 4：去重

同一事件会出现在多份文档中：一次会议出现在三份日历中，并生成了一封摘要邮件——这是一条事件，四个来源，而不是四条事件。合并。合并后的条目应引用所有来源。

步骤 5：按重要性标注——根据案件理论

阅读 matter.md 中的转折事实和关键事实（--matter 模式），或配置文件中 ## Case theory 部分的内容（--documents 模式）。为每个事件标注：

• 🔴 关键 — 事件是转折事实或对我方有利／不利的关键事实之一
• 🟡 相关 — 背景信息、模式证据，或支持次要论点
• ⚪ 背景 — 有助于完整呈现，但不会写入案情摘要

**把握尺度：**一份有 300 条记录且 300 条都标为 🔴 的时间线，等于没有标注。🔴 应仅用于真正会影响事实认定者判断的事件。如有疑问，标为 🟡。

**临界情况的标注：**当条目介于 🔴 和 🟡（或 🟡 和 ⚪）之间时，按较低的重要性标注，并内联添加 [SME VERIFY — borderline significance call]。律师的判断将取代该技能的判断。自信地过度标注，不如明确呈现不确定性有用。

步骤 6：撰写

默认输出为工作时间线。可按要求提供其他版本。

输出格式

工作时间线（默认）

位置：~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md。内容完整、带有标注和注释，是律师工作的参考文档。

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> **Privilege inheritance.** This chronology is derived from matter documents that may be attorney-client-privileged, work-product-protected, common-interest / joint-defense material, or a mix. It inherits the sources' protection status. Distributing it beyond the privilege circle — to business stakeholders outside the engagement, to opposing counsel, to a regulator — can waive protection over both the chronology and the underlying sources. Store with privileged matter material, mark consistently with house privilege conventions, and make distribution decisions deliberately. The privilege-posture choice captured below is the provenance stamp for any later distribution call.

# Chronology — [Matter Name]

> Significance tags (🔴/🟡/⚪) and privilege flags (🔒) are first-pass reads requiring `[SME VERIFY]` before use in any external work product (briefs, SoF, board memo, outside counsel deliverable).

**Matter:** [slug]
**Mode:** matter | documents
**Built:** [YYYY-MM-DD]
**Sources:** [N] documents across [source types]
**Entries:** [N] ([N] 🔴 / [N] 🟡 / [N] ⚪)
**Pivot fact:** [one sentence]
**Privilege posture:** A-cleared | B-mixed | C-aborted
**Flagged entries:** [N] 🔒 *(only present when posture == B-mixed)*

---

## Timeline

| Date | Event | Tag | 🔒 | Sources |
|---|---|---|---|---|
| [YYYY-MM-DD] | [what happened, one sentence] | 🔴/🟡/⚪ | [blank / 🔒-flag / 🔒-review] | [file paths or Bates] |

---

## Key events (🔴 only)

[Pulled out, each with a line on why it matters to the theory.]

### [date] — [event title]
- What: [one line]
- Theory tie: [why this matters]
- Sources: [list]

---

## Gaps

**Date ranges with no events:**
[ranges — where are documents for this period?]

**Expected but missing:**
[events we'd expect to see documented but don't — e.g., "contract amendments between 2024-06 and 2025-03 — not produced"]

**Unreadable sources:**
[sources declared in CLAUDE.md but not accessible this run — e.g., "Everlaw production — no MCP connector; export needed"]

---

## Marker discipline

- `[VERIFY: factual assertion — date, attendees, content]` — not yet confirmed against the underlying doc
- `[UNCERTAIN: legal characterization — e.g., whether an event establishes a regulatory trigger]`
- `[CITE NEEDED: Bates / exhibit / depo page:line]`
- `[SME VERIFY: privilege status | borderline significance call]` — counsel judgment needed

---

## Version
- v[N] built on [date] from [source summary]
- v[N-1] built on [date] (prior, superseded)

事实陈述时间线（按要求提供）

仅保留 🔴 和相关的 🟡 条目。按时间顺序以叙述体呈现，作为诉状事实部分的框架。每段对应一个事件或紧密关联的一组事件，并附上案卷引用。

特权过滤默认规则：当 privilege_posture == B-mixed 时，默认排除标记为 🔒-flag 和 🔒-review 的条目。事实陈述版本旨在供最终对外使用（诉状、披露、与对方当事人谈判）——在律师确认特权状态前，🔒 条目不应出现在其中。如果用户仍希望纳入 🔒 条目，必须明确确认使用 --include-flagged；并在输出标题中记录该确认，作为永久记录。

针对特定证人的时间线（按需）

筛选具名证人作为发件人、收件人、出席者或事件对象的事件。用于准备证人作证，并帮助还原证人当时掌握的信息。

增量构建

如果存在 chronology.md：

• 读取上一版本
• 根据当前来源构建新的时间线
• 比较差异：新增事件（自上次构建以来）、修改的条目（为现有事件添加了新来源）、已删除的条目（少见；说明原因）
• 保留上一版本号；新版本使用 v[N+1]
• 输出变更摘要

与 matter.md / history.md 集成

有意分开（内部 --matter 模式）。history.md 是律师的持续记录，涵盖决策、更新、程序性里程碑和内部策略备注。chronology.md 是面向诉讼工作的事实时间线。两者内容有所重叠，但不应合并：

• 发出了证据保全通知 → 记入 history.md（内部行动）。通常不记入 chronology（并非争议事实）。
• 对方于 3 月 14 日发出违约通知 → 记入 chronology.md（🟡 — 可确立对方的知情情况）。如果接收材料中提到了该通知，也记入 history.md。
• 我方起草了准备金建议备忘录 → 仅记入 history.md。

如果律师希望将 history 中的事件纳入 chronology，可以自行粘贴。默认情况下，两者保持分开。

此技能不会做什么

• 解决矛盾。 如果两份文件对事件发生时间说法不一，则将两条记录都纳入并添加标记。是否解决由律师决定；可能需要访谈证人或进一步取证。
• 编造来源中没有的事件。 如果文件中没有相关信息（且 matter.md 或配置中也没有记录该事实），就不会将其纳入时间线；但“缺口”部分可能会指出相关信息缺失。
• 保证完整性。 时间线的质量取决于来源质量。如果电子取证材料仍在持续提供，且目前仅收到 20%，时间线就会反映这一情况。应注明这一限制。
• 替用户判定特权状态。 Step 0 会要求选择处理立场；每条记录的 priv 标记用于初步分类。实际特权认定由律师负责，具体见 [SME VERIFY] 标记。