Matter Intake

/matter-intake

1. Load ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → risk calibration (for triage), landscape (for context, conflicts method), stakeholders (for who to loop in).
2. Follow the workflow and reference below.
3. Run the uniform intake: identification, conflicts check, source, risk triage, materiality, outside counsel, internal owners, legal hold, key dates, initial posture.
4. Generate slug from matter name (lowercase, hyphens, year).
5. Create ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md — full narrative intake.
6. Create ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/history.md — seeded with the intake as the first entry.
7. Append structured row to ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml.
8. Confirm with the user: "Here's the row I'll write — any edits?"

Matter Intake

Purpose

Every new matter goes through the same intake so the portfolio stays comparable. Uniform rows in _log.yaml let the status skill roll up. Narrative in matter.md captures what the row can't. History file seeded here becomes the event record.

Load context

• ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md — risk calibration (triage thresholds, materiality, settlement ladder), landscape (stakeholders, outside counsel bench).
• ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml — to confirm slug uniqueness.

The intake

1. Identification

• Matter name (as commonly referenced, e.g., "Acme v. Us 2026")
• Counterparty
• Matter type: contract | employment | ip | regulatory | investigation | product | other
• Our role: plaintiff | defendant | claimant | respondent | investigated
  • If the practice profile's ## Side is plaintiff, defense, or a "both — default X" variant, pre-fill the role from that default and confirm. If ## Side is varies by matter, ask cold. Never silently assume a posture the practice profile hasn't set.
  • The role drives downstream skills: plaintiff-posture matters route risk triage to case value / contingency economics; defense-posture matters route to exposure / reserves / insurance tender.
• Jurisdiction (court, arbitration forum, or regulatory body)

2. Conflicts check

Before going further, run the conflicts step per ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → Conflicts clearance.

• Status: cleared | pending | not-run | waived
• Method: match what ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md declares (corporate-legal | outside-counsel | system-check | informal | other). If the declared method is informal, say so — the record still captures that a counsel's-judgment check was the basis.
• Cleared by: name / team / firm
• Cleared date: YYYY-MM-DD
• Checked against: brief list of the specific names/entities run (counterparty, known affiliates, adverse counsel if known, key witnesses). Thin is fine; "no" is not.
• Notes: anything flagged but cleared (e.g., "Smith on our board sat on counterparty's board 2019–2021 — cleared as non-overlapping to this matter").

Behavior by status:

• cleared → proceed.

• pending → proceed with intake; flag prominently in matter.md and in the log row that conflicts are outstanding; surface again on every /matter-update and in /portfolio-status until resolved.

• waived → rare; requires a conflict-waiver rationale (writing the waiver is outside this skill — capture that one exists, who signed it, and where it lives).

• not-run → STOP. This is a gate. The skill will not create matter.md, history.md, or a _log.yaml entry until the conflicts posture is resolved. Three acceptable paths:

  Path 1 — Run conflicts now. Pause this intake. Clear per ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md Conflicts clearance. Return with status: cleared or status: waived with rationale.

  Path 2 — Mark pending with owner + due date. Allowed only when ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md Conflicts clearance declares parallel-intake acceptable. Capture: who is running conflicts, when they're expected to return, what entities they're checking. Intake proceeds; matter row carries conflicts.status: pending; /portfolio-status flags it every run; /matter-update re-prompts until resolved.

  Path 3 — Bypass with documented rationale. Only if the user explicitly acknowledges the bypass. Record in conflicts.override:

  conflicts:
    status: not-run               # preserved as-is
    override:
      by: [user name]
      date: [YYYY-MM-DD]
      rationale: [why conflicts were bypassed — permanent record; does not auto-expire]

  This field is visible in every /portfolio-status, every /matter briefing, and every /matter-update until removed. It is never removed by the skill — only by explicit user edit to _log.yaml after conflicts are actually cleared.

  Do not proceed silently. "I'll do it later" is not an acceptable response. One of Path 1/2/3 must be chosen, and the choice is captured in the record.

This step is not about the skill deciding whether a conflict exists — that's the user's/firm's judgment. It's about making sure the check happened and the record reflects it.

3. Source

How did this arrive?

• demand-letter | complaint-served | subpoena | regulator-inquiry | internal-report | pre-suit-threat
• Seed doc opportunity: "If you have the initiating document (complaint, demand, subpoena), attach or share the path. It sharpens the intake."