Status

The fastest skill in AAI. Under five seconds, no LLM involvement, no inference — just five parallel API fetches and a pure-JavaScript rollup. Open cases, stip cases, total. Real tasks (auto-noise filtered). Events this week. Unprocessed mail. The numbers an attorney glances at first thing in the morning to know where the firm stands.

The case counts and numbers in this page are fictitious demonstration data. Your install runs against your real Merus data.

What it is

At the prompt:

aaicase> /status
aaicase> status

About four seconds later you have a compact rollup of the firm’s caseload counts: open cases, stip cases, total cases, open tasks (with overdue and HIGH subcounts), events this week, and unprocessed mail count. The output is a 5-line summary, designed to be glanced at, not read.

It’s the most-used skill in the system after the morning brief, run dozens of times a day at most firms — before meetings, after lunch, end-of-day, every time the attorney wants to know “where do we stand right now.”

No AI — the deliberate design

Status doesn’t call Claude at all. No model inference, no LLM tokens spent, no semantic classification. Five API fetches, deterministic JavaScript counts, formatted output. Under five seconds.

The reason is speed. The morning brief takes 30 seconds because it’s computing danger scores and pulling per-case context. The status skill computes none of that — it just counts what’s there. Adding any AI step (even a single classification) would more than double the runtime and gain nothing the deterministic count doesn’t already produce.

This is the rule across AAI: classification goes through Claude; arithmetic goes through JavaScript. Status is pure arithmetic. The only LLM involvement in the whole flow is the trigger detection (“is this command a status request?”), which the REPL does once at command-parse time, not on every run.

How it runs (under the hood)

One bash block, five parallel fetches:

/caseFiles/index      → all cases
/tasks/index          → all tasks
/events/index         → all events
/uploads/index        → all uploads (for orphan count)
/caseStatuses/index   → firm-specific status definitions

Required: cases + tasks (the core counts). Optional: events, uploads, caseStatuses. If a non-required endpoint fails, the corresponding count is shown as 0 with a NOTE explaining what dropped out. If caseStatuses fails, the skill falls back to a hardcoded ID map for the most common firm configuration so the open/stip split still works.

Everything lands in a per-run mktemp -d directory locked to chmod 700, deleted at the end. The whole flow is bounded by network round-trip time — usually 2–4 seconds against api.meruscase.com.

Dynamic case-status lookup

Every firm has its own status IDs. One firm’s “Open” might be 9413; another firm’s might be a different ID. Hardcoding the IDs into the skill would mean status counts are wrong for any firm except the one it was developed against.

So the skill fetches /caseStatuses/index at every run. Each status definition includes:

id — the numeric status ID used elsewhere in Merus
status — the firm’s display name (“Open,” “Stipulation,” “Pending,” “Hold,”...)
slug — a normalized category: open, closed, archived

The skill builds two ID sets at runtime:

Open IDs — every status with slug === 'open'. This typically includes Open, Pending, Intake, Hold, etc. — whatever the firm considers active matters.
Stip IDs — every status whose name contains “Stip” (case-insensitive). Catches Stipulation, Stip with Award, Stip in Progress, etc.

These sets drive the open and stip counts. Firms using non-standard status names get correct counts without any aaicase update.

Fallback: if /caseStatuses/index fails or returns no data, the skill uses a documented hardcoded map (9413 Open, 9415 Stipulation, 9419 Intake) and notes the fallback in the output. This was previously the only behavior — the dynamic lookup landed in version 4.5.135 specifically because the hardcoded map was wrong for several firms.

The narrowed noise filter

Merus auto-generates “REVIEW (auto…),” “VERIFY (auto…),” and “Review filed orphan” tasks as side effects of various operations. The task count would be inflated by these — sometimes 2× or 3× — if they weren’t filtered.

The filter is intentionally narrow, matching only the prefixes that have never been a real attorney-actionable task in practice:

^(Review filed orphan|Review mail filing|REVIEW \(auto|VERIFY \(auto|VERIFY APPLICANT.*\bautogen\b)

An earlier version had ^VERIFY at the start, which hid every attorney task starting with “Verify” — including “Verify date of injury” and “Verify subpoena served.” That was wrong; this regex is narrowed (since version 4.5.113) to only catch explicit auto-generation markers.

The status output shows the noise count as a separate line so the attorney sees both the real task count and the auto-generated noise behind it. The noise number is the “how much Merus is creating tasks behind your back” signal.

The five counts

Count	Source	Notes
CASES	`/caseFiles/index`	Open count uses dynamic status IDs. Stip count is statuses whose name contains “Stip.” Total is all cases regardless of status.
TASKS	`/tasks/index`	Open count is real tasks (noise filtered) where `complete` is false. Overdue subcount: `date_due` before start of today. HIGH subcount: `priority === 1`.
EVENTS	`/events/index`	Events whose start time falls between start of today and 7 days from now.
MAIL	`/uploads/index`	Orphan uploads: no `case_file_id` AND no `activity_id`. These are the “mail came in but never got filed” uploads.
NOISE	`/tasks/index`	Auto-generated tasks filtered out of the TASKS count above. Shown for transparency.

Flags — what raises an eyebrow

The output is a count summary, not a triage. But three numbers are worth flagging when they’re non-zero:

Overdue tasks > 0 — something missed a due date. Run process my tasks to walk through.
Unprocessed mail > 0 — inbound documents are sitting orphaned. Run process mail to file them.
No events this week — either a genuinely quiet week or scheduling went missing. Worth checking the calendar.

The skill doesn’t auto-suggest actions based on these numbers. It just shows them. The attorney decides whether to act.

Example output

STATUS — Acme Law (as of 2026-05-27 14:22)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  CASES:   287 open, 42 stip, 1,418 total
  TASKS:   34 open (3 overdue, 8 HIGH)
  EVENTS:  12 this week
  MAIL:    7 unprocessed
  NOISE:   147 auto-generated tasks (hidden)

(generated in 3.4s)

That’s the whole skill. Five lines plus a header. Anything that needs deeper investigation has a dedicated skill (process my tasks, process mail, morning brief, which cases need attention).

When to run it

Anytime. The cadence is “whenever you want to know.” Most attorneys run it 5–15 times a day.
Before a meeting — quick check that nothing’s on fire before walking into a different context.
After lunch — what changed while you were away.
End of day — verify the inbox is clean and overdue is at zero before logging off.
After running another skill that wrote — sanity check that the writes landed.

Troubleshooting

“Open count is wrong”

Most likely a status the firm uses isn’t categorized as “open” in /caseStatuses/index. The slug field on each status definition is what the skill keys off. Check Merus settings; if a status like “Hold” should be counted as open and currently isn’t, update the slug.

“Stip count is zero but I know we have stips”

The skill matches statuses whose name contains “Stip.” If your firm uses a different name (e.g. “Settled-Stip” or “Closed Stipulation”), the substring match should still catch it. If you’re using something unusual (“C&R-Stip in Progress”), the match works. If you’re using a name without “Stip” at all, the skill won’t find them.

Tasks count higher than expected

Check the NOISE line. If the noise count is high (say, 100+), Merus is generating a lot of auto-tasks — usually after a mail-processing run. The TASKS line shows only real tasks, but the noise total tells you how much Merus is creating behind the scenes.

Tasks count lower than expected

Either the noise filter is too aggressive (false positives hiding real tasks — unlikely with the current narrowed regex), or the tasks were closed. Run process my tasks to see the actual open list.

“0 events this week” but I have a hearing tomorrow

The window is today through today + 7 days. A hearing tomorrow should appear. If it doesn’t, the event may be on a date past the 7-day window (the firm’s calendar entry could be wrong) or the event record didn’t have a valid start time. Run events on [case] via the Merus UI to confirm.

Unprocessed mail count keeps growing

The orphan detection counts uploads with no case AND no activity. If mail is being processed but the binding step is failing, the uploads remain orphaned. Check the process mail output for binding refusal errors.

Slow runs (over 10 seconds)

Network latency to api.meruscase.com is the dominant factor. If status is consistently slow, the Merus API is degraded — everything else in AAI will be similarly slow. Check api.meruscase.com directly.

Morning brief — status is the count; morning brief is the triage. Run status to know the numbers; run morning brief to know what to do.
Process my tasks — clears the overdue tasks status surfaces.
Process mail — clears the unprocessed mail status surfaces.
Any new mail? — the targeted question; status shows total firm-wide mail count, this skill is “just the unprocessed count.”

Part of AAI for MerusCase — code-guarded AI case intelligence for California Workers’ Comp attorneys.