/competitor-intelligence

name: competitor-intelligence
scope: common
category: research
description: "Watch named companies for material news; cited digests."
version: 0.1.0
author: Ben Barclay (benbarclay), Hermes Agent
license: MIT
platforms: [linux, macos, windows]
metadata:
  nativeReplaces: [competitor-news-monitor]
  upstream: Hermes Agent skills/research/competitor-news-monitor at 1a1f4a59e2
  hermes:
    tags: [Competitors, News, Market-Research, Monitoring]
    related_skills: [blogwatcher, rss-feeds, reddit-reading]

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.

4. Deduplicate by underlying event

Collapse syndicated stories, rewrites, URL variants, press release coverage, and revised filings into one event. Keep independently sourced corroboration attached. Done when one announcement appears once regardless of article count.

5. Assess materiality

Score directness, source authority, novelty, customer/market impact, strategic relevance, and confidence against the watch contract's threshold. Separate measured facts from interpretation. Hiring patterns and anonymous reports remain signals, not confirmed strategy. Done when every surfaced event has "why it matters" and confidence.

6. Deliver the digest or stay silent

Report per event: company, event, date, evidence links, what changed, why it matters, confidence, and follow-up watch. When there are no material events, stay silent unless a periodic all-clear was requested. Done when the state file reflects this run and the digest (if any) cites primary sources.

Before sending, use `prepare <event-id>...` and durably attach that pending checkpoint. Send only after the attachment succeeds. After confirmed delivery, use `ack <event-id>... --receipt <actual-receipt>` and persist again. A timeout or pending event on restart is uncertain delivery: inspect the task/conversation receipt before retrying; never automatically resend. `ack` records the receipt, it does not independently authenticate it. Repeated collection preserves pending and delivered events; a failed source never advances its cursor. Report persistent source failures as coverage gaps when actionable, not as material