ThomasMoreAI 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.mdis missing, ask the user to run the relevantcold-start-intervieworcustomizeskill and copy fromconfig/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— setlast_updatedto 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 rowconfig/local/codex-for-legal/litigation-legal/matters/[slug]/history.md— append targetconfig/local/codex-for-legal/litigation-legal/matters/[slug]/matter.md— reference (don't rewrite)config/local/codex-for-legal/litigation-legal/CLAUDE.md— risk calibration (if re-assessing risk)
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-intakefirst 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 nohistory.mdto 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
- Strategy — posture shift, settlement offer made/received, authority update
- 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 updaterisk:— reassessment required?materiality:— any change (new facts might trigger reserve or disclosure)?exposure_range:— revise if new informationnext_deadline:— new upcoming date, if anyoutside_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.mdsettlement 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?" |
| Regulatory / enforcement development | "Regulator action (subpoena, CID, enforcement notice) usually triggers disclosure analysis. Current: [current]. Change?" |
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.
## [YYYY-MM-DD] — [Event type]: [short title]
[Paragraph summary.]
**Fields changed:**
- [field]: [old → new]
- [field]: [old → new]
**Related doc:** [path, if provided]
If no fields changed, omit the "Fields changed" block.
Update config/local/codex-for-legal/litigation-legal/matters/_log.yaml
- Apply any field changes.
- 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.