Buy smarter

Check price history, stack coupons, compare the real total, and track return and warranty dates.

Install the 6 skills below in order, one at a time. Each block is one complete install prompt. After the last skill, list each skill with its trigger phrases.

===== SKILL 1 OF 6: Price History Checker =====

Install the "Price History Checker" skill. Its full source is
below. Create it at
~/workspace/skills/price-history-checker/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: price-history-checker
description: Answer "is this a good price?" from price history and the user's receipts. Give the historical low, the average, and a buy-or-wait verdict. Trigger phrases: "is this a good price", "should I buy this now", "check the price history", "log this receipt", "what do I usually pay for this".
---
# Purpose

Strikethrough prices lie. This skill checks what an item has
actually sold for over time and gives a buy-now-or-wait
verdict grounded in that history. It also keeps a price log
from the user's receipts. The log shows what the user paid
for staples, such as groceries.

# Workflow

1. Ask the user for the product link or exact model name.
   If the user shares a receipt, go to step 6.
2. Find price history: camelcamelcamel-style trackers for
   Amazon items, manufacturer price pages, and recent sold
   listings for marketplace items.
3. Record: current price, 90-day average, historical low and
   when it hit it, and any predictable sale pattern (Prime
   Day, Black Friday, model refresh).
4. Verdict rules:
   - At or near historical low: "buy"
   - Within 10% of average with no pattern: "fair: buy if
     you need it now"
   - Above average with a known sale window within 60 days:
     "wait"
5. Report in the Output Contract shape.
6. Record the receipt in ~/workspace/price-log.md. For each
   item, write the item name, store, date, size, and price
   paid. Create the file if it does not exist.
7. Use one name for each item and one name for each store.
   If an item already has a different name in the log, use
   the name in the log.
8. Calculate one unit price for each item: per pound for
   weight, per fluid ounce for liquid, or per count. Use the
   same unit for all entries of one item.
9. For a multi-buy deal, such as "2 for $5" or buy one get
   one, record the price of one unit.
10. For a discount on a separate receipt line, subtract the
    discount from the price of that item.
11. If a unit price is far outside the logged range for the
    item, ask the user to confirm it before you record it.
12. When the user asks about an item, read the log first. If
    the log has no entry for the item, say so. Then go to
    step 2.
13. If the log has entries for the item, compare the current
    unit price to the logged unit prices. The usual range is
    the lowest and highest unit price in the last 5 entries.
    Give the store with the lowest price.
14. Give a verdict from the log:
    - At or below the lowest logged price: "buy"
    - Inside the usual range: "fair"
    - Above the usual range: "wait"

# Output Contract

- Verdict (for a price check only): buy, fair, or wait, one
  word, then one line why
- Price history: current, 90-day average, historical low
  (with date), sale pattern if any. For a logged item: the
  lowest logged price, the usual range, and the store with
  the lowest price.
- Log update (for a receipt only): the items added, the unit
  price of each item, and each new lowest price
- Caveats: thin history, refurbished vs. new mismatch, or
  regional pricing differences

# Operating Rules

- History comes from trackers and sold listings, not from
  the merchant's "was" price. Say the source.
- "Wait" needs a reason: a dated sale window or a pattern,
  not vibes.
- Thin history gets a caveat, not a confident verdict. A
  logged item with fewer than 3 entries has thin history.
- Receipt prices come only from receipts the user shares.
  Never invent a price or a past purchase.
- If the size is missing, ask for it. Do not compare unit
  prices without a size.
- Keep the log in ~/workspace/price-log.md only. Never send
  the log or a receipt to anyone.
- Read only on the web. Never buy, never sign up for price
  trackers.

===== END OF SKILL 1 OF 6 =====

===== SKILL 2 OF 6: Price Drop Watcher =====

Set up the "Price Drop Watcher" workflow. Its full source is below. Default schedule: daily
at 09:00 local time. Ask me to confirm or change this time before you create the recurring
job. Once I confirm, create the job and ask me for the first URL and target price to track.
Tell me the job name and the confirmed schedule when it is set up.

--- SOURCE ---
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.

===== END OF SKILL 2 OF 6 =====

===== SKILL 3 OF 6: Coupon Stacker =====

Install the "Coupon Stacker" skill. Its full source is below.
Create it at ~/workspace/skills/coupon-stacker/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: coupon-stacker
description: Before an online checkout, find stackable discount codes for the store and report the best working combo. Trigger phrases: "find coupons for this store", "any codes for checkout", "stack coupons for".
---
# Purpose

Never pay full price out of laziness. Before a checkout, the
skill hunts down discount codes for the store, figures out which
ones stack, and reports the best working combination.

# Workflow

1. The user names the store (and pastes the cart total if they
   want the math done).
2. Search public coupon sources for current codes: the store's
   own promotions page, newsletter signup discounts, and
   reputable coupon aggregators. Note each code's terms
   (minimum spend, exclusions, expiry).
3. Determine stacking: most stores allow one sitewide code plus
   category codes, or a student/military discount on top. Read
   the terms; don't assume.
4. Report in the Output Contract shape, ranked by total savings.

# Output Contract

- Store and cart total (if given)
- Codes found: one line each with terms and expiry
- Best combo: the codes to use together and the expected total
  savings
- Duds: codes that are expired or excluded, marked so the user
  doesn't waste time trying them

# Operating Rules

- Public sources only. Never use leaked, stolen, or
  employee-only codes.
- Never apply codes, check out, or enter payment details. Report
  only: the user pastes the codes themselves.
- If no working codes exist, say so in one line instead of
  listing dead ones.
- Never ask for a store login or account credentials.

===== END OF SKILL 3 OF 6 =====

===== SKILL 4 OF 6: Out-the-Door Cost Comparator =====

Install 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.

===== END OF SKILL 4 OF 6 =====

===== SKILL 5 OF 6: Return Window Tracker =====

Install 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.

===== END OF SKILL 5 OF 6 =====

===== SKILL 6 OF 6: Warranty Tracker =====

Set up the "Warranty Tracker" workflow. Its full source is
below. Default schedule: first of each month at 09:00 local
time. Ask me to confirm or change this time before you create
the recurring job. Once I confirm, create the job. Tell me the
job name and the confirmed schedule when it is set up.

--- SOURCE ---
name: warranty-tracker
description: Track product warranties from purchase receipts: what's covered, when coverage ends, and a ping 30 days before expiry. Trigger phrases: "track my warranties", "is this still under warranty", "warranty expiring soon".

schedule: monthly, first of the month at 09:00 local time. Confirm the time with the user before the first scheduled run.

trigger: the scheduled time, or a manual "track my warranties" request.

steps:
  1. Search the inbox for purchase receipts from the past 3 years (order confirmations, "your receipt", warranty registrations).
  2. For each significant purchase (over $75, or anything the user flags): item, purchase date, retailer, warranty length from the receipt or the manufacturer's standard terms.
  3. Compute expiry dates. Each run: report anything expiring within 30 days as "act now", within 90 days as "coming up".
  4. For expiring items: include the claim link or support page if known.
  5. Save the registry so new purchases get added and old ones age out.

output:
  - Expiring soon (30 days): item, expiry date, claim link
  - Coming up (90 days): item, expiry date
  - Registry: total items tracked, newest additions
  - Quiet months: "Nothing expiring this month."

rules:
  - Warranty lengths come from the receipt or published manufacturer terms. If unknown, say "terms unknown": never guess.
  - Read only. Never file a claim or contact a merchant.
  - The $75 threshold is a default. The user can change it.
  - Run only on the confirmed schedule or when asked.

===== END OF SKILL 6 OF 6 =====

Ready to copy.

Before you install

A shared skill carries somebody else's instructions. Read the source before you install it.
Never paste an API key, password, or token into anything a skill asks for. Legitimate skills use Muse's own secure flows.
Installing copies the setup into your own environment. It gives the author nothing.

Skills in this pack

Price History Checker
"Is this a good price?" answered from price history and your receipts, not the tag.
Tested in MuseskillShoppinginstructionsworkflowverdict-formatprice-log
by Muse Skills editors · Written for this directory
ViewInstall the "Price History Checker" skill. Its full source is below. Create it at ~/workspace/skills/price-history-checker/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: price-history-checker description: Answer "is this a good price?" from price history and the user's receipts. Give the historical low, the average, and a buy-or-wait verdict. Trigger phrases: "is this a good price", "should I buy this now", "check the price history", "log this receipt", "what do I usually pay for this". --- # Purpose Strikethrough prices lie. This skill checks what an item has actually sold for over time and gives a buy-now-or-wait verdict grounded in that history. It also keeps a price log from the user's receipts. The log shows what the user paid for staples, such as groceries. # Workflow 1. Ask the user for the product link or exact model name. If the user shares a receipt, go to step 6. 2. Find price history: camelcamelcamel-style trackers for Amazon items, manufacturer price pages, and recent sold listings for marketplace items. 3. Record: current price, 90-day average, historical low and when it hit it, and any predictable sale pattern (Prime Day, Black Friday, model refresh). 4. Verdict rules: - At or near historical low: "buy" - Within 10% of average with no pattern: "fair: buy if you need it now" - Above average with a known sale window within 60 days: "wait" 5. Report in the Output Contract shape. 6. Record the receipt in ~/workspace/price-log.md. For each item, write the item name, store, date, size, and price paid. Create the file if it does not exist. 7. Use one name for each item and one name for each store. If an item already has a different name in the log, use the name in the log. 8. Calculate one unit price for each item: per pound for weight, per fluid ounce for liquid, or per count. Use the same unit for all entries of one item. 9. For a multi-buy deal, such as "2 for $5" or buy one get one, record the price of one unit. 10. For a discount on a separate receipt line, subtract the discount from the price of that item. 11. If a unit price is far outside the logged range for the item, ask the user to confirm it before you record it. 12. When the user asks about an item, read the log first. If the log has no entry for the item, say so. Then go to step 2. 13. If the log has entries for the item, compare the current unit price to the logged unit prices. The usual range is the lowest and highest unit price in the last 5 entries. Give the store with the lowest price. 14. Give a verdict from the log: - At or below the lowest logged price: "buy" - Inside the usual range: "fair" - Above the usual range: "wait" # Output Contract - Verdict (for a price check only): buy, fair, or wait, one word, then one line why - Price history: current, 90-day average, historical low (with date), sale pattern if any. For a logged item: the lowest logged price, the usual range, and the store with the lowest price. - Log update (for a receipt only): the items added, the unit price of each item, and each new lowest price - Caveats: thin history, refurbished vs. new mismatch, or regional pricing differences # Operating Rules - History comes from trackers and sold listings, not from the merchant's "was" price. Say the source. - "Wait" needs a reason: a dated sale window or a pattern, not vibes. - Thin history gets a caveat, not a confident verdict. A logged item with fewer than 3 entries has thin history. - Receipt prices come only from receipts the user shares. Never invent a price or a past purchase. - If the size is missing, ask for it. Do not compare unit prices without a size. - Keep the log in ~/workspace/price-log.md only. Never send the log or a receipt to anyone. - Read only on the web. Never buy, never sign up for price trackers.
Price Drop Watcher
Checks your saved product URLs daily and tells you only when a price drops below target.
Tested in MuseworkflowShoppingscheduleworkflowurl listalerts
by Muse Skills editors · Written for this directory
ViewSet up the "Price Drop Watcher" workflow. Its full source is below. Default schedule: daily at 09:00 local time. Ask me to confirm or change this time before you create the recurring job. Once I confirm, create the job and ask me for the first URL and target price to track. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- 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.
Coupon Stacker
Before checkout, finds stackable codes and the best combo.
Tested in MuseskillShoppinginstructionsworkflowcode-testing
by Muse Skills editors · Written for this directory
ViewInstall the "Coupon Stacker" skill. Its full source is below. Create it at ~/workspace/skills/coupon-stacker/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: coupon-stacker description: Before an online checkout, find stackable discount codes for the store and report the best working combo. Trigger phrases: "find coupons for this store", "any codes for checkout", "stack coupons for". --- # Purpose Never pay full price out of laziness. Before a checkout, the skill hunts down discount codes for the store, figures out which ones stack, and reports the best working combination. # Workflow 1. The user names the store (and pastes the cart total if they want the math done). 2. Search public coupon sources for current codes: the store's own promotions page, newsletter signup discounts, and reputable coupon aggregators. Note each code's terms (minimum spend, exclusions, expiry). 3. Determine stacking: most stores allow one sitewide code plus category codes, or a student/military discount on top. Read the terms; don't assume. 4. Report in the Output Contract shape, ranked by total savings. # Output Contract - Store and cart total (if given) - Codes found: one line each with terms and expiry - Best combo: the codes to use together and the expected total savings - Duds: codes that are expired or excluded, marked so the user doesn't waste time trying them # Operating Rules - Public sources only. Never use leaked, stolen, or employee-only codes. - Never apply codes, check out, or enter payment details. Report only: the user pastes the codes themselves. - If no working codes exist, say so in one line instead of listing dead ones. - Never ask for a store login or account credentials.
Out-the-Door Cost Comparator
Compares the all-in cost of one item across stores: price plus tax, shipping, and fees.
Tested in MuseskillShoppinginstructionsworkflowoutput contract
by Muse Skills editors · Written for this directory
ViewInstall 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.
Return Window Tracker
Logs your purchases, computes each return deadline, and warns you before it passes.
Tested in MuseskillShoppinginstructionsworkflowreturn-ledger
by Muse Skills editors · Written for this directory
ViewInstall 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.
Warranty Tracker
Logs purchase dates and warranty windows; pings before they expire.
Tested in MuseworkflowMoney & financeinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet up the "Warranty Tracker" workflow. Its full source is below. Default schedule: first of each month at 09:00 local time. Ask me to confirm or change this time before you create the recurring job. Once I confirm, create the job. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- name: warranty-tracker description: Track product warranties from purchase receipts: what's covered, when coverage ends, and a ping 30 days before expiry. Trigger phrases: "track my warranties", "is this still under warranty", "warranty expiring soon". schedule: monthly, first of the month at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "track my warranties" request. steps: 1. Search the inbox for purchase receipts from the past 3 years (order confirmations, "your receipt", warranty registrations). 2. For each significant purchase (over $75, or anything the user flags): item, purchase date, retailer, warranty length from the receipt or the manufacturer's standard terms. 3. Compute expiry dates. Each run: report anything expiring within 30 days as "act now", within 90 days as "coming up". 4. For expiring items: include the claim link or support page if known. 5. Save the registry so new purchases get added and old ones age out. output: - Expiring soon (30 days): item, expiry date, claim link - Coming up (90 days): item, expiry date - Registry: total items tracked, newest additions - Quiet months: "Nothing expiring this month." rules: - Warranty lengths come from the receipt or published manufacturer terms. If unknown, say "terms unknown": never guess. - Read only. Never file a claim or contact a merchant. - The $75 threshold is a default. The user can change it. - Run only on the confirmed schedule or when asked.