Guided intake for a brand-new Workers’ Comp file. Conflict-checked against existing applicants and existing matters against the same employer, SOL deadlines auto-computed and calendared with a verify-this disclaimer, and an 11-task compliance scaffold assigned by role (attorney vs. paralegal). Opens the case — does not file the Application.
At the prompt:
aaicase> new caseAbout a minute later, after a guided question-and-answer pass, you have a brand-new case in Merus with the applicant on file, an injury record attached, SOL events on the calendar, and a complete compliance task scaffold assigned by role. The case is in Intake status (case_status_id 9419), not Open — intake is the holding pattern while the retainer and NOR are being processed. Status flips to Open later when the Application is filed.
This is the only skill in AAI that creates a case from scratch. Everything else operates on existing cases. The pattern reflects that: a lot of asking, a lot of verifying, two conflict checks, and an explicit refusal to take certain steps without an attorney’s eyes on them.
The skill does not guess. It asks for what it doesn’t have:
If you give it half of these, it asks for the rest before doing anything. Partial intakes can be saved and resumed, but a case is never created with placeholder data.
Additional info collected as it goes — phone, email, address, language, interpreter, DOB, claim number, ADJ number, carrier, adjuster — gets attached where it belongs. If you don’t have it yet, the skill flags the gap for follow-up rather than inventing values.
Before creating anything in Merus, the skill searches for an existing case under the applicant’s last name:
node bin/merus-search.mjs "DOE"If a match exists, it stops and shows you:
This case may already exist:
· Doe, Jane v. Sample County Agency (#[ID]) — DOI 2024-09-12, Status: Open
Continue with new case or use the existing one?
This catches the most common intake mistake: opening a duplicate case when the client already has a matter at the firm under a different employer or for a different DOI. The skill defers to the attorney’s decision — sometimes a duplicate is correct (a new DOI for the same client) — but it surfaces the question.
Separate from the applicant check, the skill searches every existing case at the firm for the employer name:
node bin/merus-search.mjs "SAMPLE COUNTY AGENCY"If matches exist, it warns:
Your firm already represents 3 applicants against this employer. Verify no conflict of interest exists (Cal. Rule of Prof. Conduct 1.7) before proceeding.
Existing matters:
· Roe, Maria v. Sample County Agency (#[ID])
· Sample, Alex v. Sample County Agency (#[ID])
· Doe, Jane v. Sample County Agency (#[ID])
Rule 1.7 conflicts in Workers’ Comp are unusual but not impossible — the same employer matters can occasionally create informational or positional conflicts (a co-employee who is a defense witness, for example). The skill doesn’t decide whether there is a conflict; that’s a legal judgment. It just makes sure the question isn’t skipped.
Once both conflict checks are clear (or the attorney approves proceeding through them), the skill creates the case:
node bin/merus-fetch.mjs /caseFiles/add \
case_type_id=1 \
case_status_id=9419 \
"name=LAST, FIRST v. EMPLOYER"case_type_id=1 is Workers’ Compensation. case_status_id=9419 is Intake on the demo firm; the skill resolves the actual Intake status ID dynamically via /caseStatuses/index so it works against any firm’s status configuration (Intake numbers vary).
The new case_file_id is captured from the response and used for every subsequent write in this intake flow. If the case creation fails, nothing else runs — no orphaned tasks, no events on a nonexistent case.
The injury record is created next, anchored to the DOI and body parts:
node bin/merus-fetch.mjs /injuries/edit \
case_file_id=[CASE-ID] \
injury_type_id=[TYPE] \
"date_of_injury=MM/DD/YYYY" \
"q1_injury_description_text=BODY PARTS DESCRIPTION"injury_type_id=1 is Cumulative Trauma. injury_type_id=2 is Specific Injury. For CT injuries, the skill also asks for the end-of-exposure date and writes it to date_of_injury_end — both ends of the exposure period matter for the SOL calculation downstream.
If you have the carrier claim number or ADJ/EAMS number at intake, they go on the injury record as carrier_claim_number and eams_case_number. If you don’t yet, the “request claim log” task created in Step 6 below covers the follow-up.
The skill searches existing contacts before creating a new one — the same client may already be in the firm’s contact list from prior matters. If not found, the contact is created and linked to the case as a party with people_type_id=58327 (Applicant).
Phone, email, address, language, interpreter flag, and DOB are collected during the dialog and written to the contact record. If a piece of info is missing (no phone yet, no DOB on the intake form), the skill notes the gap for follow-up rather than writing a placeholder.
From the DOI, three deadlines are auto-computed and added to the case’s calendar:
| Deadline | Authority | Computation |
|---|---|---|
| 1-year SOL | LC 5405 | DOI + 1 year — deadline to file the Application for Adjudication. |
| 5-year SOL | LC 5410 | DOI + 5 years — outer jurisdiction limit. |
| 90-day acceptance/denial window | LC 4650(c) | Date of employer knowledge + 90 days. |
Every SOL event title carries the disclaimer:
VERIFY — this date is calculated automatically and may not account for discovery rule (LC 5412), tolling, or delayed employer knowledge. Attorney must independently verify.
The disclaimer is on the calendar event itself, not just the documentation, so any attorney or paralegal who opens the calendar later sees it. SOL math is the highest-stakes math in the practice; the skill computes it because computing it is useful, and labels it “verify” because relying on it without verification is malpractice waiting to happen.
The skill writes the SOL events using DOI + 1 year as a placeholder for CT cases, but flags every CT case explicitly:
This case is CT. The 1-year SOL may not run from the last date of exposure — it runs from the date of knowledge per LC 5412. Attorney must determine the LC 5412 date based on medical records, doctor advisement, or applicant statement.
That determination is a legal judgment, not arithmetic. The deadlines skill carries the same flag forward at the per-case level — a CT case with an auto-computed SOL is treated with extra caution because the “real” deadline may be earlier or later than the calculation suggests.
Every new case gets these 11 tasks created on Day 1, assigned by role:
| # | Task | Role | Due | Priority |
|---|---|---|---|---|
| 1 | Obtain signed retainer agreement (Bus. & Prof. Code 6147) | ATTORNEY | Day 1 | High |
| 2 | Send NOR to carrier, employer, defense | ATTORNEY | 3 days | High |
| 3 | Get HIPAA medical authorization signed | PARALEGAL | 7 days | High |
| 4 | Send lien letters to providers | ATTORNEY | 7 days | High |
| 5 | Request wage statement from employer/carrier | PARALEGAL | 7 days | Normal |
| 6 | Request claim log / payment log from carrier | PARALEGAL | 7 days | Normal |
| 7 | Verify DWC-1 filed with employer | PARALEGAL | 3 days | High |
| 8 | Issue subpoenas for medical records | ATTORNEY | 14 days | Normal |
| 9 | File Application for Adjudication with EAMS | ATTORNEY | 30 days | High |
| 10 | Follow-up call with client (administrative only) | PARALEGAL | 7 days | Normal |
| 11 | Check TD status and send demand if needed | ATTORNEY | 14 days | High |
These are the tasks every Workers’ Comp case should have on Day 1. The most common malpractice pattern in intake isn’t doing them wrong; it’s never creating them at all and then forgetting they were ever supposed to happen. The skill makes that forgetting impossible.
The role split isn’t cosmetic. Sending a Notice of Representation, signing lien letters, issuing subpoenas, filing the Application, and sending TD demands are all legal acts — they require attorney authorization and signature. A paralegal can prepare the materials; only an attorney can direct the act.
The skill enforces this in two places: the role tag on each task as it’s created, and the staff lookup in _approval-flow.md — the firm’s actual user list determines who is an attorney and who is a paralegal. If the firm hasn’t set those user types correctly in Merus, the skill flags the ambiguity and asks before assigning.
At the end of intake, the skill shows:
NEW CASE CREATED
Case: Doe, Jane v. Sample County Agency (#[ID])
Case ID: [INTERNAL-ID]
Status: Intake
DOI: 2026-04-12 | Type: SI
Body Parts: low back, right knee
DEADLINES CALENDARED:
1-year SOL: 2027-04-12 (VERIFY)
5-year SOL: 2031-04-12
90-day acceptance window: pending employer-knowledge date
TASKS CREATED: 11 compliance tasks
1. [ATTORNEY] Obtain signed retainer agreement due Day 1
2. [ATTORNEY] Send NOR due 3 days
3. [PARALEGAL] Get HIPAA authorization signed due 7 days
4. [ATTORNEY] Send lien letters due 7 days
5. [PARALEGAL] Request wage statement due 7 days
[...]
CONFLICT CHECKS: applicant ✓ | employer ✓ (no firm matters against this employer)
NEXT STEPS:
1. Get signed retainer (task #1) before any other work
2. Enter carrier/adjuster info when available
3. Verify LC 5412 date if anything suggests delayed knowledge
4. Flip case status to Open once Application filed (task #9)The summary is also written to CaseFile.comments so anyone opening the case later sees what was set up at intake.
Common for clients with a long employment history. Approve proceeding; the new case will be a sibling matter to the existing one, sharing the contact record but with its own DOI, body parts, and timeline.
Common at firms that handle high-volume practice against the same large employers (school districts, state agencies, large carriers). The Rule 1.7 warning is informational; the attorney makes the actual conflict determination. The skill won’t block intake on this — it just refuses to skip the question.
The skill resolves the actual Intake status ID dynamically. If your firm uses a different status name for new-but-not-yet-filed cases (some firms call it “Pre-Application” or “New”), the skill picks it up from /caseStatuses/index. If no matching status exists, it asks before falling back to Open.
The default scaffold is conservative — the union of what most applicant firms do at intake. Tasks you don’t need can be completed immediately during the post-intake task walk (process my tasks); their existence in the audit trail confirms they were considered.
Probably right. The calendar event is labeled “VERIFY” for exactly this reason — the auto-computed CT date is DOI + 1 year, but the real SOL runs from LC 5412 discovery. Edit the event with the attorney-determined discovery date. The flag in the case comments survives the edit.
You can’t through this skill. Filing is task #9 — it gets created, prepped, and walked through separately. The Application is the legal-act gateway to a WCAB matter; it goes through attorney review and signature, not an intake automation.
Part of AAI for MerusCase — code-guarded AI case intelligence for California Workers’ Comp attorneys.