Case watchlist board for tracking court dockets in one place

Build me a case watchlist workspace for my litigation team, so we work out of one screen instead of checking dockets one by one. It is a working surface for browsing, triage and shared state, not an alerting tool. Nothing runs on a schedule.

The main view is a board of the cases we track. Each card shows the case name, the court, the docket number, the date filed, and the newest docket entries on that case. Anything that arrived since the current user last opened that case is flagged as new, so store a per-user last-opened timestamp for each case and compare it against the entry dates. Let me group the board by matter or by client, with a selector to switch, and keep groups collapsible so a firm tracking thirty cases sees only what changed. Sort so cases with new activity float to the top of their group, and put a visible last checked timestamp on every card.

I add a case by searching CourtListener from inside the app. Use Search for free-text lookups across dockets and RECAP filings and List Dockets for direct docket lookups by case name, party or docket number. Build the court filter dropdown from List Courts, and cache that court list since it rarely changes. Result rows show case name, court, docket number and date filed, with a pin button that adds the case to the watchlist. Store pinned cases in app storage scoped to the team, keyed by docket id, so every member of the team sees the same watchlist.

Opening a case gives me a chronological timeline of every filing, order and motion. Use Get Docket for the case header metadata and List Docket Entries for the entries themselves. For each entry, pull the linked briefs and exhibits archived from PACER with List RECAP Documents and show them nested under the entry with links to the archived documents. Give every entry a one-line plain-language summary written from the entry description, so I can tell a scheduling order from a dispositive motion at a glance without opening anything.

Respect the CourtListener rate limits, which are 5 requests per minute, 50 per hour and 125 per day per token. All three apply at once. The board must never fan out one request per case on load. Render the board entirely from stored and cached data, and fetch docket entries lazily only when a card is expanded or a case is opened. Cache whatever was fetched alongside the timestamp it was fetched at. Offer a manual refresh on a single case, and a refresh-all that queues cases sequentially with pacing rather than firing them in parallel. If a request comes back throttled with a 429, show a calm try again shortly state and the Retry-After wait rather than an error.

Docket entry lists come back in the standard envelope with count, next, previous and results. Page by following the returned next URL rather than building pagination URLs yourself. When a case is opened, load the most recent page of entries first and offer a load more control for older history.

Team actions on top of the case data. I can mark an entry as reviewed, which records who reviewed it and when and is visible to everyone on the team, so two people never triage the same filing twice. I can assign a case to a teammate, shown on the card and filterable on the board. I can write a private matter note that stays attached to the case and is editable from the case view. Store all of this in app storage keyed by team alongside the pinned case record.

A Share to Slack button on any selected filing opens a channel picker built from Slack List Channels and posts a short summary with Slack Send a Message. The post should include the case name, the court, the docket number, the entry date and number, the one-line plain-language summary, and a link to the filing, formatted for Slack. Remember the last channel used and offer it as the default next time.