Anysite Monitor

---
name: anysite-monitor
description: >-
  Build and run recurring monitoring on the Anysite MCP, delivering ONLY new or
  changed items each run by diffing against a persistent "seen ledger". Owns the
  onboarding: interviews the user about the decision the monitor should support,
  then searches the live Anysite catalog for endpoints that serve it, verifies
  each with a real call, and compiles them into a self-contained monitor config.
  No preset source list — sources are discovered per monitor. Use whenever
  someone wants to monitor, track, watch, configure monitoring, or get daily or
  weekly updates on anything Anysite can reach — companies, people, jobs, pricing
  pages, posts, news, reviews, listings, prices — e.g. "monitor X every day", "track changes in",
  "only show me what's new", "alert me when", "set up a recurring check",
  "help me configure monitoring", "настроить мониторинг", "мониторить конкурентов",
  "отслеживать изменения", "только новое", "раз в день".
  Also use it when a saved monitor fires on a schedule. For accounts that live in
  a connected CRM, prefer anysite-crm-signals (it writes signals back to the CRM);
  this skill covers everything outside the CRM and any non-account target.
---

# Anysite Monitor

A one-shot Anysite call answers *"what is the state right now?"*. This skill
answers the harder question — **"what changed since I last looked?"** — by
keeping a **seen ledger** of fingerprints in durable storage, subtracting it from
each fresh fetch, and reporting only what's new or edited.

Two things make a monitor good, and both are decided at setup, not at runtime:

1. **The right sources.** This skill ships **no catalog**. Anysite has 566
   sources and they change; a baked-in list rots and quietly points monitors at
   endpoints that no longer do what their name suggests. Instead, onboarding
   searches the live catalog for the user's actual goal, verifies each candidate
   with `discover` + one probe call, and compiles verified specs into the config.
2. **State that survives.** Each scheduled run is a fresh session with no memory.
   Anysite's request cache does persist for 7 days across sessions (find old
   cache_keys with the free `search_requests`), but it is a cache of fetches, not
   a report state — 7-day retention is shorter than the ledger's rolling window,
   and it can't record what was already *reported*. So the ledger must sit in
   external storage a headless run can reach by token — OR, for daily-or-faster
   monitors with stable-id sources, run **ledgerless** (`ledger_mode:
   "cache_diff"`): diff each fetch against the prior runs' fetches still in that
   7-day cache. Zero storage and no persist step, at the price of no long memory
   and silent loss after a failed delivery — mode selection rules in
   `references/storage-backends.md`.

## Two modes

- **Setup mode** — the user wants to create or change a monitor. Interview,
  discover sources, compile the config, register the schedule, seed the baseline.
- **Run mode** — a scheduled task fired with a config in its prompt. Load ledger,
  execute the config's sources, diff, deliver, persist. If the incoming prompt
  already contains a monitor config, you are in Run mode — skip the interview.

## Core concepts

- **Fingerprint** — a stable id for one item, chosen from the endpoint's real
  `response_fields` (platform id/URN first, normalized URL only as fallback).
- **New / changed / seen** — new = fingerprint absent from the ledger; changed =
  present but its content hash differs (only for hashed sources like pricing
  pages); otherwise suppress.
- **Baseline** — on the first run everything looks new, so seed the ledger
  silently and report one line: "monitoring initialized, tracking N items across
  M sources". Real deltas start at run two. (`initial_snapshot` overrides.)
- **Rolling window** — drop fingerprints unseen for `retention_days` (default 45)
  so the ledger stays bounded.

## Setup workflow

Follow `references/onboarding.md` — it is the playbook, not a summary. The arc:

1. **Decision first.** "What will you do differently when this fires?" Then
   targets as resolvable handles (domain, slug, subreddit, URL), cadence,
   delivery, volume tolerance.
2. **Signals.** Restate the goal as testable signals: what item appears, and what
   makes it worth reporting.
3. **Sources — discovered, never assumed.** Per `references/source-discovery.md`:
   find candidates → `discover(source, category)` for exact params and
   `response_fields` → one small `execute` probe on a real target → record the
   verified spec. Two equally valid ways to find candidates: **MCP-only** (the
   tools self-enumerate — a bogus source/category/endpoint returns
   `available_sources` / `available_categories` / `available_endpoints`, free) or
   **catalog grep** (`docs.anysite.io/llms-full.txt` via shell, adds keyword
   search over descriptions). Use whichever the surface allows; never fetch the
   12 MB `openapi.json`. **Read the params for a time filter** (`posted_after`,
   `date_posted`, `time_filter`…) and use it when present.
4. **Size it out loud.** `targets × signals` calls per run, × cadence × 30 for the
   month. Trim here, before the schedule exists.
5. **Pick the state mode, then check the run surface.** Cadence ≤ 2 days +
   stable-id sources + digest-tolerance → offer `ledger_mode: "cache_diff"`
   (no storage, no persist; state the trade-off out loud). Otherwise ledger,
   backend per `storage-backends.md`. For ledger mode also verify: can the
   scheduled run reach a shell, Python, and this skill's `scripts/`? Test during
   the dry run; if not, record `"diff_mode": "in_session"` so the run doesn't
   discover it at 7 a.m.
6. **Agree, dry-run, register, baseline.** Show the monitor in plain language,
   invite correction, optionally execute one pass to show the real digest, then
   register the task and seed the ledger.

## Scheduling

The schedule must outlive the session. **Do not use `CronCreate`/`CronList`** —
those are session-scoped (and expire in days). Use the host's durable
scheduled-task tools; in Cowork/Claude Code Remote these are `create_trigger`,
`update_trigger`, `list_triggers`, `delete_trigger` (load via ToolSearch if
deferred).

**Verify the tools exist before promising a schedule.** If none is available in
the current surface, do not fake it: finish the config, run the baseline, hand the
user the config plus a one-line instruction for creating the scheduled task
themselves in the UI, and say plainly that the schedule is not registered yet.

The task prompt must be a self-contained Run-mode instruction: "Invoke the
anysite-monitor skill in Run mode with the config below" + the config JSON +
the ledger JSON as a **separate block**. Store the returned id in
`monitor.trigger_id`. Set the task's `notifications` per the chosen delivery.

## Run workflow

**`ledger_mode: "cache_diff"`?** Different loop, no ledger and no persist:
find prior fetches via `search_requests` (match endpoint + target handle, last
7 days), union their id sets via `query_cache`, diff the current fetch against
the union in-session, deliver; the current fetch's cache entry is next run's
history. No prior fetches → baseline (fetch + one-line init). Full recipe in
`references/storage-backends.md`. Everything below is the ledger-mode loop.

1. **Load** config and ledger (backend per `references/storage-backends.md`). No
   ledger → baseline run.
2. **Collect.** For each entry in `config.sources`, `execute` exactly what the
   spec says, capped by `max_items`. No re-discovery, no improvisation: if a
   source errors, note it and continue (fail soft, never abort the digest).
   **Time window:** if the spec has a `time_filter`, convert `last_ok_run` into
   its value per `source-discovery.md` (unix_ts → minus one cadence of overlap;
   enum → smallest bucket covering the gap). **On a baseline run there is no
   `last_ok_run`** — use a deliberate seed window instead: for enum filters the
   smallest bucket that matches the cadence (daily monitor → `day`/`past-24h`),
   for unix_ts `now − 7 days`, and cap by `max_items`. Say the seeded window in
   the init line, because anything older than it will surface as "new" on run 2.
3. **Diff deterministically.** Shape items into
   `{fingerprint, content?, label, url}` and run:
   `python3 scripts/ledger.py diff --ledger <file> --items <file> --today <YYYY-MM-DD> --retention-days <n> [--baseline]`.
   It normalizes URLs, hashes content, buckets new/changed/seen, applies the
   rolling window and returns the updated ledger. Don't hand-roll the diff — the
   whole point is that every run diffs identically.
   **If the surface has no shell or no Python** (or the skill's `scripts/` isn't
   available where the trigger fires — verify this at setup, not at 7 a.m.), fall
   back to diffing in-session, following exactly the rules the script implements:
   normalize URLs (lowercase host, strip `utm_*`/`fbclid`/`gclid`/`ref`, drop
   fragment and trailing slash), compare fingerprints against `ledger.items`,
   treat a differing content hash as *changed*, stamp `s` = today for everything
   seen, drop entries older than `retention_days`. Note in the digest that the
   fallback diff was used — it is the one step where drift can creep in.
4. **Persist, then deliver.** Write the ledger back *before* sending the digest:
   a run that reports deltas and then fails to save them repeats them next time.
   Stamp `last_ok_run` only on a successful write; if it lags `last_run`, say so
   in the digest so repeats are explained. Recovery aid: `search_requests` (free)
   can locate the previous run's fetches and their cache_keys for up to 7 days —
   useful to reconstruct what a failed-persist run had already reported, or to
   skip refetching a source this run already pulled.
5. **Deliver** per the digest format below.

### Digest format

Group by target, then signal. Lead with counts so the reader can triage.

```
📡 <Monitor name> — <date>
<N> new · <C> changed since last run

## <Target A>
### New job postings (2)
- Senior ML Engineer, Berlin — posted <date> — <url>
- Head of Sales, Remote — posted <date> — <url>
### Pricing change (1)
- Pro plan $99 → $79/mo — <url>

_No changes for: <Target B>, <Target C>_
_Source "<name>" returned an error this run — skipped._
```

Nothing new is a valid result: say it in one line. Match the channel — email can
be rich markdown, Telegram/Slack should be tighter. Honour `focus` when set.

## Guardrails

- **Cost.** `discover` and catalog greps are free; `execute` is not. Never
  re-fetch history you've already fingerprinted, use time filters where they
  exist, and keep `max_items` tight.
- **Window overflow.** If a source returns exactly `max_items` new items, the
  window may have overflowed and items were missed — warn in the digest and
  suggest a tighter cadence or a higher cap. Silent loss is worse than noise.
- **Stable fingerprints.** Prefer platform ids over URLs; normalize URLs. An
  unstable fingerprint turns the monitor into a spam machine on run two.
- **Hash meaning, not markup.** For pages, hash the extracted plan names/prices
  or feature list — never raw HTML (nav, banners and tokens change constantly).
- **cache_diff discipline.** Ledgerless mode is only as good as the cache
  window: if the gap since the last fetch approaches 7 days, re-seed quietly
  instead of flooding, and never sell this mode for must-not-miss monitoring.
- **No dead ends on discovery.** If the shell or the docs fetch is unavailable,
  the MCP self-enumeration path (`available_sources` / `available_categories` /
  `available_endpoints`) covers the same ground for free — never abandon a signal
  because one browsing route was blocked.
- **Headless reality.** Only depend on hosted, token-authenticated tools. Anything
  proxied through the user's desktop is unavailable when their laptop is closed.
- **People data.** Monitoring individuals' activity is personal-data processing:
  keep it to what the stated decision needs, and don't quietly widen it.

## Reference files

- `references/onboarding.md` — the Setup-mode interview playbook.
- `references/source-discovery.md` — how to find and verify sources in the live
  catalog, and how to pick fingerprints and time filters from `discover` output.
- `references/config-schema.md` — monitor config (incl. verified `sources[]`
  specs) and ledger schema.
- `references/storage-backends.md` — backend selection and read/write recipes.
- `scripts/ledger.py` — deterministic diff, hashing, URL normalization, rolling
  window.