Out-the-Door Cost Comparator

What it does

| Store   | Item price | Shipping | Tax    | Total   | Delivery window |
| ------- | ---------- | -------- | ------ | ------- | --------------- |
| Store C | $209.00    | $0.00    | $0.00  | $209.00 | 3-5 days        |
| Store B | $189.00    | $9.99    | $12.44 | $211.43 | 3-5 days        |
| Store A | $199.00    | $0.00    | $12.44 | $211.44 | 3-5 days        |

Cheapest: Store C at $209.00, saving $2.44 versus the most expensive.

What this one touches

Compares prices only. Never adds anything to a cart, never checks out, never enters payment details. Uses only the stores and shipping address you provide.

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

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.

• Recall Checker

  Checks your owned products against CPSC recalls; flags anything dangerous.

  Tested in Museskillinstructionsworkflowreport-format

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall 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.