Shopping

Gift ideas and price watching, with links, on the schedule you set.

13 of 13 skills

type

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
ViewInstall 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
ViewInstall 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
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.
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
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.
Recall Checker
Checks your owned products against CPSC recalls; flags anything dangerous.
Tested in Museskillinstructionsworkflowreport-format
by Muse Skills editors · Written for this directory
ViewInstall the "Recall Checker" skill. Its full source is below. Create it at ~/workspace/skills/recall-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: recall-checker description: Check products you own against CPSC recalls, what's been recalled, how serious it is, and what the remedy is. Trigger phrases: "check my products for recalls", "is this recalled", "any recalls on my stuff". --- # Purpose Recalls get announced and forgotten. This skill checks the products you own against the CPSC database and tells you what's been recalled, how serious the hazard is, and what the remedy looks like. # Workflow 1. Ask the user for the product list: brand, model, and approximate purchase date for the items they care about (appliances, kids' gear, power tools, and anything with a battery are the high-value categories). 2. Check each against CPSC recalls (cpsc.gov/Recalls). 3. For each hit: product, recall date, the hazard, how many incidents were reported, and the remedy (refund, repair, replacement) with the official link. 4. Rank by severity: injury-causing hazards first, then everything else. 5. Report in the Output Contract shape. # Output Contract - Recalled: one block per hit, product, hazard, incidents, remedy, official link - Clear: the items with no recall found, one line total - What to do: the remedy steps for the most serious hit # Operating Rules - CPSC data only for US products. Say so if the product is outside CPSC scope. - Severity comes from the recall notice (injuries reported), not from speculation. - Never file a claim for the user. Link the official remedy page and let them file. - "No recall found" is not a safety certificate. Say that once, plainly.
Restock Alert
Watches out-of-stock items and pings you the moment they're back.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet up the "Restock Alert" workflow. Its full source is below. Default schedule: every 6 hours. Ask me to confirm or change the cadence 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: restock-alert description: Watch out-of-stock products and alert the moment they're available again, with the price. Trigger phrases: "watch for restock", "tell me when this is back in stock", "alert me when available". schedule: every 6 hours. Confirm the cadence with the user before the first scheduled run. trigger: the scheduled time, or a manual "watch for restock" request with product links. steps: 1. Ask the user for the product links and the acceptable price (or "any price"). 2. Each run: check availability and current price for every watched item. 3. Alert rules: - Back in stock at or below the acceptable price: send the alert immediately with the link. - Back in stock above the acceptable price: report it once as "back but over your price" and keep watching. - Still out of stock: stay quiet. 4. After an alert is sent for an item, drop it from the watch list unless the user says otherwise. output: - Back in stock: item, price, link, one block per item - Back but over price: item, price vs. your max, one line - Still out: silence rules: - Read only. Never buy, never add to cart. - One alert per restock. No repeat pings for the same item. - The acceptable price is the user's. Ask once per item. - Run only on the confirmed cadence or when asked.
Dupe Finder
Name a product; get cheaper alternatives that don't suck.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "Dupe Finder" prompt pack. Its full source is below. Save it to ~/workspace/prompts/dupe-finder.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack finds cheaper alternatives ("dupes") for a product. Paste it into Muse along with the product name. > Find me cheaper alternatives ("dupes") for [product]. For > each alternative give: name, price, what it matches the > original on, and where it falls short, be honest about the > trade-offs. Rank by value, not by price alone. Rules: > (1) only suggest products with real reviews behind them, > no obscure no-name listings with 3 reviews, (2) say what > the original does better: if nothing cheaper comes > close, say so and tell me to buy the original, (3) no > counterfeits or knockoffs pretending to be the brand.
Price History Checker
'Is this a good price?' answered from history, not the strikethrough.
Tested in Museskillinstructionsworkflowverdict-format
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, not the strikethrough, historical low, average, and whether to buy now or wait. Trigger phrases: "is this a good price", "should I buy this now", "check the price history". --- # 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. # Workflow 1. Ask the user for the product link or exact model name. 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. # Output Contract - Verdict: buy, fair, or wait, one word, then one line why - Price history: current, 90-day average, historical low (with date), sale pattern if any - 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. - Read only. Never buy, never sign up for price trackers.
Coupon Stacker
Before checkout, finds stackable codes and the best combo.
Tested in Museskillinstructionsworkflowcode-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.
Fit Finder
Your measurements plus a brand: estimated size and watch-outs.
Tested in Museprompt packinstructionssize-template
by Muse Skills editors · Written for this directory
ViewInstall the "Fit Finder" prompt pack. Its full source is below. Save it at ~/workspace/prompts/fit-finder.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: "find my size", "check this brand's fit", "what size should I order". --- SOURCE --- # Fit Finder How to use: give your measurements, the brand, and the item (jeans, dress shirt, running shoes, whatever). It looks up the brand's size chart and tells you which size to order and what to watch for. Trigger phrases: "find my size", "check this brand's fit", "what size should I order". Save it as a reusable prompt pack named "Fit Finder". ## The prompt Help me pick a size. I will give you: my key measurements, the brand, and the item I want to buy. 1. Look up the brand's current size chart for this item. 2. Compare my measurements and name the size to order. If I fall between sizes, say so and recommend based on the item type (size up for structured jackets, down for stretch denim, state the rule you used). 3. Add brand-specific watch-outs: "runs small in the shoulders", "vanity sized, most people size down", "length runs long". Base these on the size chart and general fit reputation, not invented reviews. 4. If the item has fit variants (slim / regular / relaxed, or width options for shoes), say which variant suits my measurements. Rules: if you cannot find the brand's size chart, say so and give a best-effort estimate labeled as such. Never state a size as certain when it is a guess.
Gift Finder
Asks five questions about the recipient, then returns five gift ideas with links.
Tested in Museskillinstructionsinterview
by Muse Skills editors · Written for this directory
ViewInstall the "Gift Finder" skill. Its full source is below. Create it at ~/workspace/skills/gift-finder/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: gift-finder description: Interviews the user with five short questions about a gift recipient, then returns a shortlist of five gifts with a one-line reason and a buy link each. Never buys anything. Trigger phrases: "help me find a gift", "gift ideas for", "what should I get", "gift finder". --- # Purpose Turn five short answers about a person into a shortlist of five gift ideas, each with a reason and a link to research further. # Workflow 1. When the user asks for gift help, ask the five questions below, one at a time or as a short list, whichever the user prefers: 1. Relationship to you (partner, parent, friend, coworker, etc.) 2. Interests or hobbies 3. Budget (a number or a range) 4. Occasion 5. What they already have, or anything to avoid duplicating 2. If the user skips a question, proceed with what you have. Do not block on a missing answer more than once. 3. Using the five answers, generate a shortlist of 5 distinct gift ideas. Spread them across the stated budget rather than clustering at one price point. 4. For each idea, search for a real, currently available product using the assistant's own web search, and use the actual product page as the link. Do not invent a product name or a link. 5. If a good match cannot be verified as currently available, replace it with one that can, rather than listing it anyway. 6. Present the shortlist and stop. Do not add upsells, affiliate disclaimers, or an offer to buy. # Output Contract A numbered list of exactly 5 gifts, each formatted as: `<Gift name>: <one-line reason tied to the recipient's answers>: <link>` The reason names something specific from the interview (an interest, the occasion, or the budget), never a generic reason like "they'll love it." # Operating Rules - Never place an order, add to cart, or check out on any site. - Never ask for payment details, a shipping address, or an account login. - Never store the recipient's personal details beyond the current conversation. - Never invent a product, a price, or a link. Verify each with the assistant's own web search before including it. - Stay within the stated budget for every item on the list, unless the user asks for a stretch option.
Grocery List Builder
Name three or four meals; get one consolidated list grouped by aisle.
Tested in Museprompt packinstructionslist-template
by Muse Skills editors · Written for this directory
ViewInstall the "Grocery List Builder" prompt pack. Its full source is below. Save it at ~/workspace/prompts/grocery-list-builder.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: "build my grocery list", "organize my shopping list", "make a grocery list". --- SOURCE --- # Grocery List Builder How to use: list the meals you plan to cook this week, the number of servings for each, and any household staples you are low on. It returns one consolidated list grouped by store section, with quantities merged. Trigger phrases: "build my grocery list", "organize my shopping list", "make a grocery list". ## The prompt Build my grocery list. I will give you 3-4 meals I plan to cook, the number of servings for each, and any staples I am low on. 1. Break each meal into ingredients with quantities for my serving count. 2. Merge duplicates across meals (two meals needing onions = one line, combined quantity). 3. Add my staples. 4. Group the final list by store section: Produce, Meat & Seafood, Dairy & Eggs, Bakery, Dry Goods & Canned, Frozen, Household. 5. Flag pantry basics the recipes assume (oil, salt, spices) in a separate "check your pantry" note instead of the buy list. Rules: use standard US grocery units. If a quantity is ambiguous, pick the common package size and note it. Keep the list to one page.
Price Drop Watcher
Checks your saved product URLs daily and tells you only when a price drops below target.
Tested in Museworkflowscheduleworkflowurl 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.