Product Price Monitor: Set Up Alerts for Flights, Hotels, and Listings

The Product Price Monitor skill watches a specific purchasable item, like a laptop, flight, hotel room, or ticket listing, and alerts you when the all-in price or availability matches a condition you define. You would reach for this when you want to stop manually refreshing a page and instead get a notification when the price drops below a threshold or a refundable room opens up. It is bundled with Hermes Agent, so it is available out of the box, and it is designed for recurring checks, not one-off lookups.

What it does

This skill turns a concrete shopping or travel goal into a scheduled, deterministic alert. You define the exact item, the alert condition, and a baseline observation, then a cron job runs every few hours to re-fetch the source, normalize the price and availability, and compare against the stored state. If the condition is met, it sends an alert with the all-in price, source currency, timestamp, and link. If nothing qualifies, it stays silent, so you are not spammed with "still watching" messages. The skill handles variants, taxes, fees, currencies, stock, cancellation terms, and duplicate alerts explicitly, so you can trust that the same offer will not trigger a second alert.

Before you start

This skill is bundled with Hermes Agent, so no separate installation is needed. It runs on Linux, macOS, and Windows. You will need a destination for alerts, such as a chat or email, configured in Hermes Agent. The setup runs once in the foreground, and the recurring check runs as a cronjob tick. The price-watch automation blueprint scaffolds this, but you can also create the job manually. You should have a concrete item in mind, with a URL or provider, and a clear idea of what price or availability condition matters to you.

Setup: define the item and condition

1. Define the exact item

Record the source URL or provider, the product or listing ID where available, the variant, quantity, location, dates, number of travelers or guests, any membership or login assumptions, condition, seller, and acceptable substitutes. The goal is to pin down the item so precisely that two variants cannot be confused. For example, if you are watching a laptop, specify the exact model, RAM, storage, and seller. If you are watching a flight, specify the dates, cabin class, and airline. This step is done when you could look at two different offers and immediately tell which one matches your watch.

2. Define the alert condition

Specify the currency, whether the price is all-in or pre-tax, the maximum price you are willing to pay, the availability or stock rule, shipping requirements, refundability, cabin or room class, cooldown period, and the notification destination. The condition is done when you can run through synthetic examples and get deterministic alert decisions. For instance, if the threshold is $1,000 all-in, a total just under that should alert, but a base price just under that with shipping on top should not, unless shipping is included in your definition.

3. Establish a live baseline, then schedule

Before scheduling anything, fetch a bounded live result using web_extract or browser_navigate. Record the retrieval time, source price, fees and taxes, availability, and terms. Do not schedule until this foreground fetch works. Then write the watch contract, which includes the item, condition, and baseline observation, to a state file under ~/.hermes/price-watches/.json. Finally, create the cron job with a command like this:

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 setup is done when the baseline matches the exact item contract and the job exists.

Tick: each scheduled run

4. Fetch and normalize

Each time the cron job fires, re-fetch the source. Convert currency only with a timestamped rate, and retain the source currency in the observation. Separate the base price, mandatory fees, shipping and taxes, total, and availability. Exclude volatile page metadata, like dynamic counters or session IDs. If the fetch fails, the state is unknown: report or skip, but never overwrite the last good observation with an error page. The step is done when the observation is comparable to the baseline or explicitly marked as failed.

5. Compare and suppress duplicates

Alert on threshold entry, qualifying availability, a material lower price, or recovery, as you requested. Store the last good observation and the last alert fingerprint in the state file. Replaying the same offer must not send a second alert, and the cooldown must be respected. The step is done when the alert decision is deterministic against the stored state.

6. Deliver or stay silent

When a condition is met, the alert includes the exact item and variant, the observed all-in price and source currency, availability and terms, the threshold, the retrieval timestamp, the source link, and any important uncertainty. Never claim inventory is reserved. When nothing qualifies, stay silent, unless you requested a periodic all-clear. The step is done when the state file reflects this run.

When not to use it

Do not use this skill for one-off "what does this cost right now" lookups. For those, use web_search or web_extract directly. This skill is for ongoing monitoring, not for answering a single question.

Limits and gotchas

• Comparing a base fare with an all-in threshold is a common mistake. Always compare like with like.
• Alerting on the wrong size, seller, cabin, dates, or room terms can happen if the item definition is not precise enough.
• Overwriting a last-known-good value with an error page is a risk. The skill explicitly avoids this, but you should be aware of it.
• Polling aggressively can trigger blocking or violate site terms. Choose a cadence that is respectful.
• Scheduling before a single foreground fetch has succeeded is a pitfall. Always verify the fetch works first.

Verification

To confirm your watch is set up correctly, 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 the all-in price, source currency, timestamp, and source link.

What pairs with this

The related skill is maps, which can help with location-based aspects of your watch, such as checking the distance to a hotel or the proximity of a pickup point. You can use it alongside the price monitor to add geographic context to your alerts.