Competitor Intelligence

Competitor News Monitor

Track a declared company set and report only material, new developments with primary-source evidence. This is not a generic page-diff watcher: it applies company-news categories, source hierarchy, event deduplication, and business significance. A one-off digest needs no scheduler; recurring monitoring uses the existing Prismer tasks workflow only when the user requests recurrence.

When to Use

• "Monitor these competitors weekly."
• "Tell me when Company X changes pricing or launches a product."
• "Create a competitor intelligence digest."
• "Track funding, partnerships, executive moves, and incidents."
• A cron tick fires for an existing competitor watch (steps 3-6).

For one-off company research, apply the same source/evidence methodology without creating a schedule. Use available browser/ingest tools; optional feed connectors are not required to research public sources.

Procedure — Setup (foreground, once)

1. Freeze the watchlist

Record canonical company names, domains, products, aliases, geography/language, event categories, cadence, audience, and materiality threshold. Done when a candidate article can be accepted or rejected consistently.

2. Build source coverage, then schedule

For each company include, where available:

1. official newsroom/blog and changelog
2. pricing/product pages
3. regulatory filings and investor relations
4. status/security pages
5. reputable trade and financial press
6. job postings as weak supporting evidence

Use installed feed connectors when available and browser/ingest tools for pages. Write the watch contract (watchlist, categories, materiality threshold, timezone, destination, primary sources) into the task description or a task-bound asset. For explicitly requested recurring work, follow tasks and record the returned ID:

cloud task create --title "Competitor intelligence" --schedule-cron "0 9 * * 1" --description "<confirmed watch contract, timezone, assignee and destination>"

Done when each requested event category has at least one intended primary source or a documented gap, and the job exists.

Do not assume cron timezone from the UI host; inspect the actual task schedule and read it back. Do not promise recurrence if the task service cannot represent the requested timing or no runnable assignee is bound.

Task-bound checkpoint

Use scripts/watch_state.py relative to this installed skill, with an absolute task scratch path plus workspace and task IDs. init --source <id> creates the state once; show verifies its identity. Never reset a restored watch. collect --input <json> consumes {sources: [{source, ok, cursor, error}], events: [{id, source, url, summary}]}; each cursor is an ISO time with timezone. The event ID denotes the underlying announcement, not the article URL.

Before each tick, retrieve the latest checkpoint from cloud task get <taskId> and its assets (cloud asset get, then cloud asset download --out <path>). Verify workspace/task and revision; mutations require --expected-revision N. After each state change, attach the new state via cloud task attach <path> and record the returned asset receipt on the task. Task scratch alone is not durable. Only one runner may own a watch tick: this helper's file lock is local, not a distributed lock. If task execution cannot guarantee serialized ownership, stop recurring delivery rather than racing independent checkpoint copies.

Procedure — Tick (each scheduled run)

3. Collect incrementally

Search from the last successful cutoff with overlap for late indexing. Capture company, event category, event/publication date, source, canonical URL, and evidence in the state file. A source failure means unknown coverage, not "no news" — record it. Done when pagination and failures are recorded and the cutoff advances only on success.