Set up a product price monitor

How to use

Don't use this for one-off "what does this cost right now" lookups; use web_search or web_extract directly instead.

Setup runs once in the foreground; the recurring check runs as a cronjob tick, which the price-watch automation blueprint scaffolds.

Record the source URL/provider, product or listing ID where available, variant, quantity, location, dates, travelers or guests, membership/login assumptions, condition, seller, and acceptable substitutes — the item is pinned when two variants cannot be confused.

Specify the currency, all-in versus pre-tax price, maximum price, availability or stock rule, shipping, refundability, cabin/room/ticket class, cooldown, and notification destination; the rules are set when synthetic examples have deterministic alert decisions.

Establish a live baseline first, then schedule.

Fetch a bounded live result with web_extract or browser_navigate and record retrieval time, source price, fees and taxes, availability, and terms. Do not schedule until one foreground fetch works. Write the watch contract — item, condition, and baseline observation — to a state file under ~/.hermes/price-watches/<watch-slug>.json, then create the job.

cronjob(action="create",
        schedule="every 6h",
        prompt="Load the product-price-monitor skill and run the tick for the watch contract at ~/.hermes/price-watches/<watch-slug>.json.",
        deliver=<user's destination>)

Pick a cadence that respects rate limits and site terms; the job exists when the baseline matches the exact item contract.

When a condition is met, the alert includes the exact item and variant, observed all-in price and source currency, availability and terms, threshold, retrieval timestamp, source link, and important uncertainty, but never claims inventory is reserved. When nothing qualifies, stay silent — no "still watching" noise unless a periodic all-clear was requested.

Avoid mistakes like comparing a base fare with an all-in threshold, alerting on the wrong size, seller, cabin, dates, or room terms, overwriting a last-known-good value with an error page, polling aggressively enough to trigger blocking or violate site terms, and scheduling before a single foreground fetch has succeeded.

Alert on threshold entry, qualifying availability, a material lower price, or recovery as requested, making the decision deterministic against stored state.

A failed fetch means unknown state: report or skip it, but never overwrite the last good observation with an error page.

When re-fetching the source, a failed fetch means unknown state: report or skip it, but never overwrite the last good observation with an error page.

Done when the state file reflects the run.

Before finishing, check that the watch contract pins the item so two variants cannot be confused, that one foreground fetch succeeded before any job was created, that alert decisions replay deterministically from the state file with duplicates suppressed, that failed fetches never replaced last-known-good state, and that alerts carry all-in price, source currency, timestamp, and source link.

Exclude volatile page metadata, and mark an observation as failed when it is not comparable to the baseline.

Store the last good observation and last alert fingerprint in the state file; replaying the same offer must send no second alert, so respect the cooldown.

An observation is done when it is comparable to the baseline or explicitly marked failed.

Separate base price, mandatory fees, shipping and taxes, total, and availability, and convert currency only with a timestamped rate while retaining the source currency; exclude volatile page metadata.