Suivi des changements de tarifs

# Pricing Page Change Monitor

Create a reviewed baseline for a small set of public pricing pages, schedule TinyFish monitors, and separate material packaging changes from harmless page noise.

## Loadout capabilities

Use <action-tag>api:tinyfish_api:fetch_urls</action-tag> to capture the current content and response metadata for every reviewed pricing URL. Use <action-tag>api:tinyfish_api:create_monitor</action-tag> only after the user approves the exact URLs, schedule, purpose, and any webhook destination. Use <action-tag>api:tinyfish_api:get_monitor</action-tag> to read back the stored monitor and its latest state. Use <action-tag>api:tinyfish_api:run_monitor</action-tag> for an approved on-demand check and <action-tag>api:tinyfish_api:update_monitor</action-tag> only to apply a separately reviewed schedule, webhook, name, purpose, pause, or resume change.

Read each current Action schema before preparing input. Confirm the TinyFish connection through Aident Vault and never request a raw credential. Preflight every create, run, or update call. Show the target monitor, persistence effect, and quoted cost or risk before asking for confirmation.

## Scope

Use this Skill for 1 to 10 public vendor pricing or packaging pages that the user names or approves. It is not a site-wide crawler, a contract monitor, or a promise of real-time alerts. Do not infer a competitor list, add URLs discovered during execution, or configure a webhook without explicit approval.

Collect the exact URLs, the products or plans to watch, the user's timezone, the desired cadence, and the changes that matter. Material changes usually include plan names, prices, billing periods, usage allowances, feature limits, trials, discounts, enterprise gates, or availability. Ignore cosmetic layout, navigation, cookie banners, rotating testimonials, and timestamp-only changes unless the user says otherwise.

## Baseline

1. Normalize each approved URL without replacing it with a different locale, region, or campaign variant.
2. Fetch the URLs in markdown with page metadata and `include_etag_and_last_modified` when supported. Preserve retrieval time, final URL, ETag or Last-Modified value, and a short source excerpt for each material field.
3. Build a baseline table with one row per plan or offer: vendor, product, plan, price, currency, billing period, included usage, important limits, trial or discount, source URL, and observed time.
4. Mark inaccessible, login-gated, geo-variable, or JavaScript-incomplete pages as `Unverified`. Do not create monitors for them until the user approves an alternate public URL or a narrower verification method.
5. Show the baseline and the proposed monitor configuration before any persistent write.

## Create and verify monitors

After approval, create one URL monitor per approved page. Use a clear name and purpose that identify the vendor, product, region, and fields being watched. Convert the requested cadence to the provider's `schedule_cron` only after confirming how the provider interprets timezone. Omit `webhook_url` unless the user supplied and approved the exact HTTPS endpoint.

Read each returned monitor ID, then call the monitor read Action and verify the URL, schedule, status, purpose, and webhook match the approved configuration. A successful create response without this readback is not completion. If the user asked for an immediate sample, preflight and obtain approval for one on-demand run, execute it, and read the monitor again to inspect its recorded result.

## Interpret changes

Compare structured commercial facts, not raw page length. Classify each observed difference as:

- `Material`: a verified price, plan, entitlement, limit, trial, billing, or availability change.
- `Needs Review`: the page changed but the commercial meaning is ambiguous or evidence is incomplete.
- `Noise`: navigation, styling, legal footer, promotional rotation, or other non-commercial variation.

For every `Material` or `Needs Review` item, include the prior value, current value, exact source URL, observed time, and a short supporting excerpt. Never claim that a missing element was removed when the fetch was incomplete.

## Change control and recovery

Pause, resume, reschedule, rename, repurpose, or redirect a monitor only after showing the exact before-and-after configuration and obtaining approval. Never delete a monitor through this workflow. If a run fails, report the provider error and last verified monitor state; do not create a duplicate monitor as a retry. If the page redirects across regions or currencies, stop and ask which variant is authoritative.

## Output

Return the verified baseline, monitor IDs, read-back configuration, materiality rules, sample result if approved, and any unresolved page or timezone issue. Distinguish `Configured`, `Active`, `Paused`, `Run Requested`, and `Change Verified` precisely.