Append a dated event to a matter's history file and refresh the log row — captures new developments, status changes, risk re-assessments, deadline shifts, and settlement authority changes. Use when the user wants to log an update on a matter, note a development, or record a status change against the portfolio.
Append a dated event to a matter's history file and refresh the log row — captures new developments, status changes, risk re-assessments, deadline shifts, and settlement authority changes. Use when the user wants to log an update on a matter, note a development, or record a status change against the portfolio.
Codex v1 local-input note: This migrated skill supports local files and pasted text by default. References to Drive, CLM IDs, Slack, Westlaw, iManage, Ironclad, eDiscovery, dockets, or other remote systems require a separately configured Codex connector/MCP server. When a connector is unavailable, ask for a local export, local file path, or pasted excerpts. If config/local/codex-for-legal/<practice>/CLAUDE.md is missing, ask the user to run the relevant cold-start-interview or customize skill and copy from config/templates/codex-for-legal/<practice>/CLAUDE.md.
$litigation-legal:matter-update
Follow the workflow and reference below.
Confirm slug exists in config/local/codex-for-legal/litigation-legal/matters/ and _log.yaml.
Prompt for event type, date (default today), summary, and any log field updates (risk change, status change, next deadline shift, materiality reclassification).
Append dated entry to config/local/codex-for-legal/litigation-legal/matters/[slug]/history.md.
Update _log.yaml — set last_updated to today, apply any field updates.
Confirm.
Matter Update
Purpose
The portfolio only stays useful if it stays current. This skill makes logging an update cheap — two minutes of structured capture, no freeform drift.
Load context
config/local/codex-for-legal/litigation-legal/matters/_log.yaml — find the row
Conflicts gate — unbypassable. Before logging an update, check _log.yaml for the matter slug. If the matter is not in _log.yaml, refuse and route:
"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 exists. I won't append history to an unmanaged matter — the conflicts check is the gate, and there's no history.md to append to until the matter is intaken."
Input
Slug (required). If not provided, ask — with a short list of recently updated matters to pick from.
The update
1. Event type
Offer categories:
Procedural — motion filed/received, order issued, hearing held, deadline set
Discovery — production made/received, depositions taken, subpoena served
Substantive — new facts, key document surfaced, ruling on merits
Risk re-assessment — severity or likelihood changed
Stakeholder — new person looped in, outside counsel change
Administrative — engagement letter executed, budget adjusted, hold refreshed
Or freeform if none fits.
2. Date
Default today. Accept an override (e.g., capturing an event from last week).
3. Summary
One-paragraph narrative. What happened, what it means, any immediate implication.
4. Log field changes
Walk through potentially affected fields:
status: — has the stage shifted (e.g., pleadings → fact discovery)?
stage: — substage update
risk: — reassessment required?
materiality: — any change (new facts might trigger reserve or disclosure)?
exposure_range: — revise if new information
next_deadline: — new upcoming date, if any
outside_counsel: — change?
internal_owners: — anyone new or removed?
legal_hold: — refreshed, expanded, released?
Only prompt for fields likely affected by the event type. Procedural updates usually touch stage and next_deadline only; a settlement offer might touch materiality, exposure_range, status.
4pre. Settlement-acceptance gate
If the Strategy update is a settlement acceptance (the company is accepting a settlement offer, executing a settlement agreement, or authorizing acceptance in principle — not merely logging an offer made or received): Read ## Who's using this in config/local/codex-for-legal/litigation-legal/CLAUDE.md. If the Role is Non-lawyer:
Accepting a settlement has legal consequences — it resolves claims, typically requires a release, and can affect insurance, tax, and related matters. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
[Generate a 1-page summary: the matter, proposed settlement terms (dollar, structural, release scope, confidentiality, non-disparagement), exposure at stake, authority ladder status (see config/local/codex-for-legal/litigation-legal/CLAUDE.md settlement authority), what could go wrong, what to ask the attorney before accepting.]
If you need to find a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).
Do not log the acceptance or flip materiality on acceptance basis without an explicit yes. Logging offers or counters does not require the gate — acceptance does.
4a. Materiality trigger — explicit prompt
Certain event types force a materiality re-check. When the event type is in this list, always prompt — don't let the user move on without an explicit answer:
Event type
Materiality trigger prompt
Substantive (new facts, key document, merits ruling)
"This event is substantive. Does it push materiality? Current: [current]. Options: reserved / disclosed / monitored / none. Change?"
Strategy (posture shift, settlement offer made or received)
"Settlement activity often triggers materiality reclassification. Current: [current]. If the offer, counter, or acceptance moves exposure or shifts from contested to probable-and-estimable, reclassify."
Risk re-assessment (severity or likelihood changed)
"Risk moved. Materiality should track. Current: [current]. Reclassify?"
Acceptable answers include no change — but no change must be explicit, not implied by silence. Capture in the history entry:
**Materiality check:** [no change / changed from X to Y]
**Reasoning:** [one sentence]
If materiality moves to reserved or disclosed, and the matter did not previously carry a reserve or disclosure, flag the event as requiring finance / audit-committee notification per config/local/codex-for-legal/litigation-legal/CLAUDE.md materiality thresholds.
5. Seed doc prompt (optional)
If the update references a document (order, filing, correspondence), ask if there's a path to link. Not pushy.
Writing
Append to config/local/codex-for-legal/litigation-legal/matters/[slug]/history.md
Most recent at top, directly under the --- that follows the header.
Set last_updated: [today] (or the event date if the user overrode — the log tracks when the record was last touched).
Confirm
Show the user the history entry and the yaml diff before writing:
Here's what I'll append and update. Good to commit?
What this skill does not do
Edit past history entries. Corrections are new entries that reference and correct prior ones.
Silently change the log. Every field change is shown to the user before write.
Decide whether a new development warrants reserve/disclosure. It surfaces the question ("this might push materiality — want to reclassify?"), the user answers.
