chronology

/chronology

1. Load ~/.claude/plugins/config/claude-for-legal-zh/litigation-legal/matters/[slug]/matter.md → case theory, key facts.
2. Load ~/.claude/plugins/config/claude-for-legal-zh/litigation-legal/CLAUDE.md → document storage sources, default case folder pattern.
3. Follow this workflow.
4. Identify sources in order: paths provided by the user in this session, default case folder, sources declared in configuration.
5. For readable sources: extract dated events. For unreachable sources: note them in the gaps.
6. Deduplicate, merging each event's source list.
7. Mark importance according to the case theory (🔴/🟡/⚪).
8. Write to ~/.claude/plugins/config/claude-for-legal-zh/litigation-legal/matters/[slug]/chronology.md。
9. If a prior version exists: increment the version number, present a diff summary to the user.
10. Confirm before finalizing: "This is what I built. Review the 🔴 entries—is there anywhere I judged incorrectly?"

---

Chronology

Purpose

Facts happen in order. The chronology is the skeleton every narrative depends on—the facts section of a brief, a legal opinion, trial preparation. Building a chronology by hand is slow; AI excels at structured extraction. The point: garbage in, garbage out. This skill extracts from sources declared in configuration and materials uploaded by the user.

Perspective framework (importance labels)

The same event has different importance depending on whether the practitioner is proving a claim or rebutting one:

• Plaintiff/claimant (offensive framework) — 🔴 marksestablishevents that establish the elements of the claim (liability, causation, damages, notice),closeevents that close gaps the other side will try to open, orstartevents that start the limitation period. 🟡 marks events that support the claim but can be challenged. ⚪ is background.
• Defendant/defending party (defensive framework) — 🔴 marksbreakevents that break the elements of the claim (break in causation, absence of notice, absence of reliance),startevents that start a limitation or jurisdiction defense, orsupportevents that support affirmative defenses (release, waiver, comparative fault). 🟡 marks events that weaken the other side's narrative. ⚪ is background.

Load context

• Plugin configuration CLAUDE.md → case theory context,## Outputs get work product header
• Prior chronology.mdfor this case (if any)
• Any files uploaded or provided by the user

Workflow

Step 0: Confidentiality gate (run first every time)

The chronology extracts from files. Files may contain confidential or protected information.

Before extracting: have these sources already been confidentiality-screened?

• A. All sources cleared—you have already screened them. I will extract without confidentiality flags.
• B. Mixed or not yet screened—I will extract and flag each entry.
• C. Stop—screen first— Pause the skill. Filter sources. Go back and re-run.

Step 1: Identify file sources

1. User-provided paths— anything dropped into this session.
2. Default case folder— expanded from the configured file storage mode.
3. Declared sources— sources declared in the configuration.
4. Ask— if sources look insufficient, prompt the user.

Step 2: Extract + read

For each source with readable files:

• PDF, email, docx, txt — read directly.
• If the skill cannot access a declared source, name it explicitly in the gaps section of the output.

Source tagging. Tag each chronology entry with its information source. For any entry that cannot be traced to an extracted file — e.g. facts recalled from model knowledge, publicly recorded events found via web search — tag inline:[联网检索——需复核]、[模型知识——需验证] or [用户提供]. Tags must not be removed or compressed.

Step 3: Extract events

For each file, identify dated events:

• Emails: [日期] [发送人] 告知 [收件人] [主题/内容]
• Meetings: [日期] [参加人] 就 [主题] 开会
• Decisions: [日期] [决策人] 决定 [什么]
• Litigation documents: [日期] [当事人] 提交 [起诉状/答辩状/上诉状]
• External events: [日期] [事情发生](contract signings, product launches, regulatory actions, etc.)

Step 4: Deduplicate

The same event may appear in multiple files — this isan event with multiple sources. Merge. The merged entry cites all sources.

Step 5: Tag importance by case theory

• 🔴 Key— the event is part of the key facts
• 🟡 Relevant— background, pattern evidence, supports a secondary argument
• ⚪ Background— useful for completeness, does not go into the brief

Discipline: 300 🔴 tags out of 300 entries equals no tags. Reserve 🔴 for events that can genuinely move the factfinder.

Step 6: Write

The default output is a working chronology. Provide variants on demand.

Output formats

Working chronology (default)

[工作成果标题]

# 大事记 —— [案件名称]

**案件：** [slug]
**构建日期：** [YYYY-MM-DD]
**来源：** [N] 份文件跨 [来源类型]
**条目：** [N]（[N] 🔴 / [N] 🟡 / [N] ⚪）
**关键事实：** [一句话]

---

## 时间线

| 日期 | 事件 | 标签 | 来源 |
|---|---|---|---|
| [YYYY-MM-DD] | [发生了什么，一句话] | 🔴/🟡/⚪ | [文件路径或编号] |

---

## 关键事件（仅🔴）

[提取出来，每条附一行说明为何对理论重要。]

---

## 缺口

**无事件的日期范围：** [范围]
**预期但缺失：** [我们预期看到但未记录的事件]
**不可读来源：** [已声明但本次无法访问的来源]

---

## 版本
- v[N] 构建于 [日期] 来自 [来源摘要]

Statement of facts chronology (on demand)

Filtered to 🔴 and relevant 🟡. Presented as a chronological prose narrative — the skeleton of the facts section of the brief.

Witness-specific chronology (on demand)

Filtered to events in which a given witness is listed as sender, recipient, attendee, or subject.

What this skill does not do

• Resolve contradictions. When two files say different things about the same event, both entries go in and are flagged. Resolution is the lawyer's judgment.
• Invent events not in the sources. If it is not in the files, it is not in the chronology.
• Guarantee completeness. The chronology is only as good as the sources.