change-detection-monitoring v1.0.0

name: change-detection-monitoring description: "Set up web monitoring that catches the changes that matter without spamming: pick targets, fetch and diff strategies, filters, alert routing, and false-positive control for web pages, JSON APIs, and PDFs. Use when someone asks to watch a page for changes, monitor prices or restocks, track a changelog, detect site defacement, or asks how to do change detection well."

Change Detection Monitoring

Purpose

Turn "tell me when this page changes" into a monitor that fires only when something meaningful happens. The full loop: what to watch, how to fetch it, how to narrow the signal, how to compare snapshots, and how to route alerts. Naive page watchers fail at normalization and end up spamming on ads and timestamps until nobody reads them. This skill prevents that.

Workflow

1. Define the change worth knowing. Ask the user to name it concretely: "the price drops below $400", "this paragraph changes", "any change outside the news feed". If the answer is just "any change", push for a narrower target. Whole-page watches are the noisiest.
2. Pick the watch target. Options: a CSS or XPath selector for an element, a JSONPath/jq expression for an API-driven page, a PDF (text or checksum), or a screenshot for layout watching.
3. Choose the fetch method. Plain HTTP fetch for server-rendered pages (fast, cheap). Rendered fetch (Chrome/Playwright) for JS-heavy pages. Browser steps (log in, accept a cookie banner, fill a form) before the check when the content sits behind interaction.
4. Narrow the signal. Apply the selector, then add Ignore Text patterns for known churn (counts, timestamps, ads). Compare visible text, not raw HTML: markup-only churn like cache-busted filenames and CSRF tokens is harmless to a visible-text diff and poison to a raw-HTML one.
5. Choose the diff strategy. Text watches: hash the normalized text to detect change, then put a word-level before/after diff in the alert. Visual watches: mask dynamic regions, freeze animations, and set a mismatch threshold per page (critical pages tight, cosmetic pages loose). See references/diff-strategies.md.
6. Design the alert. Set a minimum change size so single-word noise stays quiet. Add conditional triggers: price above/below a number, keyword present or absent. Route through the right channel; changedetection.io fans alerts out to 80+ services (email, Discord, Slack, Telegram) via Apprise. Schedule checks: business hours only, or a foreign timezone, where the user chooses. Fetch failures get their own alert type: a dead site is not "no change".
7. Prove stability before trusting it. Run two or three checks against an unchanging page. If any fire, add ignore patterns or masks until they stop. A watch that fires on noise on day one trains everyone to ignore it by day three.
8. Hand over the runbook. The Output Contract below is the deliverable.

Output Contract

Deliver a monitoring plan with:

• The exact target: URL, selector or JSONPath, and the change definition in plain words.
• Fetch method and check interval or schedule.
• The normalization and ignore rules (what gets stripped, what counts as churn).
• The diff strategy and change-size threshold.
• Alert rules: conditions, destinations, and the before/after word diff format.
• A stability note: what the baseline checks showed and what was tuned out.
• For DIY setups, assets/page-watch.sh configured with the URL and ignore patterns.

Operating Rules

1. Never compare raw HTML. Normalize first: strip script and style tags, drop dynamic ids, collapse whitespace, keep visible text. Hash the normalized text.
2. Every watch ships with an ignore list. A watch with no noise control is a future false-positive report.
3. Alerts carry the word-level before/after diff, not just a URL. An alert readable without opening the site keeps getting read.
4. Treat "selector matched nothing" and "fetch failed" as failures, never as silence. A monitor that goes quiet when the site redesigns is worse than no monitor.
5. One watch, one job. Price watching and content watching on the same URL are separate watches with separate selectors, thresholds, and alert rules.
6. Re-verify tool claims before recommending specific products. This skill recommends approaches by category (browser extension, self-hosted, hosted service); name a product only when its feature is verified from its docs.