Gift Finder

What it does

What this one touches

Reads only the answers you give in the interview. Writes nothing outside the chat; it returns a shortlist and links. Never buys, orders, or checks out anything. Never stores payment details.

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

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.