← Files CrunchbaseARCHIVED FILE
skills/crunchbase-watchlists-manager/references/pipeline-monitoring.md
2.89 KB · Sep 30, 2026 · 22:50 UTC
# Workflow: Watchlist Event Monitoring Goal: review timestamped events and current state for a user-selected, persistent company list. Do not claim historical field changes without a comparable prior snapshot. ## First use If the user explicitly asks to create or save a company list for monitoring, resolve the proposed companies, preview the canonical linked set and list name, then follow `saved-lists.md`. Record a monitoring baseline date separately from list creation and membership version. If the user asks only to monitor companies or review an existing list, do not create or change a list automatically. ## Later reviews 1. Query saved lists and resolve the exact list selected by the user. 2. Fix the review baseline from the user's date, a prior task record, or an explicitly chosen date. Without a baseline, report current state only. 3. Resolve every predicate and order field through `cb_reference`. 4. Query organizations with `identifier in_list [<list_id>]`, requesting canonical identifiers, funding summary fields, dated leadership and layoff fields, employee band, current status, facets, and 30/90-day trend scores. 5. Query `funding_rounds` with `funded_organization_identifier in_list [<list_id>]` and an announcement-date predicate for the review window. Paginate to completeness. 6. Query `acquisitions` with `acquiree_identifier in_list [<list_id>]`, ordered by announcement date. Include earlier acquisitions when current pipeline state requires them. 7. Retrieve an entity profile only for an event that needs additional detail, using explicit fields and selected cards. ## Interpretation boundaries - Funding, leadership, layoff, and acquisition fields with dates can be compared with the review baseline. - A 30-day or 90-day trend score describes its own built-in window; do not present it as change since another baseline. - Status and employee band are current state unless a prior snapshot supplied in the task proves a difference. - Saved-list membership does not preserve historical organization fields. - A financing event should prompt review of prior sourcing history and disposition; do not label it a sourcing failure without that context. ## Membership updates Add, replace, or version membership only when explicitly requested. Resolve every new entity, preview the delta, and follow the reconciliation procedure in `saved-lists.md`. ## Output | Company | Dated event or current state | Detail | Suggested review action | |---|---|---|---| Then include: - **Tracked universe:** list name, list ID, member count, baseline date, and membership version - **Events since baseline:** funding, leadership, layoffs, and acquisitions supported by event dates - **Current-state review:** status, employee band, facets, and built-in trend windows - **Members with no dated event in the returned results:** collapsed into one concise line - **Source notes:** use `—` conventions from `output-contract.md`
SHA-256: 57c76a71ddc2bff1d5f68d7e51a6d7a51cdea35ad3cf2533f2baf6e8ad2259c9