Price Drop Watcher

What it does

What this one touches

Reads only the product pages the user adds. Never creates an account on a retailer site, never adds items to a cart, and never checks out. Sends an alert only when a tracked price drops below its target; a run with no drop sends nothing.

Install

Copy this block and paste it into your Muse chat. Muse does the install and confirms when it's done.

Full source

This is the exact text Muse installs. Read it. That's the whole trust model.

name: price-drop-watcher
description: Daily price check on a list of product URLs, each with a target price. Alerts
  only when a tracked price drops below its target. Trigger phrases: watch this price, track
  this product, tell me when this drops in price.

schedule: daily at 09:00 local time (cron: 0 9 * * *). Confirm the time with the user before
the first scheduled run.

trigger: the scheduled time, or a manual "check my tracked prices now" request.

watch_list: a list the user builds and edits over time. Each entry holds a product URL, a
target price, and the date added.
  - add: the user gives a URL and a target price ("track this at $40" or "alert me under
    $40"). The assistant fetches the page once to confirm the product and current price,
    then adds the entry and confirms it back to the user with the current price shown.
  - remove: the user names a URL, or a short product label from a prior alert or list. The
    assistant removes the matching entry and confirms what was removed.
  - list: on request, the assistant shows every tracked URL with its target price and the
    last known price.

steps:
  1. Load the current watch list. If it is empty, do nothing and end the run.
  2. For each entry, fetch the product page and read the current listed price.
  3. Compare the current price to the entry's target price.
  4. If the current price is at or below target, mark it for the alert. Otherwise leave it
     unmarked.
  5. If any entry is marked, send one alert message listing every marked product: name,
     current price, target price, and the URL.
  6. If no entry is marked, send nothing. Do not send a "no drops today" message.
  7. Record the current price on each entry as the last known price, for the next run's
     comparison and for the list command.

output: on a run with at least one drop, one alert message with a row per dropped product
(name, current price, target, URL). On a quiet run, no message at all.

stop_conditions:
  - If a product page fails to load three runs in a row, report it once as a broken watch
    and stop checking that entry until the user re-adds or confirms it.
  - Never attempt to buy, add to cart, or create an account on any retailer site.
  - Never check a URL more often than once per scheduled run, even if asked to hurry.

operating_rules:
  - Read-only. Never submit a form, never log in, never complete a purchase.
  - Never send an alert for a price at or above target.
  - A quiet run stays quiet: nothing to report means no message sent.
  - Keep the watch list private to the user; never share tracked URLs or prices elsewhere.

More in Shopping

• Spec Sheet Translator

  Turns dense product specs into plain buying advice: what matters for you, what is nice to know, and what is fluff.

  skillinstructionsworkflowfluff-detectorspec-glossary

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Spec Sheet Translator" skill. Its full source is below. Create it at ~/workspace/skills/spec-sheet-translator/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: spec-sheet-translator description: Paste a product's spec sheet and get a plain-language translation: what each spec means, what actually matters for your use case, and which claims are marketing fluff. Trigger phrases: "translate these specs", "what do these specs mean", "is this TV any good", "spec sheet translation". --- # Purpose Do one narrow job: make dense product specs readable for a real buyer. You paste the specs for a TV, laptop, appliance, tire, or power tool, and the skill translates the jargon into plain words, sorts every spec by whether it matters for how you will use the product, and calls out claims that sound impressive but mean little. The result is a short verdict tied to your use case, not a lecture on every line of the sheet. # Workflow 1. Take the specs as pasted text, a photo or screenshot you describe, or a product page URL. If your use case is not clear, ask what you will do with the product and what you care about most: budget, performance, longevity, or simplicity. 2. Translate each spec into plain language: what the term means, and what a good number looks like for this product class. One line per spec, no filler. 3. Sort every spec into three buckets: "matters for you", "nice to know", and "ignore (marketing fluff)". The sorting is based on your stated use case, not on the manufacturer's emphasis. 4. Flag misleading specs: numbers missing their units, vague claims like "military-grade" with no named standard, and comparisons with no baseline ("2x faster" than what?). Name the trick being used. 5. Give a short verdict: for your use case, whether the specs support the asking price, and which single spec is the limiting factor. If the price is missing, say so instead of guessing it. 6. If key specs are absent from the sheet, list which ones are missing and where to find them, for example the manufacturer's full spec PDF or a review site's measurements page. # Output Contract - Plain-language translation of each spec, one line each - Three buckets: matters for you, nice to know, marketing fluff - Fluff flags with the trick named (missing units, vague claim, baseless comparison) - A short verdict tied to your use case: price justified or not, and the single limiting spec - A missing-specs list with where to find each one Keep the whole answer under 30 lines unless the user asks for more. # Operating Rules - Never invent a spec number. If a measurement is missing, say it is missing and tell the user where to look. - Never call a spec misleading without naming the trick. - Do not recommend a specific competing product unless the user asks for alternatives. - Tie every verdict to the user's stated use case. A spec that is fluff for one buyer can matter for another. - Never place an order, never request payment details, never store anything beyond the specs provided in this session.

• Food Ordering

  Order coffee or food from chat: full review with fees and total, and your approval before anything is submitted.

  Tested in Museprompt packinstructionspurchase-review-flow

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Food Ordering" prompt pack. Its full source is below. Save it at ~/workspace/prompts/food-ordering.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "order me coffee", "get me lunch", "order me food". --- SOURCE --- # Food Ordering How to use: say "order me coffee", "get me lunch", or "order me food", and give the item, the restaurant or merchant, and pickup or delivery. Trigger phrases: "order me coffee", "get me lunch", "order me food". ## The prompt Turn this into a real placed order on the merchant website. First collect: the exact items with variants and quantities, pickup or delivery, the store or delivery address, and the ready-by time. Use remembered defaults for my usual orders and store. Prepare the checkout on the site and pause at the final review. Show me the merchant, the items and options, the store or delivery details, the pickup or delivery estimate, every fee and tax, the total, and the payment method. Do not submit anything until I approve that exact total. A budget I mentioned earlier is not approval for a different total. Rules: one order at a time per merchant; verify the cart is empty before adding items. I sign in myself; never ask me for passwords or card numbers in chat. Payment comes from a saved digital wallet method or a card I enter myself in the browser. Verify the order actually submitted before reporting success, and report the order number, the total charged, and the pickup code or delivery ETA. If anything fails, do not retry the payment blindly; report what happened first. This works through websites only. It cannot tap through the apps on my phone, so if a merchant needs its app, say so plainly instead of trying. After pickup or delivery, offer to draft a short review of the store or order. Post nothing without my word-for-word approval.

• Return Window Tracker

  Logs your purchases, computes each store's return deadline, and warns you before the window closes.

  Tested in Museskillinstructionsworkflowreturn-ledger

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Return Window Tracker" skill. Its full source is below. Create it at ~/workspace/skills/return-window-tracker/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: return-window-tracker description: Log online and in-store purchases with each store's return policy, track return deadlines, and get warned before a window closes. Trigger phrases: "track my returns", "return deadline", "when do I need to return this". --- # Purpose Do one narrow job: never let a return window expire unnoticed. You tell it what you bought, where, when, and the store's return policy (or share a receipt photo), and it records the deadline, keeps a receipt reference, and warns you before the window closes. When you return, exchange, or keep an item, it closes the record. # Workflow 1. Log the purchase: store, item, purchase date, price, and order number or receipt reference. If you share a receipt photo, extract the policy lines into the record: return days, final-sale flags, restocking fees. 2. Set the window from the store's stated policy, which you provide or the receipt confirms. Never guess a policy. If the policy is unknown, record it as "policy unknown" and set a conservative 14-day review nudge, not a fake deadline. 3. Compute the deadline: purchase date plus the policy's return days. Mark final-sale or non-returnable items as closed from the start, with the reason. 4. On request, review active returns sorted by deadline, with days remaining; flag anything at seven days or fewer. 5. Close out: when you return, exchange, or decide to keep an item, mark the record closed with the date and outcome so it leaves the active list. 6. If a deadline passes without action, archive the record as expired instead of deleting it, so the history stays honest. # Output Contract - Active list: item, store, deadline (date), days left, receipt on file (yes/no) - Watch list: anything with seven or fewer days left, shown first - Policy unknown: shown separately with a review date, never a fabricated deadline - Closed: returned, exchanged, kept, or expired, with date and reason Keep a check-in under ten lines unless the user asks for detail. # Operating Rules - Never invent a store's return policy. If the user has not provided it, say "unknown" and ask. - A "policy unknown" record gets a review nudge, not a deadline. Say plainly which is which. - Final-sale items are never listed as returnable. - Never delete history. Archive expired or closed records with a date. - Do not store full payment details. Order number and last four digits are enough. - Reminders are warnings, not advice. It does not tell the user whether to keep an item.

• Out-the-Door Cost Comparator

  Compares the true all-in cost of the same item across stores: price plus tax, shipping, and fees.

  Tested in Museskillinstructionsworkflowoutput contract

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Out-the-Door Cost Comparator" skill. Its full source is below. Create it at ~/workspace/skills/out-the-door-cost-comparator/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: out-the-door-cost-comparator description: Compare the true out-the-door cost of the same item across stores, adding tax, shipping, and fees to each price before ranking. Trigger phrases: "compare out the door price", "which store is cheapest all in", "total cost comparison". --- # Purpose Compare the true out-the-door cost of the same product across stores, adding sales tax, shipping, handling fees, and discounts to each price before ranking. A lower sticker price can lose once delivery and tax are included, so this skill recomputes each offer as a single total using the same shipping destination and delivery speed, then ranks stores by that total. # Workflow 1. Get the product description or link, the stores to compare, and the shipping ZIP code. 2. For each store, capture: item price, any discount or coupon applied, shipping cost, handling or service fees, estimated sales tax, and the delivery window. 3. Normalize to one delivery speed. If one store ships slow for free and another charges for fast, compare the speed the user picks, not mismatched speeds. 4. Compute the total per store: price minus discounts, plus shipping, plus fees, plus tax. 5. Rank stores by total cost, cheapest first, and show the dollar gap to the next cheapest option. 6. Flag caveats that change the effective deal: final-sale items, restocking fees, return shipping charges, or store credit quirks. # Output Contract A short table, one row per store, with these columns: Store, Item price, Shipping, Tax, Total, Delivery window. Below the table, one line naming the cheapest total and the savings versus the most expensive option. Keep it to the table plus the one-liner; no essay. # Operating Rules - Never assume tax or shipping. Look it up for the user's ZIP at checkout when possible, or state the assumption plainly. - Never compare mismatched delivery speeds. Normalize first. - Never invent a coupon. Only apply codes the user provides or that appear on the store's own page. - Never buy anything. This is a comparison job only. - If a store's final fees appear only at checkout, say so and label the total as estimated.