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 は構造化された抽出を得意としています。注意点は、入力が悪ければ出力も悪くなることです。このスキルは、設定で宣言された情報源と、ユーザーがアップロードしたものから情報を取得します。

モード

このスキルは、2 つの業務環境に対応します。プラグイン設定の CLAUDE.md にあるユーザーの ## Role に基づいてデフォルトを選択します。ユーザーは実行ごとにフラグで変更できます。

• --matter モード（企業内訴訟担当弁護士のデフォルト）。 案件の経緯を中心に扱います。matter.md から案件の訴訟理論と重要な事実を読み込み、宣言された文書保管元（Google Drive、SharePoint、Gmail、iManage、CLM など、CLAUDE.md の ## Landscape セクションで宣言されているもの）から情報を取得します。history.md は、継続的に記録する内部ログ（判断、保留、引当金メモなど。意図的に年表には含めません）として扱います。出力は案件中心で、紛争全体で何が起きたかを、主張立証での使用に備えて重要度を付けて示します。
• --documents モード（法律事務所のアソシエイト／パラリーガルのデフォルト）。 文書の提出を中心に扱います。設定から訴訟理論を読み込み、eDiscovery のエクスポート、カストディアンのファイル一式、または 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 に定められたデフォルトの案件フォルダーの形式 → このスラッグの文書の保存場所。

--documents モードでは、以下も読み込みます：

• コネクタが利用可能な場合は、eDiscovery プラットフォームのメタデータ（Everlaw、Relativity、DISCO、Aurora）— 保管担当者別、日付範囲別。
• ユーザーが指定した場合は、Bates 番号の範囲を示すマニフェストまたはプロダクションインデックス。

コンフリクト確認ゲート — 回避不可（--matter モード）。 年表を作成する前に、案件のスラッグが ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml にあるか確認してください。案件が _log.yaml にない場合は、作業を拒否し、次のように案内してください：

「案件ログに [matter slug] が見つかりません。まず /litigation-legal:matter-intake を実行して、コンフリクト確認を行い、案件のワークスペースを設定してください。インテークされていない案件の年表は作成しません。コンフリクト確認は必須のゲートです。」

インテークされていない案件について作業を進めないでください。インテークによってコンフリクト確認が実行され、このスキルが参照する _log.yaml の行が作成されます。--documents モード（案件スラッグを指定せず、アドホックな文書セットを対象に実行する場合）はこのゲートの対象外ですが、その出力は案件化前の調査資料として扱い、案件の成果物であるかのように提出してはいけません。

ワークフロー

ステップ 0：特権に関するゲート（毎回、最初に実行）

時系列の作成では、文書を参照します。文書には特権の対象となるもの（弁護士・依頼者間、ワークプロダクト、共通利益、共同弁護）が含まれることがよくあります。社内案件のファイルは多くの場合、原則として特権の対象です。eDiscovery のプロダクション、特に段階的なプロダクションや共通利益に基づくプロダクションには、特権の対象となる資料や未レビューの資料が含まれていることがよくあります。特権の対象となる文書の内容を、後に共有される時系列に抽出すると、受領者や適用される法理（共通利益、共同弁護、Kovel、ワークプロダクト保護）によっては、特権放棄のリスクが生じる可能性があります。特権放棄の分析は事実関係によって異なるため、配布前に弁護士の承認を得てください。

ユーザーが特権に関する方針を選択するまで、このスキルは抽出を行いません。

抽出する前に、ソースの特権チェックはどのように行われていますか？

• A. すべてのソースの確認済み — すでに確認済みです。特権フラグを付けずに抽出します。出力はディスカバリー対応の方針ですが、ワークプロダクトであることは引き続き明記されます。

• B. 混在または未確認 — すべてのエントリに priv フラグを付けて抽出します。ok（明らかに特権の対象ではない資料から取得）、flag（特権の対象である可能性がある資料（A/C、WP、共通利益）から取得）、または review（ソースが不明）を設定します。フラグ付きのエントリは出力内で視覚的に示され、Statement-of-Facts 版ではデフォルトで除外されます。

• C. 中止 — 先に確認 — スキルを一時停止します。ソースを確認してから戻り、再実行してください。

選択内容を、時系列のヘッダーに privilege_posture: A-cleared | B-mixed | C-aborted として記録してください。B または C を選んだ場合は、理由も簡潔に記録してください。

警告ではなくゲートを設ける理由： 警告は一度読まれた後、忘れられてしまいます。ゲートを設けることで、方針の選択が記録に残ります。そのため、各時系列ファイルにはそれ自体の出所情報が含まれ、後で読む人も、エントリが特権チェック済みの資料から作成されたものかどうかを確認できます。

ステップ 1：文書ソースを特定する

--matter モード：

1. ユーザーが指定したパス — このセッションで追加されたもの（ファイルパス、ドライブのリンク、メールのエクスポート）。
2. デフォルトの案件フォルダー — CLAUDE.md の文書保存パターンから、このスラッグ用に展開したもの（例：G:/Legal/Matters/acme-v-us-2026）。
3. 宣言済みのソース — CLAUDE.md の Document storage テーブルから、この案件に関係する可能性があるものを抽出します（例：送信者側の通信に関する Gmail アーカイブ、SharePoint の法務フォルダー）。
4. 確認する — ソースが不十分に見える場合は、次のように尋ねます。「手元にある資料をもとに作成できますが、時系列は不完全になります。他に参照すべき資料はありますか？ 重要なメール、契約書、社内メモ、プロダクション関連の書簡などはありますか？」

--documents モード：

1. プロダクションのエクスポート／Bates 番号セット — ユーザーがプロダクションのディレクトリまたはマニフェストを指定し、スキルが Bates 番号の範囲と日付に基づいて読み取ります。
2. eDiscovery コネクター — MCP コネクター（Everlaw、Relativity、DISCO、Aurora）が利用可能な場合は、保管担当者と日付範囲を指定して取得します。
3. 保管担当者のファイル — ユーザーが保管担当者のメールボックスの生データやドライブのエクスポートを提供した場合は、それらも読み取ります。
4. 確認する — 重要な保管担当者または日付範囲のカバー範囲が不十分に見える場合は、確認を求めます。

ステップ 2：取得して読み込む

読み取り可能なファイルがある各ソースについて、次のように対応します。

• PDF、メール（.eml）、.docx、.txt — 直接読み込みます。
• メールアーカイブ（Gmail、Outlook） — MCP コネクターで認証済みの場合は、日付範囲と相手方／キーワードで検索します。そうでない場合は、ユーザーが関連するスレッドをフォルダーにエクスポートします。
• eディスカバリープラットフォーム（Everlaw、Relativity、DISCO、Aurora） — コネクターを利用できる場合は、保管責任者と日付範囲で取得します。そうでない場合は、ユーザーがエクスポートを提供します。

スキルが申告されたソースにアクセスできない場合は、そのソースを黙って処理を続けるのではなく、出力の「不足」セクションに明記してください。

黙って補完しないでください。 ある時期についてソースの網羅性が低い場合（想定より少ない文書しかない対象期間、メールボックスにアクセスできない保管責任者、まだ届いていないプロダクションなど）は、見つかった内容を報告して、そこで止めてください。確認を求めずに、ウェブ検索、公開記録の検索、または事案に関するモデルの知識で不足を補ってはいけません。次のように伝えてください。「[期間／保管責任者]について、ソースから[N]件の出来事が見つかりました。網羅性が低いようです。選択肢：（1）追加のソース（Bates番号、フォルダー、メールボックス）を指定する、（2）設定済みであれば別のMCPコネクターを試す、（3）この期間の公開記録に関する出来事をウェブで検索する――検索結果には[web search — verify]のタグを付け、依拠する前に一次ソースと照合する必要があります、または（4）ここで止めて不足を記録する。どれを選びますか？」信頼度の低いソースを受け入れるかどうかは弁護士が判断します。スキルが判断することではありません。

ソースの帰属。 すべての時系列項目に、出来事の出典（ファイルパス、Bates番号、MCP コネクター、または申告された文書保管ソース）を付けてください。取得した文書から抽出した出来事の出典は、すでに「ソース」列に記録されています。取得した文書にたどれない出来事や日付（モデルの学習データから想起した事実、ウェブ検索で見つけた公開記録の出来事など）には、項目内に[web search — verify]、[model knowledge — verify]、またはユーザーがセッション中に述べた事実の場合は[user provided]のタグを付けてください。verifyタグの付いた項目は、文書をソースとする項目より捏造のリスクが高いため、優先して確認する必要があります。タグを削除したり、まとめたりしてはいけません。ブリーフや事実陳述書に取り込む前に確認すべき項目を示す、弁護士にとって最も迅速な手がかりです。

法的結論、期限、または算出した日付を記載するセクションすべてにタグを付けてください。時系列項目だけではありません。 時系列は文書をソースとします。「不足」セクション、「主要な出来事」セクション、「理論との関連」行、ならびに制限期間、時効の進行停止事由、提出期限、ディスカバリーの締切、特権の判断についての記述はすべて、ソースがない限り、スキルがモデルの知識に基づいて作成する法的分析です。そのような記述にはすべて、出所を示すタグを付けてください。[computed from: <rule cited with tag>]、[model knowledge — verify]、[user provided]、またはこのセッションで情報を取得した場合は調査用コネクターのタグを使います。タグのない時効期間は、既定で[model knowledge — verify]となります。事実の法的重要性を説明する「主要な出来事」の行も分析にあたるため、タグが必要です。ルールは単純です。文書の記載内容ではなく法律についての主張であれば、時系列項目と同じ出所タグを付ける必要があります。調査用コネクターにアクセスできず、スキルが期限を算出したり規則を引用したりする場合は、レビュアー向けメモの**Sources:**行に記録してください（プラグインのCLAUDE.mdの## Outputsを参照）。単独のバナーは出力しないでください。

Step 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]（契約締結、製品発売、規制当局の措置、イベントがしきい値を超えたなど）

通常、文書ごとにイベントは1件です。イベントがない場合もあります（日時が記載されていない、またはイベントが確認できない場合）。複数の場合もあります（複数の決定をまとめた会議の要約など）。

エントリーごとの特権フラグ（privilege_posture == B-mixed の場合のみ）。3状態ルール — 主観的な特権テストを満たさないと黙って判断してはいけません。

• priv: ok — 情報源が確実に特権対象ではない（申立書、規制当局との通信、公開文書、当社の弁護士を含まない相手方との通信）。特権の適用を合理的に主張できない場合にのみ使用します。
• priv: flag — 情報源が確実に、または特権対象である可能性が高い（弁護士との通信、ワークプロダクトメモ、特権対象の草稿、共同弁護資料）。不確かな場合はこれをデフォルトにします — 主たる目的の判断が微妙な場合、訴訟の予見可能性が境界線上にある場合、または内容が混在している場合は、ok ではなくこちらにします。
• priv: review — 情報源の内容だけでは判断できず、スキルでもまったく判断できない（送信者／受信者のメタデータがない、判読不能など）。

priv: flag または priv: review の場合は、インラインで [SME VERIFY: privilege status] を追加し、レビュー時に弁護士が確認できるようにします。フラグの付け忘れは特権を放棄することになります（一方通行）。フラグの付けすぎはレビュー時に弁護士が修正できます（双方向）。後から修正可能な誤りを優先してください。

Step 4: 重複を除去する

同じイベントが複数の文書に現れる場合があります。会議が3つのカレンダーに記載され、要約メールが作成された場合、それは4件のイベントではなく、4つの情報源を持つ1件のイベントです。統合してください。統合したエントリーには、すべての情報源を記載します。

Step 5: 重要度をタグ付けする — 事件の理論に基づいて

--matter モードでは matter.md から、--documents モードでは設定の ## Case theory セクションから、転換点となる事実と重要事実を読み取ります。各イベントにタグを付けます。

• 🔴 重要 — イベントが転換点となる事実、または当社に有利／不利な重要事実の一部である
• 🟡 関連 — 背景、パターンを示す証拠、二次的な主張を裏付けるもの
• ⚪ 参考情報 — 完全性のためには有用だが、準備書面には含めないもの

原則： 300件のエントリーすべてに🔴タグが付いた時系列表には、実質的にタグがありません。事実認定者の判断を実際に左右するイベントにのみ🔴を付けてください。判断に迷う場合は🟡にします。

境界線上のタグ付け： エントリーが🔴と🟡（または🟡と⚪）の境界線上にある場合は、重要度の低いほうのタグを付け、インラインで [SME VERIFY — borderline significance call] を追加します。弁護士の判断がスキルの判定に優先します。自信を持って過剰にタグ付けした時系列表よりも、不確かさを明らかにする時系列表のほうが有用です。

Step 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)

事実関係陳述用時系列表（リクエストに応じて作成）

🔴と関連する🟡のみを抽出します。時系列順の叙述として文章で示します。これは準備書面の事実関係セクションの骨子となります。各段落には、記録の引用を添えて、1件のイベントまたは密接に関連するイベント群を記載します。

特権フィルターのデフォルト： privilege_posture == B-mixed の場合、🔒フラグ付きおよび🔒レビュー対象のエントリーは、デフォルトで除外されます。事実関係陳述用の形式は、最終的な外部利用（準備書面、開示、交渉相手への提示）を想定したものです。弁護士が特権の状態を確認するまでは、🔒エントリーを含めません。ユーザーが🔒エントリーの記載を希望する場合は、明示的に --include-flagged を指定して確認する必要があります。その確認内容は永続的な記録として出力ヘッダーに記載します。

証人固有の時系列（オンデマンド）

送信者、受信者、出席者、または件名に名前付き証人が含まれるイベントに絞り込みます。証人の準備を支援し、証人がいつ何を知っていたかの再構成に役立ちます。

インクリメンタルビルド

chronology.md が存在する場合:

• 以前のバージョンを読み込む
• 現在のソースから新しい時系列を構築する
• 差分: 新しいイベント（前回のビルド以降）、変更されたエントリ（既存のイベントに追加された新しいソース）、削除されたエントリ（まれ。理由を記載）
• 以前のバージョン番号を保持し、新しいバージョンを v[N+1] として書き込む
• 変更内容のサマリーを出力する

matter.md / history.md との統合

意図的に分離（社内 --matter モード）。history.md は弁護士のランニングログです — 決定、更新、手続き上のマイルストーン、内部戦略メモ。chronology.md は主張に直面する事実のタイムラインです。両者は重複しますが、統合はしません:

• ホールドが発令された → history.md に記載（内部アクション）。通常は chronology には含めません（紛争の事実ではないため）。
• 相手方が3月14日に違反通知を送付した → chronology.md に記載（🟡 — 相手方の認識を立証）。intake で言及されていれば history.md にも記載。
• 当方のリザーブ推奨メモが作成された → history.md のみ。

弁護士が history のイベントを chronology に含めたい場合は、貼り付けることができます。デフォルトでは分離したままです。

このスキルが行わないこと

• 矛盾の解決。 2つの文書がイベントの発生日時について異なる記述をしている場合、両方のエントリがフラグ付きで記載されます。解決は弁護士の判断です。証人インタビューやさらなるディスカバリが必要になる場合があります。
• ソースにないイベントの創作。 文書にないもの（および matter.md や構成にキャプチャされた事実としてないもの）は chronology に含まれません — ただし「Gaps」で欠落として指摘される場合があります。
• 完全性の保証。 chronology はソースの質に依存します。eDiscovery のプロダクションが進行中で20%しか到着していない場合、chronology はその状況を反映します。制限を明記してください。
• ユーザーの秘匿特権ステータスの決定。 ステップ0のゲートで姿勢の選択を強制し、エントリごとの priv フラグで一次分類をキャプチャします。実際の秘匿特権の判断は [SME VERIFY] フラグごとに弁護士の判断です。