litigation-matter-update git:20260529.efece30A

Immutable. This exact content is served forever at /api/v1/blob/ea548246e56a9b54.

---
name: litigation-matter-update
description: >
  向案件历史文件追加带日期的事件记录并刷新日志行——
  捕获新进展、状态变化、风险重评估、期限变更和和解授权变更。
  当用户需要记录案件更新、标注进展或对案件组合记录状态变更时使用。
argument-hint: "[代号] [简要事件描述]"
---

# /matter-update

1. 按以下工作流操作。
2. 确认代号在 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/` 和 `_log.yaml` 中存在。
3. 提示输入：事件类型、日期（默认今天）、摘要，以及任何日志字段更新（风险变更、状态变更、下一节点变更、重要性重新分类）。
4. 追加带日期条目至 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/[slug]/history.md`。
5. 更新 `_log.yaml` —— `last_updated` 设为今天，应用任何字段更新。
6. 确认。

---

# 案件更新

## 目的

案件组合只有保持更新才有用。本技能让记录更新变得简单——两分钟结构化记录，不跑偏。

## 加载上下文

- `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/_log.yaml` —— 找到对应行
- `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/[slug]/history.md` —— 追加目标
- `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/[slug]/matter.md` —— 参考（不重写）
- `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md` —— 风险校准（如需重评估风险）

**冲突门禁——不可绕过。** 在记录更新前，检查 `_log.yaml` 中是否存在该案件代号。如果案件不在 `_log.yaml` 中，拒绝并路由：

> "我在案件日志中没有找到 [案件代号]。请先运行 `litigation-matter-intake`，以便冲突检索可以运行且案件工作空间已经建立。我不会向未登记的案件追加历史记录——冲突检索是门禁，且在案件完成登记之前没有 `history.md` 可供追加。"

## 输入

代号（必填）。如未提供，询问——附最近更新案件的简短列表供选择。

## 更新内容

### 1. 事件类型

提供类别：

- **程序性** —— 起诉/答辩/申请已提交或收到、裁定/判决已下达、开庭/庭前会议已进行、期限已设定
- **证据** —— 证据已提交或收到、证人出庭/询问已进行、调查令已送达
- **实质性** —— 新事实、关键文件浮现、实体裁定
- **策略** —— 姿态转变、和解要约已发出或收到、授权更新
- **风险重评估** —— 严重性或可能性变更
- **相关方** —— 新人员纳入、外聘律师变更
- **行政性** —— 委托合同已签署、预算调整、证据保全已刷新

如以上无一匹配，使用自由格式。

### 2. 日期

默认今天。可接受覆盖（如记录上周的事件）。

### 3. 摘要

一段话叙述。发生了什么、意味着什么、任何即时影响。

### 4. 日志字段变更

逐项检查可能受影响的字段：

- `status:` —— 阶段是否转移（如起诉 → 庭审）？
- `stage:` —— 子阶段更新
- `risk:` —— 是否需要重评估？
- `materiality:` —— 是否有变更？
- `exposure_range:` —— 如新信息出现，修正
- `next_deadline:` —— 新的即将到来的日期（如有）
- `outside_counsel:` —— 变更？
- `internal_owners:` —— 新增或移除人员？
- `legal_hold:` —— 已刷新、扩大或解除？

仅对事件类型可能影响的字段进行提示。程序性更新通常仅涉及 `stage` 和 `next_deadline`；和解要约可能涉及 `materiality`、`exposure_range`、`status`。

### 4pre. 和解接受门禁

如果策略更新为**接受和解**（公司正在接受和解要约、签署和解协议或原则性授权接受——不仅仅是记录要约的发出或收到）：读取 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md` 中的 `## 使用者`。如果角色是**非律师**：

> 接受和解具有法律后果——它解决争议，通常需要签署免责协议，并可能影响保险、税务和关联事项。您是否已与律师审查过此事？如已审查，继续。如未审查，以下是带去给律师的简要材料：
>
> [生成一页摘要：案件、拟议和解条款（金额、结构、免责范围、保密、不得贬损条款）、涉及的敞口、授权层级状态（见 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md` 和解授权）、可能出错的事项、接受前需要问律师的问题。]
>
> 如果您需要寻找律师：请联系当地律师协会或拨打 12348 法律援助热线获取推荐。

未收到明确确认之前，不记录接受或翻转重要性。记录要约或还价不需要门禁——接受需要。

### 4a. 重要性触发器——显式提示

某些事件类型强制重要性重新检查。当事件类型在以下列表中时，**始终提示**——不要让用户在未明确答复的情况下跳过：

| 事件类型 | 重要性触发器提示 |
|---|---|
| 实质性（新事实、关键文件、实体裁定） | "此事件是实质性的。是否推动 `materiality`？当前：`[current]`。选项：`需计提 / 已披露 / 监控中 / 不适用`。变更？" |
| 策略（姿态转变、和解要约已发出或收到） | "和解活动通常触发重要性重新分类。当前：`[current]`。如果要约、还价或接受改变了敞口或从争议状态变为很可能且可估计，重新分类。" |
| 风险重评估（严重性或可能性变更） | "风险已变动。重要性应跟进。当前：`[current]`。重新分类？" |
| 行政监管/执法进展 | "监管机关行动（协查通知、执法通知）通常触发披露分析。当前：`[current]`。变更？" |

可接受的答复包括"不变更"——但"不变更"必须是明确的，不能由沉默默示。在历史记录中捕获：

```markdown
**重要性检查：** [未变更 / 从 X 变更为 Y]
**理由：** [一句话]
```

如重要性变更为"需计提"或"已披露"，且该案件此前未记录计提或披露，标注该事件需要按 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/profile.md` 的重要性门槛通知财务/审计委员会。

### 5. 文件关联提示（可选）

如更新引用了一份文件（裁定书、起诉状、往来函件），询问是否有路径链接。不强求。

## 写入

### 追加至 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/[slug]/history.md`

最新记录在最前，直接放在标头后的 `---` 之下。

```markdown
## [YYYY-MM-DD] —— [事件类型]：[简短标题]

[段落摘要。]

**字段变更：**
- [字段]: [旧 → 新]
- [字段]: [旧 → 新]

**关联文件：** [路径，如有提供]
```

如无字段变更，省略"字段变更"块。

### 更新 `$LEGAL_AGENT_PROFILE_HOME/litigation-legal/matters/_log.yaml`

- 应用任何字段变更。
- 设置 `last_updated: [今天]`（如用户覆盖日期，使用事件日期——日志记录的是记录最后被触及的时间）。

## 确认

写入前向用户展示历史条目和 yaml 差异：

> 这是我将追加和更新的内容。可以写入吗？

## 本技能不做什么

- 编辑既往历史记录条目。修正是引用并纠正既往条目的新条目。
- 静默变更日志。每次字段变更在写入前向用户展示。
- 决定新进展是否需要计提/披露。浮现问题（"这可能推动重要性——需要重新分类吗？"），用户答复。