Ready-to-use skills for Muse AI.

Muse is Meta's new AI assistant. One paste installs the whole thing. Pick a skill, read its full source, copy the install prompt, and paste it into your Muse chat. Skills, prompt packs, scheduled workflows, and config snippets, all free.

• Costume Coordinator

  Plans a group costume theme and assigns each person a look within your budget.

  skillCreativeGroup costume theme shortlist matched to your people and occasionOne costume assigned to each person, with sizes and comfort notesBuy links for each piece, with a running budget tallyTimeline that leaves time for shipping, fitting, and fixesBackup plan when a piece is out of stock or does not fit

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Costume Coordinator skill, save the skill source below as ~/workspace/skills/costume-coordinator/SKILL.md, then tell Muse to use it whenever you are planning a group or family costume theme for a holiday and want each person assigned a look within a budget. --- SOURCE --- --- name: costume-coordinator description: Plan a group or family costume theme for a holiday. Use when the user wants a theme, a costume assigned to each person, buy links, a budget tally, and a timeline that leaves time for shipping. --- ## Purpose Turn a holiday costume idea into a finished plan for the whole group. The skill picks a theme that fits the people involved, assigns one costume to each person, finds buy links for each piece, keeps a running tally against the budget, and builds a timeline that leaves time for shipping, fitting, and fixes before the day arrives. ## Workflow 1. Take the occasion, the people, and the budget: names, ages, sizes, and anything anyone will not wear. 2. Suggest two or three themes that fit the group, and let the user pick one. 3. Assign one costume to each person in the theme, matching the role to the person where it matters, such as the tallest person playing the tallest character. 4. Find a buy link for each piece, with a price, and tally the total against the budget. Flag the plan when it runs over, and suggest a swap or a homemade piece to bring it back. 5. Build a timeline working back from the event date: order by date, fitting and fix time, and a final check the day before. 6. Name a backup for each piece that could sell out or arrive in the wrong size. ## Output Contract - The chosen theme and a one line reason it fits the group. - A per-person assignment: name, character, pieces, sizes, and buy link with price. - A budget tally: total, per-person cost, and the amount left or over. - A timeline: order-by date, fitting window, and final check. - A backup option for each piece that could sell out or misfit. ## Operating Rules - Never buy anything. Links are suggestions for the user to approve and order. - Ask about sizes, sensitivities, and comfort before assigning a costume. - Keep the budget visible at every step, and flag the moment the plan runs over. - Leave shipping and fitting time in the timeline; never plan an order to arrive the day before. - Offer a homemade or reuse option before suggesting a spend over budget.

• Interval Tracker

  Logs recurring events like haircuts and predicts the next due date from your intervals.

  skillProductivityLog of every recurring event you report, with the date it happenedAverage, shortest, and longest interval per trackPredicted next due date once a track has a few entriesReminder before the next due date so nothing slipsOne line per track showing the last date and the days since

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Interval Tracker skill, save the skill source below as ~/workspace/skills/interval-tracker/SKILL.md, then tell Muse to use it whenever you report a recurring event, such as a haircut, and want the date logged with a prediction for the next one. --- SOURCE --- --- name: interval-tracker description: Log recurring events such as haircuts and predict the next due date from your own intervals. Use when the user reports a recurring event happened today and wants the date logged, interval stats, or a reminder before it is due again. --- ## Purpose Keep a simple log of the recurring things in your life: haircuts, nail trims, oil changes, filter swaps, and anything else that repeats on a rough rhythm. You report the event in plain words, such as haircut today, and the skill logs the date, keeps the average, shortest, and longest interval per track, and predicts the next due date once a track has enough entries to judge. ## Workflow 1. Take the report: the event name and the date, which defaults to today when you say today. 2. Log it under its track, creating the track on the first report. 3. Compute the intervals between the logged dates for that track: average, shortest, and longest, in days. 4. Predict the next due date from the average interval once the track has at least three entries, and say how confident the prediction is from how steady the intervals are. 5. Offer a reminder a few days before the predicted date, and note when the prediction is based on too little data to trust. 6. Show a one line summary per track: last date, days since, average interval, and next due date. ## Output Contract - A confirmation naming the event and the date logged. - Per track: last date, days since, average interval, shortest interval, and longest interval. - A predicted next due date once three or more entries exist, with a note on how steady the pattern is. - A reminder offer before the next due date. ## Operating Rules - Never invent a date. Log only what the user reports. - Do not predict from fewer than three entries; say the track needs more data. - Report the average, shortest, and longest interval, not just the average, so a lopsided pattern stays visible. - Keep each track separate; a haircut interval never mixes with a nail trim interval. - Reminders are suggestions only. Never book, order, or schedule anything on the user's behalf.

• Grocery List Deduper

  Merges every grocery list and recipe into one clean list with nothing counted twice.

  skillShoppingMerge of lists from every person, recipe, and note into one listDuplicate items combined with quantities added togetherItems grouped by store section so the shop is one passConflict flags when two entries disagree on brand or sizePantry check that drops what you already have at home

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Grocery List Deduper skill, save the skill source below as ~/workspace/skills/grocery-list-deduper/SKILL.md, then tell Muse to use it whenever you have grocery lists from several people or recipes and want one clean list before you shop. --- SOURCE --- --- name: grocery-list-deduper description: Merge multiple grocery lists and recipes into one clean shopping list. Use when the user has lists from several people, recipes, or notes and wants one deduped list with quantities added together before shopping. --- ## Purpose Turn a pile of grocery lists, recipe ingredient lists, and stray notes into one list you can shop from in a single pass. The skill normalizes item names, combines duplicates with their quantities added together, groups everything by store section, and flags the places where two entries disagree so nothing gets bought twice or left out. ## Workflow 1. Collect every list: notes from each person, ingredient lists from each recipe, and any pantry or fridge notes. 2. Normalize the items: match the same item across lists even when the wording differs, such as tomatoes and tomato, and keep brand and size wording as the user wrote it. 3. Combine duplicates: add quantities together, convert units where the math is plain, and keep a note of which list each item came from. 4. Flag conflicts: when two entries disagree on brand, size, or amount, list the conflict and ask the user to pick, instead of choosing silently. 5. Apply the pantry check: drop items the user already has at home, and say what was dropped and why. 6. Group the final list by store section, such as produce, dairy, meat, pantry, and frozen, in the order the user walks the store. ## Output Contract - One shopping list with each item once, quantities added together, grouped by store section. - A merged-from note on each item showing which lists it came from. - A conflicts list with the choices the user needs to make. - A dropped list naming what was removed by the pantry check and why. ## Operating Rules - Never drop an item without saying so and naming the reason. - Ask when two entries conflict instead of picking one silently. - Keep the user's wording for brands and sizes so the list still matches the shelf. - Add quantities only when the units match or convert plainly; otherwise keep both amounts and flag it. - If a quantity is vague, such as some or a few, keep it vague and mark it as an estimate.

• Warranty Claim Helper

  Turns a broken product and its warranty terms into a ready-to-send claim draft.

  skillProductivityCoverage check against the warranty terms you paste inEvidence checklist: receipt, photos, serial number, and datesClaim draft ready to send to the maker or retailerPlain verdict when coverage has expired or the damage is excludedFollow-up tracker with claim number and dates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Warranty Claim Helper skill, save the skill source below as ~/workspace/skills/warranty-claim-helper/SKILL.md, then tell Muse to use it whenever a product breaks and you need to file a warranty claim. --- SOURCE --- --- name: warranty-claim-helper description: Help file a warranty claim for a broken product. Use when a product breaks under warranty, when the user wants to check what a warranty covers, or when they need a claim draft with the proof to attach. --- ## Purpose Turn a broken product and a warranty document into a claim that is ready to send. The skill reads the warranty terms, checks what is covered and what is excluded, lists the proof the maker will ask for, and drafts the claim message with the facts filled in. It is the filing step, not a tracker: it starts when something breaks and ends with a draft you can send. ## Workflow 1. Collect the facts: product name and model, serial number if there is one, purchase date and place, and what went wrong and when. 2. Read the warranty terms the user pastes in: coverage length, what is covered, what is excluded, and how claims are filed. 3. Give a coverage verdict: covered, likely excluded, or expired, with the exact term that decides it quoted in plain words. 4. Build the evidence checklist: receipt or order record, photos of the fault, serial number photo, and any prior repair notes. 5. Draft the claim: a short message to the maker or retailer with the product facts, the fault, the warranty term that covers it, and the remedy asked for. 6. Set up the follow-up: claim number, date sent, and the next date to chase it if no reply comes. ## Output Contract - A coverage verdict with the deciding warranty term in plain words. - An evidence checklist with each item marked as have it, need it, or not applicable. - A claim draft ready to send, with product facts, fault, covering term, and remedy asked for. - A follow-up note: where to send the claim, the claim number once filed, and the date to chase it. ## Operating Rules - Never file the claim for the user; the user always sends it. - Never invent a purchase date, serial number, or receipt. If a fact is missing, ask for it or mark it as missing. - Say plainly when coverage has expired or the damage looks excluded, and do not draft a claim that cannot succeed. - Quote the deciding warranty term in plain words so the user can check it. - Keep the draft short and factual, with no extra blame or apology.

• Garden Planner

  Plans garden beds for your zone, sun, and space, with a season-by-season schedule.

  skillHomeBed layout sized to the space and sunPlant choices rated for the hardiness zoneSeason-by-season planting and care scheduleWatering, mulching, and problem notesShopping list with quantities for plants, seed, soil, and mulch

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Garden Planner skill, save the skill source below as ~/workspace/skills/garden-planner/SKILL.md, then tell Muse to use it whenever you want to plan garden beds or landscaping for your zone, sun, and space. --- SOURCE --- --- name: garden-planner description: Plan garden beds and landscaping for your zone, sun, and space. Use when the user wants a bed layout, plant choices for their hardiness zone, or a season-by-season planting and care schedule. --- ## Purpose Turn a yard, a patch of sun, and a hardiness zone into a garden plan you can actually plant. The skill matches plants to the light and soil you have, lays out beds that fit the space, and spreads the work across the seasons so nothing is planted at the wrong time. ## Workflow 1. Collect the facts: hardiness zone, bed size and shape, hours of direct sun, soil type if known, and what the user wants to grow or see. 2. Map the space: divide the area into beds, leave paths wide enough to walk and reach the middle, and place tall plants where they will not shade short ones. 3. Choose the plants: pick varieties rated for the zone, matched to the sun each bed gets, and grouped by water needs. 4. Build the schedule: a season-by-season plan for sowing, transplanting, feeding, pruning, and harvest, with the dates for the user's zone. 5. Add the care notes: watering, mulching, and the first signs of trouble to watch for. 6. List the shopping: plants, seed, soil, and mulch with quantities for the beds as drawn. ## Output Contract - A bed layout with dimensions, paths, and where each plant goes. - A plant list with variety names, zone ratings, sun needs, and spacing. - A season-by-season schedule: sow, transplant, feed, prune, and harvest dates. - Care notes for watering, mulching, and common problems. - A shopping list with quantities for plants, seed, soil, and mulch. ## Operating Rules - Never recommend a plant outside its rated hardiness zone without saying so plainly. - Never recommend a plant known to be invasive in the user's region without flagging it. - Flag plants that are toxic to pets and children when they appear in the plan. - Keep the schedule tied to the user's zone, not a generic calendar. - Ask about sun and space before choosing plants; do not guess the light a bed gets.

• Recipe Cooking Companion

  Turns how you cook a dish into a repeatable recipe and rescales it for any headcount.

  skillCreativeWrites a dish you cook from memory as a repeatable recipeRescales rubs, sauces, and sides together for a new weight or headcountShopping list for the scaled amountsShort timing and technique answers during the cook

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Recipe Cooking Companion skill, save the skill source below as ~/workspace/skills/recipe-cooking-companion/SKILL.md, then tell Muse to use it whenever you want to write down a dish you cook from memory, rescale a recipe, or ask a timing question mid-cook. --- SOURCE --- --- name: recipe-cooking-companion description: Turn how you already cook a dish into a repeatable recipe, or rescale a recipe for a new weight or headcount. Use when the user describes a dish they cook from memory, gives a recipe to scale up or down, or asks a timing or technique question mid-cook. --- ## Purpose Keep the dishes you already cook, and make them repeatable. The skill writes the way you cook a dish as a written recipe with amounts, order, and times, or rescales a recipe you hand it so the rubs, sauces, and sides all fit the new weight or headcount. During the cook it answers timing and technique questions in short replies, so you can keep your hands on the food. ## Workflow 1. Take the dish as the user cooks it: ingredients in rough amounts, the steps in order, and the cues they use to judge doneness. 2. Write it as a repeatable recipe: exact amounts, steps in order, times, temperatures, and the doneness cues. 3. For a rescale, take the recipe and the real weight or headcount, and scale the rubs, sauces, and sides together so the ratios hold. 4. Check the scaled recipe: pan sizes, cooking times, and seasoning, which do not always scale in a straight line. 5. Give the shopping list for the scaled amounts. 6. During the cook, answer timing and technique questions in short replies, one answer at a time. ## Output Contract - A repeatable recipe: ingredients with amounts, steps in order, times, temperatures, and doneness cues. - A rescaled recipe with rubs, sauces, and sides scaled together, plus the pan size and time changes the scale forces. - A shopping list for the scaled amounts. - Short answers to timing and technique questions during the cook. ## Operating Rules - Never change a step the user swears by without asking first. - Scale rubs, sauces, and sides together; a sauce scaled alone throws the dish off. - Say when a time or temperature does not scale in a straight line, and give the new range. - Keep mid-cook answers short: one answer, no lecture. - If an amount is a guess, mark it as a guess and give the range to taste.

• Personal Stylist

  Turns your closet and a photo into outfits that fit your style, budget, and the occasion.

  skillCreativeOutfit ideas built from clothes you already ownOne photo or list of pieces, plus occasion and weatherA small swap for each outfit that changes the lookNew-item suggestions only when they fill a real gapTailoring and fit notes, in plain language

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Personal Stylist skill, save the skill source below as ~/workspace/skills/personal-stylist/SKILL.md, then tell Muse to use it whenever you need an outfit for an occasion and want ideas built from the clothes you already own. --- SOURCE --- --- name: personal-stylist description: Build outfits from your closet and a photo. Use when the user says "what should I wear", "style me", "outfit for", "what goes with this", or shares a photo of clothes and asks for outfit ideas. --- ## Purpose Turn the clothes a person already owns into outfits that fit the occasion, the weather, and their own taste. The skill starts with what is in the closet, builds complete outfits from those pieces, and suggests a new item only when it fills a real gap, so getting dressed takes minutes instead of a morning of second guessing. ## Workflow 1. Gather the pieces: a list of clothes, or a photo of the closet, plus the occasion, the weather, and the budget for anything new. 2. Note the constraints: dress code, comfort needs, colors the user likes, and pieces they never wear. 3. Build outfits: complete combinations from owned pieces first, each one named piece by piece. 4. Add one small swap per outfit: a rolled sleeve, a different belt, a layer added or removed, that changes the look without a new purchase. 5. Suggest a new item only when it fills a gap: one piece that works with three or more outfits, with a price range and where to look. 6. Flag fit and care: pieces that need tailoring, pieces that only work with one other item, and pieces that clash with the rest. ## Output Contract - Two or three complete outfits, each named piece by piece. - One small swap per outfit that changes the look. - A short note on why each outfit works for the occasion and the weather. - At most one new-item suggestion, with the gap it fills and a price range. - Fit notes: tailoring needed, or pieces that only pair with one other item. ## Operating Rules - Build from owned pieces first; a new purchase is the last resort, never the starting point. - Never comment on a body type as a problem to fix; style advice stays about the clothes. - Never push a brand or a store; name the item type and a price range instead. - Say plainly when a photo is too unclear to use, and ask for a list of pieces instead. - Keep the number of outfits small; three strong options beat ten weak ones.

• Used-Car Shopper

  Turns a used-car listing into a plain verdict: fair price, red flags, and what to check.

  skillShoppingPrice check against similar cars listed nearbyRed-flag scan: title, accident history, and seller signalsTest-drive checklist for that modelPre-purchase inspection questions for a mechanicA plain verdict, with the evidence behind it

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Used-Car Shopper skill, save the skill source below as ~/workspace/skills/used-car-shopper/SKILL.md, then tell Muse to use it whenever you find a used-car listing and want a plain verdict on the price, the red flags, and what to check before you buy. --- SOURCE --- --- name: used-car-shopper description: Judge a used-car listing before you buy. Use when the user shares a used-car listing, asks "is this a good price", "is this car worth it", or wants a test-drive and inspection checklist for a used car. --- ## Purpose Read a used-car listing the way a careful buyer would, so the decision rests on the price, the history, and the condition, not on shiny photos and a low monthly payment. The skill compares the asking price with similar cars nearby, flags the red flags in plain language, and builds a short checklist for the test drive and the pre-purchase inspection. ## Workflow 1. Collect the listing: year, make, model, trim, mileage, asking price, title status, and the seller's notes, plus the listing link. 2. Check the price: find similar cars listed nearby with the same year, trim, and mileage range, and note the price spread. 3. Scan for red flags: salvage or rebuilt title, a price far below the market, no service records, mismatched tires, rust in the photos, or a seller who will not share a vehicle history report. 4. Look up the model: common faults for that year and model, and the repairs that tend to cost the most. 5. Build the checklists: a test-drive checklist for this car, and the exact things to ask a mechanic to inspect. 6. Give the verdict: fair price or not, the red flags, and what would change the answer, with the evidence shown. ## Output Contract - A price comparison: asking price against similar listings nearby, with the range and the sources. - A red-flag list, each flag named plainly with where it appears in the listing. - A model note: common faults for that year and model, and the costly repairs to watch for. - A test-drive checklist and a pre-purchase inspection checklist for a mechanic. - A plain verdict: buy, walk away, or negotiate, with the reasons and what would change it. ## Operating Rules - Never tell the user to buy a car; the verdict is advice, and the buy is the user's call. - Never call a price fair without showing the comparable listings behind it. - Never invent a vehicle history report, an inspection result, or a price; if a fact cannot be checked, say so. - Treat a price far below the market as a warning, not a bargain, until the reason is clear. - Keep the checklists short and specific to this car, not a generic list.

• Contractor Quote Requester

  Turns a job description into a clear quote request you can send to three contractors.

  skillProductivityJob brief with scope, materials, and timelineQuote request message ready to send to each contractorApples-to-apples quote comparison tableQuestions that surface hidden costs and exclusionsRed-flag checklist for vague or one-line quotes

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Contractor Quote Requester skill, save the skill source below as ~/workspace/skills/contractor-quote-requester/SKILL.md, then tell Muse to use it whenever you need quotes for a job and want the replies to be easy to compare. --- SOURCE --- --- name: contractor-quote-requester description: Turn a job description into a clear quote request for contractors. Use when the user says "get quotes", "contractor quote", "quote request", "compare contractor quotes", "hire a contractor", or describes a job and asks what to send to contractors to get comparable prices. --- ## Purpose Turn a job description into a quote request that gets complete, comparable answers. A vague ask gets vague quotes: one contractor includes cleanup, another does not, and the prices cannot be compared. This skill writes one clear brief for you to send to every contractor, then lines the replies up in a table so the differences are easy to see. ## Workflow 1. Collect the job: what needs doing, where, measurements, materials, and the timeline. Ask for photos when they help a contractor price the work. 2. Draft the request: scope, specs, materials, site access, timeline, and exactly what the quote must include, in one message ready to send. 3. Show the exact message for each contractor. The user approves each message and sends it themselves, to three contractors when possible, so every reply answers the same questions. Never send a message for the user. 4. Build the comparison table: price, materials, labor, timeline, warranty, payment schedule, and exclusions, one column per contractor. 5. List the follow-up questions: permits, cleanup, disposal, change orders, and anything a quote left out. 6. Flag the red flags: one-line quotes, no materials listed, no timeline, or a price far below the rest with no explanation. ## Output Contract - A job brief: scope, specs, materials, access, and timeline. - A quote request message ready to send to each contractor. - A comparison table: price, materials, labor, timeline, warranty, and exclusions per contractor. - A follow-up questions list for anything a quote left out. - A red-flag checklist for vague or one-line quotes. ## Operating Rules - Never invent a price, a timeline, or a material. If a number is missing, ask for it or mark the brief as partial. - Never recommend a contractor or vouch for one; the user checks licenses, insurance, and references. - Never send a message to a contractor. The user approves the exact message for each contractor and sends it themselves. - Use the same brief for every contractor so the quotes stay comparable. - Flag any quote that skips permits, materials, cleanup, or disposal, and say what to ask before signing. - Keep the comparison table honest: mark what a quote left out instead of guessing it.

• Ratings-First Product Comparison

  Compares products by ratings and reviews first, so the best-reviewed pick wins.

  skillShoppingRatings and review-count check for each candidateReview summary that separates real complaints from noiseSide-by-side table: rating, review count, price, and key specsWarning when a product has too few reviews to trustA pick with the reasons, in plain language

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Ratings-First Product Comparison skill, save the skill source below as ~/workspace/skills/ratings-first-product-comparison/SKILL.md, then tell Muse to use it whenever you compare products and want the ratings and reviews checked before the price. --- SOURCE --- --- name: ratings-first-product-comparison description: Compare products by ratings and reviews before price. Use when the user says "compare products", "which one is better rated", "check reviews", "best reviewed", or asks which product to buy and wants ratings checked first. --- ## Purpose Put ratings and reviews first when comparing products, so a low price on a weak product does not win by default. The skill checks the star rating and the review count for each candidate, reads what buyers actually complain about, and only then looks at price, so the pick rests on how the product holds up in real use. ## Workflow 1. Collect the candidates: product names or links, plus what matters to the user, such as size, fit, or durability. 2. Pull the ratings: star rating and review count for each candidate, from the merchant page, and note the source. 3. Read the reviews: common praise, common complaints, and recurring defects, with the worst recurring complaint named plainly. 4. Flag thin evidence: a rating built on only a handful of reviews, or a high rating with no written reviews behind it. 5. Build the table: rating, review count, price, and key specs side by side, with the source for every number. 6. Recommend: the best-reviewed pick that fits the budget, with the reasons in plain language, and say when no candidate earns a recommendation. ## Output Contract - A ratings table: star rating and review count for each candidate, with the source. - A review summary: common praise, common complaints, and the worst recurring defect. - A thin-evidence flag for any product with too few reviews to trust. - A side-by-side comparison: rating, review count, price, and key specs. - A pick with the reasons, or a plain statement that no candidate earns one. ## Operating Rules - Never invent a rating, a review count, or a price. If a number cannot be found, say so and mark the row as unverified. - Treat a small review sample as a soft signal, never as proof; say how many reviews the rating rests on. - Check the price only after the ratings are in, so a cheap price cannot hide a weak product. - Note when a listing looks sponsored or the reviews look planted, and say the final buy is the user's call. - Keep one currency and one unit through the table, and state both.

• DIY Build Planner

  Turns a build idea, measurements, and budget into a materials list and a step plan.

  skillHomeMaterials list with quantities and estimated costCut list for boards and sheetsTool list split by owned and to borrow or rentStep plan in order with checks at each stageFlags for structural, permit, and licensed-trade work

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the DIY Build Planner skill, save the skill source below as ~/workspace/skills/diy-build-planner/SKILL.md, then tell Muse to use it whenever you describe a project to build and ask what to buy and how to do it. --- SOURCE --- --- name: diy-build-planner description: Plan a DIY build from an idea, measurements, and a budget. Use when the user says "build a shed", "build shelves", "DIY build plan", "materials list", "cut list", or describes a project to build and asks what to buy and how to do it. --- ## Purpose Turn a build idea into a plan a person can actually follow: a materials list with quantities and estimated cost, a cut list, the tools needed, and the steps in order. The plan stays inside the measurements and budget the user gives, and it flags work that belongs to a licensed pro. ## Workflow 1. Collect the project: what is being built, where it goes, the measurements, and the budget. Ask for a sketch or a photo of the space when one helps. 2. Break it into parts: frame, surfaces, fasteners, and finish, each with quantities worked out from the measurements. 3. Price it: an estimated cost per line from prices the user gives or typical store prices, with the total checked against the budget. If it runs over, say so and offer a smaller scope. 4. Build the cut list: every board or sheet with its length, width, and count, grouped so cuts waste as little material as possible. 5. List the tools: what the build needs, marking which tools the user already has and which to borrow or rent. 6. Order the steps: site prep first, then frame, then surfaces, then finish, with a check at each stage for square, level, and plumb. 7. Flag the limits: load-bearing work, electrical, plumbing, gas, and anything a permit covers gets a clear note to bring in a licensed pro or check local rules first. ## Output Contract - A materials list: item, quantity, size, and estimated cost, with a total against the budget. - A cut list: every piece with dimensions and count. - A tool list: needed tools, split into owned and to borrow or rent. - A step plan in order, with a check at each stage. - A flags list: structural, permit, or licensed-trade work that needs a pro. ## Operating Rules - Never invent a measurement or a price. If a number is missing, ask for it or mark the plan as partial. - Never present a plan as safe for structural, electrical, plumbing, or gas work; those lines always get a pro note. - Remind the user to check local permit and setback rules before buying materials for an outdoor structure. - Keep all measurements in one unit through the plan, and state the unit. - If the budget cannot cover the materials, say so plainly and offer a smaller scope instead of trimming the list silently.

• Trip Expense Reimbursement

  Turns trip receipts and mileage into a clean expense report ready to submit.

  skillMoney & financeExpense report draft from receipts and mileageCategory totals with per diem handlingMileage log with rate mathPolicy flags for missing receipts and limitsExpense report template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Trip Expense Reimbursement skill, save the skill source below as ~/workspace/skills/trip-expense-reimbursement/SKILL.md, then tell Muse to use it whenever you come back from a trip with receipts or ask how to file expenses. --- SOURCE --- --- name: trip-expense-reimbursement description: Build an expense reimbursement report from trip receipts, mileage, and per diem. Use when the user says "file my trip expenses", "expense report", "reimbursement", "mileage log", "trip receipts", or comes back from a trip with receipts to sort out. --- ## Purpose Turn a pile of trip receipts and a mileage note into a clean expense report: every cost categorized, mileage totaled at the right rate, per diem handled, and anything that breaks policy flagged before the user submits it. The report is a draft the user reviews, never a submission. ## Workflow 1. Collect receipts: for each one, the date, vendor, amount, and category (lodging, meals, transport, parking, other). Ask for a photo or a typed line for each receipt. 2. Collect mileage: start and end points, miles driven, and the reimbursement rate. Multiply miles by the rate for the mileage total. 3. Handle per diem: if the user gets a daily meal allowance, apply it per travel day instead of itemizing meals, and note which days it covers. 4. Total by category and check the policy the user states: daily meal caps, lodging caps, and any categories that need a receipt above a set amount. 5. Flag gaps: receipts missing, amounts without a category, mileage without a rate, and any line over a cap. 6. Build the report draft: a dated table of every line, category totals, the mileage log, and the grand total, with flagged lines marked for the user to fix. ## Output Contract - An expense table: date, vendor, category, amount, and receipt status for every line. - Category totals and a grand total, with per diem shown as its own line. - A mileage log: trips, miles, rate, and the mileage total. - A flags list: missing receipts, uncapped lines, and anything over a stated limit. - Nothing is submitted. The report is a draft the user reviews and files. ## Operating Rules - Never invent an amount, a mileage figure, or a receipt. If a number is missing, ask for it or mark the line as incomplete. - Never submit the report or contact an employer, a finance team, or a booking system. - Keep one currency through the whole report; convert foreign amounts only when the user gives the rate or the converted figure. - Per diem and itemized meals never mix on the same day; pick one and note the choice. - State the rate and the policy limits used, so the user can check them against the real policy.

• Instagram Saved Reels Sort

  Files your Instagram saved reels into your own topic collections, two pages at a time.

  skillProductivityinstructionspython scriptssetupreview files

  shared by chinami-michaels

  ViewCopy install promptInstall the "Instagram Saved Reels Sort" skill. Its full source is below. Create it at ~/workspace/skills/instagram-saved-reels-sort/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. This skill also runs scripts from https://github.com/chinami-michaels/instagram-saved-reels-sort that the source below does not contain. Before you clone anything, tell me what you will download, and wait for my yes. Clone the repository into ~/workspace/skills/instagram-saved-reels-sort, compare its SKILL.md with the source below, and tell me if they differ. Read each script in bin/ and tell me what it does before you run it. Do not run setup until I say go. --- SOURCE --- --- name: "instagram_saved_reels_sort" description: "Sort Instagram saved reels into the user's topic collections, in small reviewable batches. Use when the user asks to sort saved reels, run a recurring sort, or work through a saved-reels backlog. Requires a connected Instagram account (instagram-cli)." --- # Instagram Saved Reels Sort ## Purpose Move saved Instagram reels out of the unsorted Saved bucket into the user's own topic collections, two pages at a time, with a human review step before anything moves. Built for backlogs of hundreds or thousands of saved reels, and for a light recurring run that keeps new saves filed. ## Requirements - An agent environment with the `instagram-cli` tool available and the user's Instagram account connected (`instagram-cli accounts` must return an account). This skill was built for Muse; on other platforms, substitute the equivalent commands for listing saved posts, describing media, managing saved collections, and moving posts between collections. - Python 3 (standard library only). ## Setup (one time) 1. Run `python3 bin/setup.py`. It verifies the Instagram connection, lists the user's existing saved collections, and walks through defining topics. 2. The user picks a short theme key per topic (e.g. `ai`, `recipes`, `travel`). Collections that don't exist yet are created on Instagram. 3. Setup writes `~/.instagram-saved-reels-sort/config.json` (account id and the key → collection-id map) and a starter `~/.instagram-saved-reels-sort/my-collections.md`. 4. The user writes their routing rules (which reels go where, plus the edge cases) into `my-collections.md`. See `references/collections-template.md` for a worked example. This file is the source of truth for every batch; keep it current as tastes change. ## Tooling Helpers live in `bin/`; all state (config, cursor, batch files) lives in `~/.instagram-saved-reels-sort/`, never in `/tmp`, which can be wiped without warning and would lose your place mid-sort. - Fetch a batch: `python3 bin/fetch_batch.py fetch 2 <label>`: pulls 2 pages of saved posts (50/page), keeps reels, runs media-understanding, writes `<label>_reels.json` and `<label>_review.txt`, advances `cursor.txt`. - Re-sync a lost cursor: `python3 bin/fetch_batch.py advance <pages>`: walks forward N pages without processing. - Sort a batch: `python3 bin/sort_batch.py --batch <label> --map <map.json>`: moves reels into collections per a `{media_id: theme_key}` map. Collection map and routing rules: the user's `my-collections.md` (template: `references/collections-template.md`). Step-by-step with examples and troubleshooting: `references/batch-procedure.md`. Dining dossiers (opt-in per-restaurant health-inspection + review-trend reports for food-spot reels): `references/dining-dossier.md`. ## Workflow 1. Fetch one batch (`fetch 2 <label>`), then read `<label>_review.txt`. 2. Assign every reel a theme key per the user's `my-collections.md`, or leave it unassigned (stays in Saved). 3. Write the map to `<label>_map.json` (`{"<media_id>": "<theme_key>"}`), run the sorter. 4. Report per-collection move counts plus the unsorted leftovers with reasons. Repeat these steps for each batch. ## Output Contract After each batch: counts moved into each collection + list of reels left unsorted (with reason, e.g. no description). ## Operating Rules 1. Two pages per batch: keeps reviews human-sized. Continue to the next batch only when asked, or during a full scheduled run. 2. Never move a reel with no usable description and no inferable content; unsortable reels stay in Saved. 3. Write actions only move posts between collections: nothing is deleted, unpublished, or unsaved globally. Say that plainly to the user before the first sort. 4. The cursor file is the source of truth for progress; if it looks stale, re-sync with `advance` rather than guessing pages. 5. Confirm the first batch's moves with the user before running unattended. After that, a recurring run (e.g. weekly) can process everything saved since the last batch until caught up. 6. Dining dossiers are opt-in: after a batch, offer one for any reel filed into a food/dining collection that's about a specific restaurant, or run one on demand. Never auto-run them for every food reel.

• Marketplace Listing Builder

  Turns item photos into a ready-to-post marketplace listing priced from recent sales.

  Tested in MuseskillShoppingItem identification and details from photosPrice grounded in recent sold pricesOne condition question photos cannot answerReady-to-post title and descriptionBundle and repricing suggestions

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Marketplace Listing Builder skill, save the skill source below as ~/workspace/skills/marketplace-listing-builder/SKILL.md, then tell Muse to use it whenever you share photos of an item you want to sell. --- SOURCE --- --- name: marketplace-listing-builder description: Turn photos of an item into a ready-to-post listing for Facebook Marketplace, Craigslist, or eBay, with a price grounded in recent sold prices. Use when the user says "sell this", "list this for me", "what is this worth", "write a listing", or shares photos of an item they want to sell. --- ## Purpose Take the slow part out of selling household items: turning a few photos into a listing with a fair price. The skill reads what the photos show, checks what similar items actually sold for, asks the one question a photo cannot answer, and hands back a title, a description, and a price the user can post as is. ## Workflow 1. Look at the photos: identify the item, brand, model, size, color, and any visible wear, damage, or missing parts. Note anything the photos cannot show. 2. Ask the one question photos cannot answer: does it work, and what is its true condition? Wait for the answer before drafting. 3. Check recent sold prices for the same or closest matching item on the marketplace the user names. Use sold prices, not asking prices, and say how many comparable sales the price rests on. 4. Set a price: a starting price for a quick sale and, when the gap matters, the higher price a patient seller could ask. 5. Draft the listing: a title with the words a buyer would search for, and a short description covering what it is, its condition, what is included, and pickup or shipping terms the user gives. 6. Check the value floor: if the item is worth too little to sell alone, suggest a bundle with related items instead of a solo listing. 7. If a listing sits without interest, draft repricing moves: a price drop, a title change, or a bundle, with the reason for each. ## Output Contract - An item summary: what the photos show, plus anything they cannot show. - The condition question, asked before any draft, and the user's answer reflected in the description. - A price with its basis: the comparable sold listings it rests on. - A ready-to-post title and description the user can copy. - A bundle suggestion when the item is worth too little alone, and repricing drafts when a listing sits. - Nothing is posted. The output is a draft for the user to review and publish. ## Operating Rules - Never publish, edit, or delete a listing, and never message a buyer or seller. - Never invent a detail the photos do not show. Mark anything unknown as unknown and ask. - Base prices on sold listings whenever they exist. If no comparable sales can be found, say so and label the price as an estimate. - Describe condition honestly, including flaws the user confirms, even when a softer wording would sell faster. - Keep personal details out of the listing text: no addresses, no phone numbers, no names.

• Movie Sidekick

  Answers questions about the film you are watching without spoiling what comes next.

  Tested in MuseskillCreativeProduction and cast facts on requestA strict no-spoilers line at the scene you nameShort answers sized for mid-film questionsOpinions when you ask for themA fuller debrief once the film ends

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Movie Sidekick skill, save the skill source below as ~/workspace/skills/movie-sidekick/SKILL.md, then tell Muse to use it whenever you are watching a film and ask about it. --- SOURCE --- --- name: movie-sidekick description: A watch-along companion for a film in progress: production facts, cast facts, and opinions, with nothing revealed past the scene the user names. Use when the user says "watching", "movie sidekick", "who is that actor", "was this filmed", names a film they are partway through, or asks about a scene they just watched. --- ## Purpose Make watching a film with an assistant feel like watching with a knowledgeable friend: quick answers about who is on screen, how a scene was made, and what to think of it, without ever ruining what comes next. The user names the film and where they are in it; everything the skill says stays behind that line. ## Workflow 1. Set the line: ask which film the user is watching and where they are, a scene description or a timestamp. Treat that point as the spoiler boundary for the whole session. 2. Answer in short form while the film runs: a cast fact, a production note, or a piece of context, kept brief so the user can glance and keep watching. 3. Update the line as the user reports new scenes. Facts about events up to the new point become fair game; anything past it stays off limits. 4. Give opinions only when asked, and base them on what has happened up to the line: a performance, a shot, a line of dialogue. 5. When the user says the film is over, lift the boundary and offer a fuller debrief: themes, ending questions, and what to watch next if they want it. ## Output Contract - Mid-film answers are short: a few sentences at most, one fact or one opinion each. - Every answer respects the spoiler boundary the user last set. - Facts the skill cannot verify are flagged as uncertain rather than stated flatly. - The end-of-film debrief is offered, not imposed, and comes only after the user confirms they finished. ## Operating Rules - Never reveal, hint at, or confirm plot events past the user's named point, including twists the user guesses at. Offer to revisit the question once they pass that scene. - Never use knowledge of the ending to color a mid-film answer, even vaguely. - If the user's scene description is ambiguous, ask which scene they mean before answering anything plot related. - Keep answers short during the film. Save long explanations for the debrief or for a direct request. - If a production or cast fact cannot be checked, say it is unverified instead of presenting it as settled.

• PIL: Personal Instagram Library

  Turns your Instagram saved posts into a private, searchable library on your own computer.

  skillProductivityinstructionspython packagelocal databasemcp server

  shared by pjpoulose

  ViewCopy install promptInstall the "PIL: Personal Instagram Library" skill. Its full source is below. Create it at ~/workspace/skills/pil/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. This skill also needs code from https://github.com/pjpoulose/PIL: a Python package and scripts that the source below does not contain. Before you clone, download, install, or run anything, tell me exactly what you will fetch and run, and wait for my yes. Do not ask me for a password or token in chat. --- SOURCE --- --- name: "pil" description: "Build and query a Personal Instagram Library: ingest your saved Instagram posts into a local SQLite database, run vision-AI deep extraction over them, and query the library live through a read-only local MCP server. Use when the user wants to index, search, or ask questions over their Instagram saved posts." --- # PIL: Personal Instagram Library ## Purpose Turn a user's Instagram saved posts into a private, queryable knowledge base that lives entirely on their own machine: ingest → deep-extract → tag → export, plus a read-only MCP server so Cursor, Claude Code, or Claude Desktop can query it live. ## Tooling Helpers live in `bin/` and share config through `bin/pil_common.py`. Config resolves from `PIL_CONFIG` env var, `./pil.config.json`, then `~/.config/pil/pil.config.json` (copy `pil.config.example.json` to start). The DB is `<data_dir>/pil.sqlite`; `schema.sql` is applied automatically on first run. - `bin/ingest_saved.py [collection_id]`, step 1: saved collections → `folders`, saved posts → `posts`/`post_folders`. Resume-safe via cursor files. - `bin/extract_content.py`, step 2: vision-AI deep read (`instagram-cli media-understanding`) → `knowledge` rows (summary, key points, how-to, links) plus tags. Resume-safe; batches of 25. - `bin/tag_all.py`, step 3: programmatic tags (caption keywords + folder names) for posts with fewer than 3 tags. - `bin/export_web.py [output_path]`, step 4: static JSON export for manual use with any AI tool. Captions are truncated to snippets, never verbatim. - `bin/export_html.py [output_path]`, step 5: self-contained HTML dashboard (`pil_library.html`): answer-first search with inline citations, source cards, thin-result fallbacks and follow-up prompts, plus rooms, tags, sorting, read-notes. Works offline from disk; the user can keep it on their Desktop as a web app. - `bin/export_pwa.py [output_dir]`, step 6: installable PWA bundle (`index.html` + `manifest.json` + offline service worker + icons) for the real browser *Install* prompt, plus one-click launchers: a Mac `Start PIL.app` builder (no terminal window), hidden-console Windows `Start/Stop PIL.vbs`, and a universal `Start PIL.command`. Serve over localhost; Chrome/Edge prompt automatically, Safari/Firefox add manually (see README). - `bin/publish_pwa.py <pwa_dir> [--provider netlify|manual]`, step 7: publish the PWA bundle to the user's own private static host for phone install; writes `phone.json` + `phone-qr.png` so the desktop PWA shows a "Take PIL on your phone" panel with a QR code. Tokens live in the local config's `publish` section, never committed. See `MOBILE.md`. - `bin/mcp_server.py`, read-only MCP server over stdio. Tools: `search_posts`, `get_post`, `list_folders`, `list_tags`, `library_stats`. Requires: `python3`, `instagram-cli` (see the Instagram skill), `pip install "mcp<2"`. ## First-run: setting up the user When the user asks you to set up PIL (e.g. pastes the prompt from the README): 1. Clone the repo (or pull latest) and work from it. You can run `bootstrap.sh` / `bootstrap.ps1` yourself for Python/git/deps, or do the Install steps manually. 2. Link Instagram: `instagram-cli accounts` must list their account. If not, get the connect URL (`instagram-cli connect-url`) and have the user link it in their browser, then re-check. Never handle passwords or tokens yourself. 3. Run the pipeline in order; every step is resume-safe: `ingest_saved.py` → `extract_content.py` → `tag_all.py`. Extraction is slow on large libraries; run it in the background and report when done. 4. Build the app with `export_pwa.py`, then **deliver it**: zip the PWA folder, put the zip in the user's file area, and attach it to your reply along with the 3 install steps (unzip → double-click Start PIL → click Install). Also run `export_web.py` and attach `web_data.json`: that's the file they hand to any other AI tool. 5. Offer the phone step: `publish_pwa.py` needs their hosting token; collect it via the secure credential flow, never in chat. After publishing, make sure the QR/URL reaches them (re-serve the folder or send the code directly). Keep the user posted at each stage; ask only for what only they can do. ## Auth The user links their own Instagram account themselves. `instagram-cli accounts` must list it; the `user_fbid` from that output goes into `pil.config.json` as `account_id`. Never ask for, handle, or store passwords, tokens, or session data. The pipeline only reads the user's own saved posts. ## Operating Rules 1. **Code is shared, data stays home.** Never copy, upload, or commit a user's `pil.sqlite`, exports, captions, or account ID. The package holds code, schema, config examples, and docs only. 2. The MCP server is read-only by construction (SQLite `mode=ro`, SELECT-only tools). Never add a write tool. 3. Run the pipeline in order: ingest → extract → tag. Export any time after ingest. 4. Deep-extraction headings are normalized in `extract_content.py` (`_normalize_labels`): sections read Context / Moment / Significance / Origin. Do not reintroduce the word "Cultural". 5. Keep this file lean. Install/usage docs live in `README.md`; per-client MCP wiring lives in `references/mcp_clients.md`.

• Debt Payoff Planner

  Turns your debts, APRs, and minimums into a payoff order and a monthly plan.

  skillMoney & financePayoff order by avalanche or snowballMonthly payment plan with a debt-free dateInterest comparison between payoff ordersWhat-if check for an extra monthly paymentPayoff plan template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Debt Payoff Planner skill, save the skill source below as ~/workspace/skills/debt-payoff-planner/SKILL.md, then tell Muse to use it whenever you list your debts or ask which debt to pay first. --- SOURCE --- --- name: debt-payoff-planner description: Build a debt payoff plan from debts, balances, APRs, and minimum payments. Use when the user says "pay off my debts", "debt payoff plan", "avalanche or snowball", "how fast can I be debt free", "extra payment", or shares a list of debts and asks which one to pay first. --- ## Purpose Turn a list of debts into a payoff plan with a clear order: which debt gets every extra dollar, which debts stay at their minimums, and when each debt is gone. The plan compares two orders, avalanche (highest APR first) and snowball (smallest balance first), so the user picks with both the math and the motivation in view. ## Workflow 1. Collect debts: for each debt, the name, balance, APR, and minimum payment, plus the total monthly amount the user can pay toward debt. 2. Check the floor: confirm the monthly amount covers all minimums combined. If it does not, say so plainly and stop; the plan needs a different budget first. 3. Build both orders: avalanche (highest APR first) and snowball (smallest balance first), each with a debt-free date and total interest paid. 4. Recommend one order and give the reasons: avalanche usually costs less interest, snowball usually clears a first debt sooner. 5. Turn the chosen order into a month-by-month plan: which debt gets the extra payment, which debts stay at minimum, and when each balance hits zero. 6. Run the what-if: show how an extra monthly payment changes the debt-free date and the interest total. 7. Recheck on payoff: when a debt is paid off, roll its payment into the next debt in the order and update the dates. ## Output Contract - A debt table: name, balance, APR, minimum payment, and position in the chosen order. - A comparison: avalanche versus snowball, with a debt-free date and total interest for each. - A monthly plan for the chosen order, naming the target debt each month. - An extra-payment what-if: the new debt-free date and the interest saved. - No payment is made, moved, or scheduled. The plan is text the user reviews. ## Operating Rules - Never ask for logins, card numbers, or account access. Work only from numbers the user types in. - Never move money, schedule a payment, or contact a lender. - Never invent a balance, APR, or minimum. If a figure is missing, ask for it or mark the plan as partial. - Every debt stays at its minimum in every month of the plan; the extra payment goes to one target debt at a time. - Round dates to the month, and state that the plan assumes no new charges and no rate changes. - If the minimums alone exceed the monthly amount the user can pay, say so plainly and stop instead of building a plan that cannot work.

• Interview Question Prep

  Turns a job posting and your notes into likely interview questions and draft answers.

  skillProductivityLikely questions drawn from the job postingShort draft answers in your own wordsGap flags where you still need a real exampleQuestions to ask the interviewerPrep sheet template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Interview Question Prep skill, save the skill source below as ~/workspace/skills/interview-question-prep/SKILL.md, then tell Muse to use it whenever you prepare for a job interview. --- SOURCE --- --- name: interview-question-prep description: Prepare for a job interview from a job posting and the user's background notes. Use when the user says "prep me for an interview", "interview prep", "interview questions", "help me prepare for an interview", "what will they ask", or shares a job posting and asks how to get ready. --- ## Purpose Turn a job posting and the user's own background notes into a focused prep sheet: the questions most likely to come up, short draft answers grounded in real experience, and good questions to ask the interviewer, so the user walks in prepared instead of rehearsing generic answers. ## Workflow 1. Collect inputs: the job posting text or link, plus the user's background notes, resume bullets, and anything known about the team or interview format. 2. Extract what matters: the top requirements, skills, and themes in the posting, and which parts of the user's background match each one. 3. Draft likely questions: a ranked list mixing role-specific questions, behavioral questions, and company-fit questions, most likely first. 4. Draft short answers: for each question, a 3 to 5 sentence answer tied to a real detail from the user's notes. Where the notes lack a real example, mark it "needs your example" instead of inventing one. 5. Draft questions to ask: 5 to 7 questions for the interviewer, tied to the role, the team, and how success is measured. 6. Produce the prep sheet (see Output Contract) plus a short practice plan for the time the user has left. ## Output Contract - A prep sheet with: the ranked likely questions, a short draft answer under each, and gap flags wherever a real example is still missing. - A short list of questions to ask the interviewer, each with one line on why it matters. - A practice plan for the time available: what to rehearse first, and what to skip if time is short. - Nothing is sent to an employer or recruiter. The prep sheet is text only. ## Operating Rules - Never invent experience, employers, metrics, credentials, or past results. If the notes lack a story, flag the gap and ask the user for one. - Never send applications, follow-up notes, or messages to employers or recruiters. - Never share the user's resume, notes, or prep sheet with anyone. - Keep draft answers short and in words the user would actually say. No jargon the user would not use, and no script to memorize word for word. - Do not help embellish or misstate experience. If the user asks for that, reframe the answer around what is honestly true. - If the posting is missing (no text or link), ask for it before drafting questions, and say plainly that questions drafted without it are generic.

• Wedding Vow Drafter

  Turns a couple's story, promises, and tone into short vows each partner can say aloud.

  skillCreativestory interviewthree vow draftslength checkpromise listread-aloud pass

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Wedding Vow Drafter skill, save the skill source below as ~/workspace/skills/wedding-vow-drafter/SKILL.md, then tell Muse to use it whenever you want help writing wedding vows. --- SOURCE --- --- name: wedding-vow-drafter description: Turn a couple's story, promises, and preferred tone into short, speakable wedding vow drafts. Use when the user says "write my vows", "wedding vows", "help with vows", "vow draft", "what should I promise", or wants help writing vows for a wedding or commitment ceremony. --- ## Purpose Turn what a couple actually knows about each other into vows they can say out loud with a straight face: specific promises, real moments, and a tone that sounds like them, kept short enough to deliver without rushing. ## Workflow 1. Interview each partner separately or together: how they met, one early memory, one hard time they got through, three qualities they admire in the other person, and what they want to promise going forward. 2. Build the promise list: turn each intention into a specific, keepable promise, for example "I promise to call before I am late" instead of "I promise to always be there". 3. Draft three versions per partner: one sincere, one lighthearted, one mix of both. Each draft opens with a line about the other person, states two or three promises, and closes with a single clear line. 4. Check length: each draft should read aloud in about two minutes. Cut filler lines and repeated ideas until it fits. 5. Read-aloud pass: read each draft back slowly and flag any line that is hard to say, sounds borrowed, or does not match the tone the partner picked. Offer a plainer rewrite for each flagged line. 6. Deliver the drafts: present each partner's three versions side by side, with the promise list attached, and note which lines each partner can mix and match. ## Output Contract - Interview notes: the moments, qualities, and intentions each partner named, in their own words where possible. - Promise list: each promise as a single specific sentence, grouped by partner. - Three drafts per partner: sincere, lighthearted, and mixed, each about two minutes spoken. - Read-aloud notes: flagged lines with a plainer rewrite offered for each. - Questions: anything missing, such as the tone, the ceremony style, or a memory only one partner can supply, asked instead of invented. ## Operating Rules - Never invent a memory, story, or promise the couple did not name. If a draft needs a detail, ask for it. - Never copy published vows, poems, or song lyrics. Every line must be original to the couple. - Never push a tone a partner did not pick. If one partner wants sincere and the other wants funny, draft each in their own tone. - Never make a promise sound grander than the couple means it. Keep promises specific and keepable. - Never present a draft as finished. Vows are personal: the couple edits, and the skill reworks the draft from their edits. - If the couple is stuck on where to start, offer three opening lines built only from facts they already gave, and let them pick one.

• Chore Rotation Planner

  Turns household chores and who does them into a fair rotation, with swaps built in.

  skillHomeweekly rotationchore listfairness checkswap ruleweekly chart

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Chore Rotation Planner skill, save the skill source below as ~/workspace/skills/chore-rotation-planner/SKILL.md, then tell Muse to use it whenever you want a fair chore rotation for the household. --- SOURCE --- --- name: chore-rotation-planner description: Build a fair weekly chore rotation for a household from a list of chores, the people who share the home, and how often each job needs doing. Use when the user says "chore rotation", "chore chart", "split the chores", "who does what this week", "fair chores", "household chores", or wants to swap or rebalance household jobs. --- ## Purpose Turn a pile of household jobs into a rotation that feels fair: every chore gets a person and a week, heavy weeks balance against light ones, and swaps are easy, so the same argument about who does what does not restart every Sunday. ## Workflow 1. List the chores: take the user's rooms and jobs, and record each chore with how often it needs doing (daily, weekly, biweekly, monthly) and a rough time estimate in minutes. 2. List the people: record who shares the home, any jobs each person cannot do for safety or health reasons, and any jobs each person strongly dislikes, so those rotate rather than stick to one person. 3. Build the rotation: assign each chore to one person per cycle, spreading heavy jobs and disliked jobs across people and weeks, and keeping daily jobs on a short cycle of their own. 4. Check fairness: add up the minutes per person per week, flag any week where one person carries much more than the others, and rebalance by moving a light job or swapping a heavy one. 5. Handle swaps: when someone asks to trade, swap the two chores for that week only, record the trade, and let the original rotation resume the next week unless the user asks for a permanent change. 6. Publish the chart: output a weekly chart with one row per chore and one column per day or per week, in a form the user can paste into a shared note or print for the fridge. ## Output Contract - Weekly chart: one row per chore, showing who does it this week and when it repeats. - Fairness summary: minutes per person for the week, plus any imbalance flagged and how it was fixed. - Chore list: each chore with its frequency and time estimate, so the rotation can be rebuilt later. - Swap record: any trade made, with the two chores and the week it applies to. - Questions: anything missing, such as who lives in the home or how often a job needs doing, asked instead of guessed. ## Operating Rules - Never assign a chore to a person who cannot do it safely, for example a heavy lifting job to someone with a back injury the user has named, or a chemical cleaning job to a young child. - Never present the rotation as a judgment on a person. It tracks jobs and minutes, not effort or character. - Never invent chores, people, or frequencies the user did not name. Ask when a room or a regular job is missing from the list. - Never make a swap permanent unless the user says so: swaps last one week by default. - Never drop a chore from the chart without saying so. If a job has no one to do it, flag it as unassigned and ask who should take it. - If the household changes, for example someone moves out or a new room is added, rebuild the rotation from the updated list instead of patching the old chart.

• Commit Message Writer

  Turns a git diff into a conventional commit message that explains what changed and why.

  skillDev & automationconventional commit messagechange explanationbreaking-change notescope suggestionalternative subject line

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Commit Message Writer skill, save the skill source below as ~/workspace/skills/commit-message-writer/SKILL.md, then tell Muse to use it whenever you want a commit message written from a diff. --- SOURCE --- --- name: commit-message-writer description: Turn a git diff or staged change into a clear conventional commit message with a short subject line and a body that explains what changed and why. Use when the user says "commit message", "write a commit message", "summarize this diff", "conventional commit", "git commit message", or pastes a diff and wants a message for it. --- ## Purpose Turn a diff into a commit message a future reader can trust: a short subject line that says what changed, and a body that says why, so the project history reads like a log of decisions instead of a pile of vague notes. ## Workflow 1. Read the diff: list the files touched, group them by what they do together, and note the kind of change: feature, fix, docs, refactor, test, chore, or build. 2. Pick the type and scope: choose the conventional type that fits the change, and a scope drawn from the area of the code touched, such as the module or feature name, not from the branch name. 3. Write the subject line: one line, 72 characters or fewer, in imperative mood, naming the change plainly, for example "fix: handle empty cart before checkout". 4. Write the body: two to five short lines explaining what changed and why it was needed, naming the problem or the request behind the change when the user supplies it, and staying silent on motive when no motive is known. 5. Flag breaking changes: when the diff changes an interface, a config key, or behavior that callers depend on, add a BREAKING CHANGE note describing what breaks and what callers must do instead. 6. Offer one alternative subject line when the first one could be read two ways, so the user can pick the clearer wording without a rewrite round. ## Output Contract - Commit message: a code block with the subject line, a blank line, and the body, ready to paste into git commit. - Type and scope: the type chosen and why it fits, in one line. - Files grouped: the changed files grouped by what they do together. - Breaking change note: present only when the diff actually breaks something callers depend on. - Alternative subject line: one option, only when the first line is ambiguous. - Questions: anything about motive or scope that the diff alone cannot answer, asked instead of guessed. ## Operating Rules - Never run git commit, git push, git amend, or git rebase. The user always runs the commit command themselves. - Never invent a reason for a change. If the user gives no motive, describe the change only, and ask about the why. - Never include a secret, token, password, or private key that appears in the diff. Flag it, leave it out of the message, and tell the user to remove it from the change. - Never write a subject line longer than 72 characters, and never pad a thin change with filler just to look thorough. - Never claim a change is a fix when it only refactors, and never call a refactor a feature. The type must match the diff. - If the diff mixes two unrelated changes, say so and draft one message per change, instead of forcing one message to cover both.

• Freelance Rate Calculator

  Turns target income, expenses, and billable hours into an hourly floor and a day rate.

  skillMoney & financehourly floorday rateproject quotenegotiation rangemath breakdownquote note

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Freelance Rate Calculator skill, save the skill source below as ~/workspace/skills/freelance-rate-calculator/SKILL.md, then tell Muse to use it whenever you want to work out what to charge. --- SOURCE --- --- name: freelance-rate-calculator description: Work out a freelance hourly rate, day rate, and project quote from target income, business expenses, taxes set aside, and realistic billable hours. Use when the user says "freelance rate", "what should I charge", "calculate my rate", "hourly rate calculator", "day rate", "quote this project", or wants to raise, check, or defend a price for client work. --- ## Purpose Turn a freelancer's real numbers into a rate that covers income, costs, and time off, with math the user can check and a range they can negotiate from, instead of a price guessed from what others charge. ## Workflow 1. Gather the inputs: target annual take-home pay, yearly business expenses, a taxes set-aside percentage, weeks worked per year, and realistic billable hours per week. Ask for missing numbers, and never fill them in silently. 2. Show the math step by step: add expenses and the taxes set-aside to the target income to get the revenue needed, then divide by total billable hours to get the hourly floor. 3. Build the range: present the hourly floor as the low end, a target rate above it for profit and slow months, and a stretch rate for premium or rush work, each labeled clearly. 4. Price the project: multiply estimated hours by the target rate, add a line for revisions or scope risk when the brief is vague, and show the day rate as eight times the hourly rate or the user's own working day length. 5. Sense-check the result: compare it with the user's current rate, flag it when the floor lands above what the market for that work usually pays, and suggest honest levers: fewer expenses, more billable hours, or a narrower service. 6. Write the quote note: a short paragraph the user can paste into a proposal, stating what the rate covers, what is out of scope, and that revisions beyond the agreed count are billed extra. ## Output Contract - Inputs used: every number, with any assumption flagged as an assumption to confirm. - Math breakdown: revenue needed, billable hours, and each division shown line by line. - Rate range: low, target, and stretch hourly rates, plus the day rate. - Project quote: estimated hours, rate used, total, and any scope-risk line. - Sense-check: how the new rate compares with the current rate, and levers if the floor looks high. - Quote note: ready to paste, covering scope and extra revisions. ## Operating Rules - Never invent expenses, hours, weeks worked, or a tax percentage. If the user does not give a number, ask for it or mark it plainly as an assumption. - Never present the result as tax advice, legal advice, or financial advice. Suggest the user check tax figures with their own accountant. - Never send a quote to a client, accept work, or agree to a price on the user's behalf. The user always makes the final call. - Never round away the story: show the full math, even when the answer is awkward, so the user can spot a wrong input. - Never price from a competitor's rate alone. The floor comes from the user's own numbers first, and market comparison is only a sense-check. - If the brief is vague, price with a stated hours range and a scope-risk line, not a single confident total.

• Appliance Manual Finder

  Turns a brand and model number into key manual facts: settings, care, and error codes.

  skillHomemanual lookupsettings summarycleaning taskserror code meaningsappliance record

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Appliance Manual Finder skill, save the skill source below as ~/workspace/skills/appliance-manual-finder/SKILL.md, then tell Muse to use it whenever you need an appliance manual. --- SOURCE --- --- name: appliance-manual-finder description: Find the manual for a home appliance from its brand and model number, then pull out the settings, maintenance, and error codes that matter. Use when the user says "find my appliance manual", "appliance manual", "what does this error code mean", "how do I clean my dishwasher filter", or gives a brand and model number for a washer, dryer, dishwasher, fridge, oven, or other home appliance. --- ## Purpose Turn a brand and model number, or a photo of the rating plate, into the manual facts the user actually needs, without making them read a long PDF cover to cover. ## Workflow 1. Identify the appliance: ask for brand, model number, and appliance type. If the user has only a photo of the rating plate, read the brand and model from it and confirm them before proceeding. 2. Locate the manual: point the user to the maker's official manual page or document when one is known, and note the exact model the manual covers. 3. Extract what matters: everyday settings, filter and cleaning tasks with intervals, and the error codes the user asked about, each with the manual's stated fix. 4. Flag mismatches: if the model number is partial or matches a different series, say so plainly and ask the user to confirm the full number from the rating plate. 5. Produce the manual brief (see Output Contract) and keep a one-line appliance record the user can reuse next time. ## Output Contract - Appliance line: brand, model, type, and manual source. - Settings that matter: a short list of the modes or settings the user asked about, in plain words. - Care tasks: filter, cleaning, and part replacement tasks with the manual's interval for each. - Error codes: each code asked about, what it means, and the manual's fix, in that order. - Anything not found in the manual is marked "not in the manual" rather than guessed. ## Operating Rules - Never invent a model number, setting, interval, or error code meaning. If it is not in the manual or the maker page, say it is not found. - Never tell the user to open sealed parts, touch wiring, gas lines, or refrigerant lines. For those fixes, say to call a qualified technician. - Never claim a manual covers a model it does not. Partial model matches are flagged, not assumed. - Keep answers short: the brief first, then the details the user asked for, nothing more. - Do not buy parts, book service, or contact the maker on the user's behalf.

• Yard Sale Route Planner

  Turns yard sale listings into one morning route, ordered by opening time and location.

  skillDeal huntingroute orderingconflict flagsskip-first listroute sheet template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Yard Sale Route Planner skill, save the skill source below as ~/workspace/skills/yard-sale-route-planner/SKILL.md, then tell Muse to use it whenever you plan a yard sale morning. --- SOURCE --- --- name: yard-sale-route-planner description: Plan a morning route across yard sales, garage sales, and estate sales from a list of listings. Use when the user says "plan my yard sale route", "yard sale route", "map my garage sales", "plan Saturday garage sales", or shares a list of sale listings with addresses and times. --- ## Purpose Turn a pile of sale listings into one sensible driving route for a morning, ordered by opening time and geography, so the user hits the best sales first and wastes no time backtracking. ## Workflow 1. Collect listings: ask for or accept a pasted list, links, or screenshots with address, start time, end time, and any notes on what is for sale. 2. Normalize each listing: address, start time, rough category of goods, and any must-visit flag the user names. 3. Order the route: cluster sales that sit near each other, start with the earliest openers, and keep travel between stops short. Note any sale that opens later so the user can loop back if time allows. 4. Check for conflicts: flag sales that overlap in a way that forces a choice, and mark which one the user ranked higher. 5. Produce the route sheet (see Output Contract) plus a short note on what to skip if the morning runs short. ## Output Contract - A numbered stop list, each stop with: address, start time, what to look for there, and drive time from the previous stop. - A one-line total: number of stops, estimated start and finish times. - A short "skip first" list for when time runs short, ordered by lowest priority. - Nothing is sent, booked, or messaged to sellers. The route sheet is text only. ## Operating Rules - Never invent addresses, times, or items for sale. If a listing lacks an address or time, mark it "details missing" and leave it off the ordered route until the user supplies them. - Never message sellers, place holds, or negotiate prices. - Never share the user's home address or route with anyone. - Keep the route to what fits in a morning unless the user asks for a full day. - If two sales open at the same time in opposite directions, ask the user which matters more instead of guessing.

• Packing List Builder

  Turns trip details, weather, and activities into a packing list grouped by bag.

  skillProductivityinstructionsworkflowpacking-templatelast-check-list

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Packing List Builder" skill. Its full source is below. Create it at ~/workspace/skills/packing-list-builder/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: packing-list-builder description: Turns trip details, weather, and planned activities into a checked packing list grouped by bag, with a last-check list for the items people most often forget. Trigger phrases: "build my packing list", "what should I pack", "packing list for my trip", "pack for my trip", "trip packing checklist". --- # Purpose Do one narrow job: turn the facts of a trip into a packing list you can actually check off. You give the destination, dates, length, bags you plan to take, weather, and what you will do there: meetings, hiking, a wedding, a beach day, a cold morning run. The skill sorts everything into groups by bag, keeps daily clothes separate from gear, toiletries, and tech, and ends with a short last-check list for the items people most often leave behind: keys, wallet, phone charger, medication, travel documents, and house keys for the return. # Workflow 1. Gather the trip facts before drafting: destination, dates, nights away, bags and their limits, weather forecast or typical weather, activities by day, dress codes, and any items you already know you need, such as a laptop, camera, or sports gear. Ask for what is missing; never guess a dress code or a bag limit. 2. Build the core list first: clothes counted by nights away, with one spare set for delays, plus sleepwear and layers for the coldest and warmest hours, not just the daytime high. 3. Add activity gear next: one group per activity, so a hiking day does not mix with a meeting day. Add toiletries, tech, chargers, adapters, and documents as their own groups. 4. Sort the whole list by bag: carry-on, checked bag, personal item, and day bag. Mark items that must stay in the personal item, such as medication, documents, and chargers you need on the plane. 5. Finish with a last-check list of ten or fewer items to run through at the door, plus a short "buy before you leave" list for anything you do not own yet. # Output Contract - A packing list grouped by bag, with checkboxes - Clothes counted by nights away, with a spare set noted - One group per activity, plus toiletries, tech, and documents - A last-check list of ten or fewer door items - A "buy before you leave" list, kept separate from the packed list - A note on anything you still need to confirm, such as a bag limit or a dress code # Operating Rules - Never guess weather, bag limits, dress codes, or what an activity requires. Ask, or mark the item as unconfirmed. - Count clothes by nights away, not by vague trip length. - Keep medication, documents, and valuables in the personal item group, never in a checked bag group. - Keep the last-check list short. If it grows past ten items, cut it to the items that would ruin the trip if forgotten. - Ask for missing facts instead of filling them in.

• Social Bio Polisher

  Turns your bio facts into platform-ready bios for LinkedIn, X, Instagram, and your site.

  skillCreativeinstructionsworkflowplatform-rulesbio-versions

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Social Bio Polisher" skill. Its full source is below. Create it at ~/workspace/skills/social-bio-polisher/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: social-bio-polisher description: Turns a pile of raw bio facts into platform-ready bios: a LinkedIn headline and opener, an X bio, an Instagram bio, and a short about-page bio, each within that platform's limits and conventions. Trigger phrases: "polish my bio", "rewrite my profile bio", "write my LinkedIn bio", "bios for social media", "about page bio". --- # Purpose Do one narrow job: take your raw facts (what you do, who you help, proof points, links, voice notes) and turn them into a matching set of bios, one per platform, each shaped to that platform's limits and conventions. A LinkedIn headline, an X bio at 160 characters, an Instagram bio at 150 with line breaks that scan on a phone, and a two-paragraph about-page bio, all in one voice, all specific, none stuffed with buzzwords. The point: every profile you own sounds like the same person, and the strongest one, without you rewriting the same paragraph four times. # Workflow 1. Gather the facts before drafting: name, what you do, who you help, your proof points (years, clients, numbers, ships), one personality or voice note, and any links that matter. Ask for what is missing; never invent a title, employer, or stat. 2. Draft the LinkedIn version first: a headline under 220 characters with searchable keywords, plus a two-line about opener that states who you help and how. 3. Cut it down for X: one or two lines, 160 characters max, keywords front-loaded, one link-safe line. Then the Instagram bio: 150 characters max, stacked lines that scan on a phone, one clear call to action or link intent. 4. Expand for the about page: two to three short paragraphs, same voice, a human detail at the end that the short versions had no room for. 5. Present all versions side by side with a character count on each, and add a one-sentence "elevator" bio you can drop anywhere: intros, panels, bylines. # Output Contract - LinkedIn: headline (with character count) plus a two-line about opener - X bio: 160 characters max, with character count - Instagram bio: 150 characters max, stacked lines, with character count - About-page bio: two to three short paragraphs - One-sentence elevator bio - A note on anything you still need to confirm (a number, a title, a link) # Operating Rules - Never invent titles, employers, credentials, or numbers. Flag any claim that came only from assumption and ask. - Keep one voice across all four versions; the platforms change the shape, not the person. - Prefer specific claims over buzzword adjectives; cut "passionate" unless the user insists. - Respect each platform's character limits exactly; show the count on every short bio. - Ask for missing facts instead of filling them in.

• Moving Cost Estimator

  Turns your inventory, distance, and service level into a moving cost estimate.

  skillMoney & financeinstructionsworkflowestimate-templatemover-questions

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Moving Cost Estimator" skill. Its full source is below. Create it at ~/workspace/skills/moving-cost-estimator/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: moving-cost-estimator description: Turns a rough inventory list, origin and destination, move date, and service level into a realistic moving cost estimate with line items and a quote-comparison checklist. Trigger phrases: "estimate my moving cost", "how much will my move cost", "compare moving options", "is this mover quote fair", "moving cost breakdown". --- # Purpose Do one narrow job: build a realistic moving cost estimate before the user talks to any mover. Take a room or item list, the origin and destination, the move date or window, the service level (DIY truck rental, labor-only help, portable containers, full-service movers), and any special items (piano, safe, fragile art). Turn that into a per-service-level estimate with line items, the levers that move the total, and a checklist of questions that make real quotes comparable. The point is simple: walk into quoting armed with your own number, so a padded bid stands out fast. # Workflow 1. Gather the inputs before estimating: the inventory (rooms or an item list), origin and destination, move date or window, preferred service level (or "compare all"), and special items. Ask for anything missing; never invent a distance or a date. 2. Estimate volume: convert the inventory into cubic feet and truck-size equivalents using standard room-volume benchmarks. Show this number; it is the single biggest driver of cost. 3. Build the estimate per service level: base cost ranges from distance and volume bands, then line items for fuel or mileage, valuation coverage, packing materials, storage if the date window needs it, and access fees (stairs, elevator, long carry). Include tipping as its own line. 4. Name the levers: which three inputs move the total most, and how the user can shrink them (pack themselves, pick a mid-month or off-season date, reduce volume before moving). 5. Present a comparison across service levels plus a quote-comparison checklist: the questions that make every bid apples to apples, including how the mover charges for access, stairs, and packing materials. # Output Contract - A cost estimate per service level as a low/high range, with the assumptions shown - A line-item breakdown: transport, labor, fuel, insurance or valuation, materials, storage, access fees, tipping - The three biggest levers and how to shrink each - A quote-comparison checklist for collecting real bids - A statement of what information would sharpen the estimate # Operating Rules - Never present a range as a quote; label every figure an estimate and show the assumptions behind it. - Never drop a bulky or special item from the estimate without asking about it first. - Ask for origin, destination, and date before estimating; never invent distances or guess the move date. - Keep estimates in ranges. Moving costs vary too much for single numbers. - Never recommend a specific moving company or book anyone.

• Unit Price Comparator

  Does the unit-price math on your shopping list so the cheapest sticker stops winning.

  skillShoppinginstructionsworkflowunit-normalizershrinkflation-checklist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptPaste this entire block into a Muse chat to install the Unit Price Comparator skill. Muse will create the skill file at ~/workspace/skills/unit-price-comparator/SKILL.md using the source after the marker below. --- SOURCE --- --- name: unit-price-comparator description: Compares unit prices (per oz, per lb, per sheet) across stores and package sizes so you always buy the cheapest per-unit option. Trigger phrases: unit price, price per unit, bulk deal, cheapest per ounce, grocery math, compare sizes. --- ## Purpose Sticker prices mislead. A family-size bag that costs more can be cheaper per ounce, and a sale item can cost more per unit than the regular brand beside it. This skill does the unit-price math on a shopping list and tells you which option costs least per usable unit, after adjusting for packaging tricks like concentrated formulas and different serving counts. ## Workflow 1. Ask for the shopping list and the candidate products or stores: paste labels, photos, links, or receipt lines. 2. For each item, collect the price and the net quantity (oz, lb, count, fl oz, sheets, loads, servings). 3. Normalize to a common unit per product type (per oz for coffee, per sheet for paper towels, per load for detergent). 4. Flag traps: shrinkflation (same package, less product), concentrated or diluted products, and club-pack quantities you cannot finish before they spoil. 5. Rank options cheapest-per-unit first, then give a final pick per item and the total expected spend. ## Output Contract Reply with a table per product: product, size, price, unit price, and a verdict column naming the winner. Follow with two lines: the total for the full list under the recommended picks, and the difference versus the worst per-unit option. ## Operating Rules - Never assume a size or a price; if a quantity is missing, ask or mark it unknown. - Use the units the shopper thinks in; convert only when the comparison requires it. - Do not recommend bulk buys of perishables beyond what the user says they can finish. - Do not place orders or check live prices; work from the data the user provides.

• Release Notes Writer

  Turns commits and merged PRs since the last tag into a changelog draft worth shipping.

  skillDev & automationinstructionsworkflowchangelog-templatemigration-notes

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Release Notes Writer" skill. Its full source is below. Create it at ~/workspace/skills/release-notes-writer/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: release-notes-writer description: Turns commits and merged PRs since the last tag into a clean changelog or release-notes draft, grouped by breaking changes, features, fixes, and chores. Trigger phrases: "write release notes", "draft a changelog", "summarize this release", "what changed since v", "cut release notes". --- # Purpose Do one narrow job: turn the raw history since your last release tag into release notes a human would be proud to ship. Point it at a repo and a tag (or the previous release), and it reads the commits and merged PRs in between, groups the changes by impact (breaking changes, new features, fixes, chores), and drafts notes written for the reader of the release, not the author of the commit. It names what changed, who it affects, and how to migrate when behavior changed. # Workflow 1. Identify the range: the previous release tag and the current HEAD (or the new tag you are about to cut). Confirm both with the user if they are ambiguous. 2. Collect the raw material: commit subjects since the previous tag, plus merged PR titles and labels when the repo uses them. 3. Sort every change into groups: Breaking changes, New features, Fixes, Chores and internals. Reword cryptic commit subjects into plain descriptions of what changed and why it matters to the person using the software. 4. For breaking changes, add a migration note: what the old behavior was, what the new behavior is, and the smallest change a user must make. 5. Draft the notes in a standard shape: version header, highlights line (the two or three changes that matter most), then the grouped lists. Keep each bullet to one line. 6. Present the draft and ask which entries to cut or keep before finalizing. Never invent changes that are not in the commit history. # Output Contract - A version header with the new tag and date - A highlights line: the two or three most important changes - Grouped bullets: Breaking changes, New features, Fixes, Chores - Migration notes attached to every breaking change - A note on any commit that could not be classified, rather than dropping it silently # Operating Rules - Never invent a change that is not in the commits or merged PRs. - Never bury a breaking change in the fixes list; it always gets its own group and a migration note. - Write for the reader of the release, not the author of the commit: plain words, no internal jargon. - Keep bullets to one line; cut entries the user flags as noise. - Ask which tag range to use when it is ambiguous, instead of guessing.

• Open Box Hunter

  Finds open-box, refurbished, and clearance deals on one product, ranked by savings.

  skillDeal huntinginstructionsworkflowprice-comparisoncondition-checklist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Open Box Hunter" skill. Its full source is below. Create it at ~/workspace/skills/open-box-hunter/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: open-box-hunter description: Finds open-box, refurbished, and clearance deals on a product you name: compares retailer prices, checks condition grades, and ranks offers by real savings. Trigger phrases: "find an open-box deal on", "cheapest refurbished", "clearance price for", "open box deals", "refurbished alternative". --- # Purpose Do one narrow job: when you already know the product you want but would rather not pay full retail, find the best discounted way to buy it. The skill searches open-box listings, certified refurbished stock, and clearance markdowns across major retailers, compares the effective price (after shipping, tax, and warranty differences), and ranks offers by true savings against the current new price. It never hides what is missing: every verdict shows condition, accessories, return window, and warranty side by side, so a cheap price with a 14-day return and no charger does not win by accident. # Workflow 1. Collect the inputs: the exact product name or model number, your acceptable condition grades (open-box excellent, good, or fair; certified refurbished; store clearance), your max budget, and whether accessories and manuals must be intact. 2. Establish the baseline: find the current new price from a major retailer, not the list price, so savings are measured against what you would actually pay today. 3. Build the candidate list: check the big open-box sources (Best Buy open-box, Amazon Warehouse, manufacturer refurbished stores, manufacturer clearance pages), plus reputable general marketplaces, for the exact model. 4. For each candidate record the price, shipping cost, condition grade, what is included or missing, the return window, and the warranty status. 5. Compute true savings per offer versus the new-price baseline, then rank the offers. Flag any deal where missing accessories or a short return window erase the apparent discount. 6. Present the ranked list with links and a one-line verdict on each: worth it, borderline, or skip. Ask about budget and condition limits before starting if the user did not give them. # Output Contract - The current new price used as the baseline, with its source - A ranked list of offers: price, shipping, condition grade, included and missing items, return window, warranty - True savings per offer versus new, in dollars and percent - A one-line verdict on each offer: worth it, borderline, or skip, with the reason - A note on any candidate that could not be verified with a live listing # Operating Rules - Always compare against the live new price, not the list price, so savings are real. - Never hide missing accessories, short return windows, or warranty gaps in a verdict. Show them next to the price. - Never recommend an offer you cannot verify with a live listing; say which offers you could not check. - Never push the buyer below the minimum condition grade they set. - Never share the buyer's personal or location data in any search you run.

• Review Responder

  Turns customer reviews, good and bad, into on-brand public replies that defuse complaints.

  skillMarketinginstructionsworkflowreply-templatestone-calibration

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Review Responder" skill. Its full source is below. Create it at ~/workspace/skills/review-responder/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: review-responder description: Drafts on-brand public replies to customer reviews: defuses bad reviews, thanks good ones, and moves real problems offline. Trigger phrases: "draft a reply to this review", "respond to this bad review", "write review responses", "review reply". --- # Purpose Do one narrow job: turn raw customer reviews into public replies worth publishing. The skill takes the review text, the star rating, the business name, and your tone, then drafts a reply that sounds like a real human who read the review. For negative reviews it acknowledges, takes the fix offline, and never argues in public. For positive reviews it thanks specifically, names something the reviewer mentioned, and encourages a return visit. You always review and post; the skill only drafts. # Workflow 1. Collect the inputs: the review text, star rating, platform (Google, Yelp, Amazon, TripAdvisor, app store), business name, and your desired tone (warm and casual, professional, playful, formal). 2. Classify the review: praise, complaint, mixed, or spam/suspicious. Spam and policy-violating reviews get a brief factual reply plus a flag-and-report recommendation, not a full engagement. 3. For complaints: open by naming the specific issue (never a generic "sorry for your experience"), take responsibility for the part that is yours, give a private contact path (name, phone or email placeholder), and invite them to reach out. Never argue the facts in public, never admit legal fault, never promise refunds or compensation in the reply. 4. For praise: thank them by naming the specific thing they liked, add one line of personality, and invite them back. Skip the hard sell; a genuine reply earns more than a coupon. 5. For mixed reviews: acknowledge the positive, address the negative with the complaint playbook, and keep the reply shorter than the review. 6. Produce two versions: the recommended reply and a shorter alternate. Both stay under 100 words unless the platform norms differ. Ask for the business details you need before drafting. # Output Contract - The review classification (praise, complaint, mixed, or spam) - A recommended reply under 100 words, ready to copy - A shorter alternate version - A one-line note on what to fill in (contact name, phone, order details) before posting - For spam: a brief reply plus a flag-and-report recommendation # Operating Rules - Never post anything to a review site; you draft, the owner posts. - Never include private customer details in a public reply. - Never promise refunds, discounts, or compensation in a reply unless the owner told you to. - Never argue with the reviewer in public, even when they are wrong. Take it offline. - Never invent facts about what happened. If the complaint is vague, ask for context or keep the reply general and forward it to a private channel. - Match the tone the owner gave you; keep the voice human, not corporate filler.

• Home Maintenance Calendar

  Builds a year-round maintenance schedule for your home and climate: what to do and when.

  skillHomeinstructionsworkflowseasonal-checklisthome-profile-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Home Maintenance Calendar" skill. Its full source is below. Create it at ~/workspace/skills/home-maintenance-calendar/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: home-maintenance-calendar description: Turns your home's details into a year-round maintenance calendar: seasonal tasks, frequencies, DIY-vs-pro calls, and the items you should never skip. Trigger phrases: "home maintenance schedule", "what should I check on my house this season", "build my home maintenance calendar", "home upkeep checklist". --- # Purpose Do one narrow job: keep a house from quietly falling apart. The skill takes a short description of the home and produces a 12-month maintenance calendar: which tasks, when to do them, how hard they are, and which ones you should never skip. It separates safe DIY work from hire-a-pro work, and it flags the high-stakes items (water, safety, HVAC) that cost the most when ignored. # Workflow 1. Ask for the home profile: home type (single-family, condo, apartment, townhouse), age of the home, region or climate, and which systems it has (forced-air heat, central AC, gas fireplace, sump pump, septic, chimney, gutters). 2. Build the 12-month calendar from seasonal tasks plus frequency-based tasks (monthly, quarterly, yearly). For each task give the month or interval, a one-line what-and-why, and the effort level (15 minutes, an hour, half a day). 3. Mark every task DIY or hire-a-pro. Electrical, gas, and roof-slope work are always hire-a-pro. For pro work, include a rough cost range so the user can budget. 4. Name the never-skip list: the 5 tasks where skipping costs real money or creates real danger (smoke and CO detectors, gutters and drainage, furnace filter, dryer vent, water shutoff valve check). Explain the consequence of skipping each one. 5. Suggest a reminder cadence: which tasks pair well with a monthly or quarterly nudge. Do not create any calendar events or reminders; just propose the schedule and ask before any action. 6. If the user rents, reframe everything: what is the tenant's job, what belongs to the landlord, and what to document in writing before calling. # Output Contract - A month-by-month calendar of tasks with effort level and one-line what-and-why - DIY vs hire-a-pro callout on every task, with rough pro cost ranges - A never-skip list of 5 items with the consequence of skipping - A suggested reminder cadence, no reminders created - Renter reframing when the user rents Keep the whole answer scannable: the calendar as a list, then the never-skip list, then the cadence. # Operating Rules - Never advise touching electrical panels, gas lines, or walking a steep roof. Those are always hire-a-pro, no exceptions. - Never invent local code requirements or recall notices. - Tune the calendar to the stated climate: freeze protection only where it freezes, humidity tasks only where it applies. - Never create calendar events, reminders, or contact a contractor without being asked explicitly. - Keep tasks concrete. "Check gutters" is not enough; say what to look for.

• Spec Sheet Translator

  Turns dense product specs into plain buying advice: what matters and what is fluff.

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

• Release Radar

  Watches the repos you name and summarizes new releases, skipping the noise.

  skillDev & automationinstructionsworkflowrepo-watch-list

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Release Radar" skill. Its full source is below. Create it at ~/workspace/skills/release-radar/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: release-radar description: Watch a list of repos for new releases and get a short summary of the ones that matter to you. Trigger phrases: "what did I miss", "repo updates", "new releases", "check release radar". --- # Purpose Do one narrow job: keep you current on the projects you actually use. You name the repos you care about, and on each check the skill looks for releases newer than the last check, reads the release notes, and gives you a short rundown of what changed and why it might matter. Everything it reports is marked as seen, so you never read the same release twice. # Workflow 1. Set up your watch list: repo names (owner/name) plus one line on why each matters to you, for example "my blog's framework" or "the linter in CI". Add or remove entries anytime. 2. On each run, check every repo for releases newer than the last recorded check. Record a timestamp and the newest release seen per repo. 3. For each new release, read the release notes and write a two to four line plain-language summary: the version, the headline change, and who should care. Flag breaking changes, security fixes, and new features. 4. Rank the summaries: breaking changes first, then security fixes, then features, then everything else. Bugfix-only patch releases get one line, never a paragraph. 5. Mark everything reviewed as seen, so the next check reports only what is new. A repo with no new release is not mentioned; silence is the correct output for a quiet week. 6. When release notes are vague, say so and link the release page instead of guessing what changed. # Output Contract - Per repo with a new release: version, headline summary (2-4 lines), and flags: breaking change, security fix, or feature - Order: breaking changes, then security fixes, then features, then patch notes - Quiet repos: omitted entirely - End with the count of repos checked and the count with new releases Keep the whole digest under 25 lines unless the user asks for more. # Operating Rules - Never invent release details. If the release notes are empty or vague, link the release page and say the notes are thin. - Never mark a release as seen without reporting it first. - Do not clone repositories or run code; read release metadata only. - Never access private repositories unless the user explicitly names the repo and provides a way to read it in this session. - Never recommend upgrading a dependency. Describe what changed; the user decides. - If a check fails for a repo (rate limit, moved repo, 404), report the repo name and the failure, and try again next run.

• Ad Hook Researcher

  Finds the ad hooks already winning in your niche and turns them into a creative brief.

  skillMarketinginstructionsworkflowbrief-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Ad Hook Researcher" skill. Its full source is below. Create it at ~/workspace/skills/ad-hook-researcher/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: ad-hook-researcher description: Collect winning ad hooks in a niche from a product URL into a creative brief. Trigger phrases: "research ad hooks", "find winning hooks", "build an ad hook brief". --- # Purpose Find the ad hooks already winning in your niche and hand them to you as a creative brief you can work from. You give a product URL (or a niche description), and Ad Hook Researcher returns a hook bank, the patterns behind the hooks, the angles nobody is using, and three starter hook drafts written for your product. # Workflow 1. Read the product URL or niche description. If you gave both, use the page to ground the niche read; if you gave one, start there. 2. Read the product's own landing page: headline, subhead, hero claims, pricing framing, and the promises on the page. This is the baseline the brief adapts hooks for. 3. Search the niche for active ads: public ad libraries, competitor landing pages, and ad creative roundups. Note which ads or hooks keep showing up across sources; persistence is an observed signal, not proof of performance. 4. Extract each hook: the first five to ten words plus its angle. Tag the angle: transformation, curiosity gap, direct callout, proof, offer, or contrast. 5. Cluster the hooks by angle and note which clusters dominate the niche and which angles are missing entirely. 6. Keep only hooks from ads that were actually found. Never invent ad text. Quote short hooks verbatim; summarize longer ones. 7. Write three starter hooks for the product, clearly marked as drafts, each using a different winning angle from the niche. 8. Write the creative brief in the Output Contract shape and send it. # Output Contract The creative brief, in this order: - Niche snapshot: what your page leads with today, in three lines - Hook bank: 10 to 15 hooks, each with an angle tag and the source type it was found in - Pattern notes: three to five recurring patterns across the niche - Gaps: angles the niche is not using, with one line on why each could fit - Starter hooks: three drafts for your product, marked as drafts, each using a different winning angle - Sources checked: a short list of what was actually read # Operating Rules - Read public pages and public ad libraries only. Never log in, and never work around a paywall or a bot check. - Never present persistence as proof of performance. Say what was observed. - Never invent ad copy. Every hook in the bank comes from a real page or ad that was read during the run. - Never buy media, post an ad, or contact a competitor. Research only. - If the niche is too thin to fill the hook bank, deliver what was found and say what is missing rather than padding it. - Run once per request; do not re-run on a schedule unless asked.

• Daily Journaler

  Turns end-of-day notes into a structured journal entry in your notes system.

  skillProductivityinstructionsworkflowtemplate

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Daily Journaler" skill. Its full source is below. Create it at ~/workspace/skills/daily-journaler/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: daily-journaler description: Turn rough end-of-day notes into a structured daily journal entry for your notes system. Trigger phrases: "journal today", "write my journal entry", "turn my notes into a journal entry". --- # Purpose Turn the user's raw end-of-day notes into a clean, structured journal entry that fits their notes system (Obsidian, Apple Notes, or plain markdown files). The entry captures what happened, what got done, what is still open, and what the user wants to remember, in the user's own words, tightened up and organized. # Workflow 1. Read the user's raw notes for the day: pasted text, dictated thoughts, or a pointer to an inbox note. 2. Ask for the notes-system format only on first use (Obsidian daily-note template, Apple Notes, or plain markdown), then reuse it without asking again. 3. Extract events, decisions, completed items, open loops, and anything the user explicitly marked as worth remembering. 4. Organize the entry into sections: Highlights, Completed, Open loops, Notes to self. Drop a section if it would be empty. 5. Preserve the user's phrasing where possible; tighten wording rather than rewriting in a different voice. 6. Never invent facts the notes did not contain. If something is unclear, flag it with a question instead of filling it in. 7. Present the entry as a markdown draft the user can paste into their notes system. If the user has a daily-note naming convention, use it for the file name suggestion. # Output Contract A markdown journal entry dated for the day being journaled, with sections in this order (skipping empty ones): - Highlights: the 1 to 3 moments that mattered most - Completed: what got finished, one short line each - Open loops: what is still pending, with the next action where known - Notes to self: reminders, ideas, or observations for later After the entry, a single line suggests the file name for the user's notes system. # Operating Rules - Never publish, send, or share a journal entry. It stays private to the user. - Never combine notes from more than one day into a single entry unless the user explicitly asks. - Never invent events, feelings, or facts the notes did not state. Mark gaps as questions. - Never rewrite the user's voice into formal or marketing copy; tighten, do not transform. - Keep the entry skimmable: short lines, no paragraph longer than two sentences. - Run only when asked; do not journal unprompted.

• Bedtime Story Weaver

  Turns a child's details into a short tale with a recurring hero.

  skillCreativeinstructionsworkflowcontinuity-log

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Bedtime Story Weaver" skill. Its full source is below. Create it at ~/workspace/skills/bedtime-story-weaver/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: bedtime-story-weaver description: Weave a personalized bedtime story for a child, starring a recurring hero across nights. Trigger phrases: "weave a bedtime story", "tell a story with our hero", "continue last night's story". --- # Purpose Turn a child's details into a short, cozy tale starring a recurring protagonist who grows with the child. The hero persists across nights: names, friends, and favorite places carry over, so each new story feels like the next chapter of one ongoing adventure. # Workflow 1. Ask for the child (first name, age), the hero (name, species or kind, one personality trait), and tonight's theme or setting if the user has one. 2. Load the hero profile and continuity log from prior runs: who the hero knows, where they have been, what they learned. 3. Build tonight's outline: one small quest or problem, one helper character (new or returning), one gentle lesson, and a calm ending that winds the energy down. 4. Draft the story for reading aloud: 5 to 8 minutes of reading, simple sentences for younger ages, slightly richer language for older kids. 5. End with an optional soft cliffhanger: a hint of tomorrow's adventure that invites sleep, never suspense. 6. Update the continuity log with new characters, places, and lessons so the next story can reference them. # Output Contract The story text, ready to read aloud, followed by three lines: - Hero update: what changed for the hero tonight - Tonight's gentle point: the lesson, stated simply - Tomorrow's hint: one sentence, only if a cliffhanger was requested First run also returns the hero profile card for approval before the first story is written. # Operating Rules - Never write frightening, violent, or age-inappropriate content. If a theme is too dark, steer it gentle and say why. - Never introduce real people without the user's permission; use the hero and fictional friends. - Never keep personal details the user has not approved for the hero profile. Ask before adding anything new to the profile. - Keep the story length right for reading aloud: under ten minutes unless the user asks for more. - If the child is scared or restless mid-story, offer a shorter, calmer ending instead of pushing through.

• Reconciliation Checker

  Compares two money sources line by line and flags every mismatch.

  skillMoney & financeinstructionsworkflowreport format

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Reconciliation Checker" skill. Its full source is below. Create it at ~/workspace/skills/reconciliation-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: reconciliation-checker description: Compares two money sources (invoices vs spreadsheet, payouts vs bank export) and flags every mismatch. Trigger phrases: "reconcile my invoices", "check my reconciliation", "find the mismatches". --- # Purpose Find every line that does not agree between two records of the same money. Typical pairs: invoices against a tracking spreadsheet, payout reports against a bank export, donation receipts against a ledger, platform sales against deposited amounts. Reconciliation Checker normalizes the two sources, matches their lines, and reports what matches, what is missing on either side, and what disagrees. # Workflow 1. Ask which two sources to compare, and get both in a readable form: CSV, spreadsheet, pasted text, or a structured list the user provides. Do not proceed on only one side. 2. Ask which field is the match key: invoice number, order ID, date plus amount, or a combination. Confirm the date format and the currency before matching. 3. Normalize both sources: trim whitespace, standardize dates to one format, and express amounts as plain numbers. Note which side needed the most cleanup; that is where errors hide. 4. Match lines on the agreed key. Mark each line as: matched, only in source A, only in source B, or matched but with a differing field. 5. For lines matched but disagreeing, record the field, the value on each side, and the difference in plain numbers. 6. Sort findings by impact: amount differences first (largest first), then lines present on one side only. 7. Write the report in the Output Contract shape and send it. # Output Contract - Summary: counts of matched lines, lines only in A, lines only in B, and lines with amount differences, plus the total dollar value of all differences. - Mismatch table: one row per issue, in impact order. Each row has the match key, the issue type, the value in source A, the value in source B, and the difference. - Cleanup note: what was normalized, so the user can judge whether the matches are trustworthy. - Next step suggestion: a plain sentence on where to look first (for example, "two payouts are missing on the bank side; check the payout delay policy"). No diagnosis is presented as fact. # Operating Rules - Never edit, overwrite, or append to either source file. Work on copies in memory and report the findings. - Never move money, pay a bill, or contact a bank, client, or platform on the user's behalf. Flag only. - Never treat a guessed match as confirmed. If the match key is ambiguous, say so and list the candidates separately. - Never fabricate a line to make the totals balance. Unmatched lines stay unmatched in the report. - Never share the report or the source data with anyone but the user.

• Lead Scorer

  Scores a list of public leads against your ideal customer profile and ranks them.

  skillMarketinginstructionsworkflowscoring-rubric

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Lead Scorer" skill. Its full source is below. Create it at ~/workspace/skills/lead-scorer/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: lead-scorer description: Score public leads against your ideal customer profile and rank them. Trigger phrases: "score these leads", "rank my leads", "which leads first". --- # Purpose Stop working your lead list in alphabetical order. Lead Scorer takes the list you hand it, scores each lead against the ideal customer profile you define, and returns a ranked list with the evidence behind every score. You see exactly why a lead sits at the top or the bottom, so your outreach starts with the people most likely to be a fit. # Workflow 1. The user provides the ideal customer profile: industry, company size, role titles, signals that suggest fit (hiring, funding, tech stack), and deal breakers. 2. The user provides the lead list: names plus whatever public data they have per lead (company, title, location, public posts, listing details). 3. Score each lead 0 to 100: fit signals add points, missing basics subtract, deal breakers zero the score. Record the evidence for every point. 4. Rank the list high to low. Group obvious tiers: reach out now, nurture later, skip. 5. Deliver the ranked list with one evidence line per lead, plus the rubric used, so the user can reweight it. # Output Contract Each run delivers: - The ranked lead list with 0-100 scores - One evidence line per lead showing why it scored that way - Three tiers: reach out now, nurture later, skip - The rubric, written out, so scoring stays repeatable A score is a ranking aid, not a verdict. The user reviews the evidence before acting on it. # Operating Rules - Score only public data and what the user provides. Never scrape private accounts, and never use bought or breached data. - A deal breaker zeroes the score but keeps the lead visible, flagged, with the reason shown. - Never inflate a score to be encouraging. A weak list gets weak scores, honestly. - The rubric is fixed for the whole list. Never reweight mid-list to favor one lead. - Draft no outreach and contact nobody. Scoring ends where outreach begins, and a human writes and sends every message. - Keep the user's lead list private to their workspace.

• Research Brief Builder

  Gathers multi-source research into a brief with sources, key findings, and open questions.

  skillProductivityinstructionsworkflowbrief-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Research Brief Builder" skill. Its full source is below. Create it at ~/workspace/skills/research-brief-builder/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: research-brief-builder description: Turn scattered research into a structured brief with sources, findings, and open questions. Trigger phrases: "build a research brief", "research this for me", "brief me on". --- # Purpose Replace the tab sprawl with one document you can trust. Research Brief Builder gathers research from the sources you name or that are publicly reachable, distills it into key findings, and lays it out as a structured brief: question asked, what each source says, where they agree, where they conflict, and which questions are still open. Every claim carries its source, so you can check the original in seconds. # Workflow 1. The user states the research question and any constraints: sources to prefer, sources to exclude, deadline for currency (e.g. "only 2025 or newer"). 2. Gather the research from the named or publicly available sources. Note the publication date of each source. 3. Extract findings per source in the source's own terms before any synthesis. Do not mix sources into one voice. 4. Synthesize: agreement points, conflicts, and the gaps no source covers well. 5. Write the brief in the template below and deliver it with the source list, each claim linked to the source that made it. # Output Contract Each brief contains: - The question, restated in one line - Key findings: 3 to 7 bullet points, each with its source - Where sources agree, and where they conflict - Open questions the research did not answer - A source list with publication dates and links where public If fewer than three solid sources turn up, say so plainly and deliver the thin brief rather than padding it. # Operating Rules - Never invent a citation. If a claim cannot be traced to a source you actually read, drop the claim. - Never reach paywalled, logged-in, or private accounts. Only public pages and sources the user provides. - Distinguish what a source says from what you infer. Inferences get flagged as your reading, not the source's claim. - When sources conflict, report the conflict. Never pick a winner silently. - Keep findings proportional to evidence: one source is a hint, not a consensus. - Never act on the research: no purchases, no outreach, no decisions. The brief informs; the user decides.

• Report Watchdog

  Checks incoming reports against rules you set and flags anomalies while the day is live.

  skillProductivityinstructionsworkflowrules

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Report Watchdog" skill. Its full source is below. Create it at ~/workspace/skills/report-watchdog/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: report-watchdog description: Watch incoming reports against rules you set and flag anomalies while the day is still live. Trigger phrases: "watch these reports", "flag bad reports", "set up report watchdog". --- # Purpose Catch bad reports before the day is over. Report Watchdog holds a set of rules you define once, checks each incoming report against them as reports arrive, and raises a flag the moment something looks wrong: a skipped checklist item, a number far outside the normal range, a missing photo, or a report that never arrived at all. # Workflow 1. The user defines the rules once: what a good report contains, what a good report looks like numerically, and when each report is due. Rules live in the watch config until the user changes them. 2. Each time a new report arrives, check it against the rules. Checklists must be complete, numbers must fall inside the expected ranges, required attachments must be present. 3. Compare the report against recent history for the same source. Flag anything that shifts sharply: a total that doubles, a reading that collapses, a value that is flat for the fifth run in a row. 4. Track what is due. If a report has not arrived by its due time, flag the absence. 5. For every flag, write one entry: which report, which rule broke, and the evidence. Group related flags from the same source into one alert so one bad day does not become ten messages. 6. If nothing broke, stay quiet. A clean check produces no message. # Output Contract One alert per source with a problem, containing: - Source and report time - The rule that broke, in plain words - The evidence: the value or gap that tripped it - What was normal: the recent baseline for comparison No problems: no message at all. This job is quiet by design. # Operating Rules - Never edit, correct, or re-file a report. Flag only. - Never contact the person who filed the report, or anyone else about it. The user handles every follow-up. - Never invent a rule. Every check runs against a rule the user wrote, and the alert always names it. - Never lower a threshold to quiet the noise without the user's say-so. If rules produce too many flags, report the pattern and propose new thresholds for approval. - Keep the alert short. One screenful per source, most days one alert at most.

• Voice Matched Writer

  Learns your voice from writing samples, then drafts new posts in it.

  skillCreativeinstructionsworkflowvoice-profile

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Voice Matched Writer" skill. Its full source is below. Create it at ~/workspace/skills/voice-matched-writer/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: voice-matched-writer description: Learn a writer's voice from their samples, then draft new posts in it. Trigger phrases: "write this in my voice", "match my voice", "draft a post like me". --- # Purpose Write like yourself on a busy day. Voice Matched Writer builds a voice profile from writing samples you provide, then drafts new posts, captions, or updates that sound like you wrote them: your sentence rhythms, your vocabulary habits, your humor level, your openings and closings. The goal is a draft that needs light edits, not a rewrite. # Workflow 1. The user provides 5 to 15 samples of their own writing in the target form: posts, captions, scripts, newsletters. More than 15 dilutes the profile; fewer than 5 makes it generic. 2. Read the samples and extract a voice profile: sentence length patterns, favorite words and phrases, punctuation habits, rhythm, humor style, how pieces open and close, what the voice never does. 3. Save the voice profile. It persists until the user replaces it or adds more samples. 4. When the user asks for a draft, read their brief: topic, key points, length, platform, and anything to avoid. 5. Draft to the brief first, then apply the voice profile. Accuracy on the content always outranks style matching. 6. Deliver the draft with a short note on the two or three voice traits applied most strongly, so the user can judge whether the match feels right. # Output Contract Each draft comes with: - The draft itself, sized to the platform - The brief it answers, restated in one line - Two or three voice traits applied, named briefly The user edits or approves. Nothing publishes on its own. # Operating Rules - Never publish, post, schedule, or send a draft anywhere. Draft only, every time. - Never learn a voice from anyone else's writing. Samples must be the user's own, or work they have the right to reuse. - Never use the samples for anything besides building the profile, and never quote them back in new drafts. - If the samples show two or more distinct voices, say so and ask which one to keep before writing. - If the brief conflicts with the voice (a formal topic in a casual voice), flag the tension instead of forcing the match. - Keep the user's voice profile in their workspace, and treat it as private: never copy it to another user or skill.

• Prospect Reply Drafter

  Reads a prospect's reply in the context of the thread and drafts the right next step.

  skillMarketinginstructionsworkflowtemplates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Prospect Reply Drafter" skill. Its full source is below. Create it at ~/workspace/skills/prospect-reply-drafter/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: prospect-reply-drafter description: Read a prospect's reply in the context of the thread and draft the right next step. Trigger phrases: "draft a reply to this prospect", "how should I respond", "write a follow-up for". --- # Purpose Read a prospect's latest reply together with the full thread history, figure out what the prospect is actually signaling, and draft the single best next move. It classifies the reply, an objection, a timing deferral, a referral, a polite no, or genuine interest, and writes a response matched to that signal instead of a generic follow-up. # Workflow 1. Read the full thread: your outreach, their reply, and any earlier exchanges. Ask for the offer or call to action if it is not clear from the thread. 2. Classify the reply: interested, objection, timing deferral, referral, polite no, or ambiguous. 3. Identify the signal underneath the words: what they care about, what is blocking them, what would change their mind. 4. Draft one reply: short, specific, and matched to the classification. Handle objections by addressing the block, not by arguing. 5. Give the human a send-or-edit choice: the draft plus two alternate lines for the risky spots. # Output Contract - Classification: one label plus the evidence line from the reply. - Signal read: what the prospect cares about and what blocks them, in two bullets. - Draft reply: subject or opener plus body, ready to paste, under 120 words. - Alternates: two rewrite options for the key line. # Operating Rules - Never send anything; the human reviews and sends every reply. - Never invent facts about the product, pricing, or the prospect. - Never guilt-trip, never pressure, never fake a personal connection. - If the reply is a no, draft a graceful close, not a rescue attempt.

• Support Ticket Miner

  Groups repeat support ticket issues and suggests help-doc updates and marketing angles.

  skillProductivityinstructionsworkflowtemplates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Support Ticket Miner" skill. Its full source is below. Create it at ~/workspace/skills/support-ticket-miner/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: support-ticket-miner description: Scan support tickets, cluster repeat issues, and suggest help-doc updates and marketing angles. Trigger phrases: "mine my support tickets", "what are customers complaining about", "find repeat support issues". --- # Purpose Turn a batch of support tickets into an evidence-backed map of what customers keep running into: the repeat issues, the wording they use, and the gaps in your docs. It reads the tickets you give it, groups the problems into clusters, and hands you two things: which help articles need rewriting, and which customer pains are worth talking about in marketing. # Workflow 1. Read the ticket batch: exported CSV, pasted threads, or a connection you provide. Ask for the product name and date range if they are missing. 2. Normalize each ticket to one core problem in one sentence. 3. Cluster tickets by underlying problem, not by surface wording; count each cluster and pull 2-3 representative quotes. 4. For each top cluster, diagnose the root cause as product, docs, or messaging, and propose a fix in one line. 5. Map clusters to help docs: which articles cover them, which are missing, which need a rewrite based on real customer language. 6. Draft marketing angles from the sharpest pains, using the customers' own words, labeled as drafts only. # Output Contract - Cluster table: problem, ticket count, share of batch, sample quotes, root cause category. - Help-doc plan: rewrite list, new-article list, exact customer phrases to borrow. - Marketing angles: 5-10 one-line angles, each tied to a cluster, marked as drafts for human review. # Operating Rules - Never close, delete, or reply to a ticket. - Never publish a help-doc change or marketing copy without human approval. - Never invent tickets or quotes; every claim traces to a ticket in the batch. - Quote real customer language; do not smooth it into corporate phrasing.

• Ad Spend Auditor

  Audits an ad spend export, flags wasted spend, and suggests creative refresh angles.

  Tested in MuseskillMarketinginstructionsworkflowreport

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Ad Spend Auditor" skill. Its full source is below. Create it at ~/workspace/skills/ad-spend-auditor/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: ad-spend-auditor description: Audit an ad spend export for wasted spend and creative fatigue, then suggest refresh angles. Trigger phrases: "audit my ad spend", "review my ad spend", "find wasted ad spend". --- # Purpose Find the specific places where ad money is burning: campaigns with rising cost per result and no conversions, ad sets spending on narrow segments that never convert, and creative that has run so long its frequency is climbing while its click-through rate falls. Report waste first and refresh ideas second, all from one export. # Workflow 1. Read the ad spend export: a CSV or pasted table with at least campaign, ad set, ad name, spend, impressions, clicks, conversions, and the date range. Ask which platform and range if either is unclear. 2. Compute per campaign and per ad set: spend, impressions, CTR, cost per click, cost per result, and conversion count. 3. Flag spend without results: anything over the user's waste threshold (ask for one; default $50) with zero conversions. 4. Flag fatigue: ads where frequency is rising and CTR is falling across the range, or the same creative live more than 30 days with falling performance. 5. Flag overlap waste: ad sets on the same platform targeting near-identical audiences with near-identical creative. 6. For each flagged item, draft one concrete refresh angle: a new hook, a new audience slice, or a pause recommendation, grounded in the numbers. 7. Write the report in the Output Contract shape. Never adjust a budget or pause anything; analysis only. # Output Contract - Waste table: item, spend, results, and why it is flagged. - Fatigue table: creative, days live, CTR trend, frequency trend. - Refresh angles: one short line per flagged item, most spend first. - One-paragraph summary naming the single biggest burn. # Operating Rules - Never change bids, budgets, audiences, or campaign status; read-only analysis. - Never invent numbers; every figure comes from the export. - Ask for missing columns before guessing. - Keep the report short enough to act on in one sitting.

• Invoice Drafter

  Turns completed work and timesheet lines into a draft invoice; a human always sends it.

  Tested in MuseskillMoney & financeinstructionsworkflowtemplates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Invoice Drafter" skill. Its full source is below. Create it at ~/workspace/skills/invoice-drafter/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: invoice-drafter description: Turn completed work and timesheet lines into a draft invoice and a client-ready summary. Trigger phrases: "draft an invoice", "make an invoice for", "invoice my client". --- # Purpose Turn a list of completed work into a draft invoice plus a plain-language summary a client can read without asking follow-up questions. The human always reviews and sends; the skill never sends anything. # Workflow 1. Read the work: timesheet lines, project notes, or a paste of completed tasks. Ask for the client name, rate, currency, and billing period if any are missing. 2. Group the lines into invoice items: date or milestone, a description of the work in client language, hours or quantity, rate, line total. 3. Compute subtotal, tax if the user gives a rate, and total. Show the math so the human can check it. 4. Draft a client-ready summary: what was done, in what period, and the total due, in two or three short paragraphs. 5. Write the draft in the Output Contract shape. Never mark it final, never send it, never change a price without asking. # Output Contract - Draft invoice: client name, billing period, line items (description, hours or quantity, rate, line total), subtotal, tax, total due, payment terms placeholder. - Client summary: short prose recap of the work and the total. - Questions list: everything the skill had to assume, so the human can verify before sending. # Operating Rules - Never send the invoice or contact the client. - Never finalize, mark paid, or change a price on your own. - Never invent hours, rates, or dates; flag gaps as questions. - A human reviews and sends. Every time.

• Auction Bid Calculator

  Sets a hard bid ceiling for an auction lot after fees, tax, shipping, and your margin.

  Tested in MuseskillDeal huntinginstructionsworkflowcalculator

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Auction Bid Calculator" skill. Its full source is below. Create it at ~/workspace/skills/auction-bid-calculator/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: auction-bid-calculator description: Computes your maximum bid for an estate or online auction lot, accounting for buyer premium, sales tax, shipping, and your target margin. Trigger phrases: "what should I bid", "auction bid ceiling", "is this lot worth bidding on". --- # Purpose Set a hard ceiling for an auction lot before the bidding starts, so the fees and taxes do not turn a win into a loss. # Workflow 1. Read the lot details: item description, current bid, estimate, and the auction's buyer premium percentage and payment terms. 2. Read the sales tax rate for the auction location and the shipping cost if it is not local pickup. 3. Read the target: the item's conservative resale value and the margin the user wants to keep. 4. Compute the ceiling: the highest hammer price such that the hammer price plus buyer premium plus sales tax plus shipping plus any other fees stays at or below the target value after the margin. 5. Show the math line by line, then the ceiling as one bold number. 6. Optionally produce a bid plan: the opening bid and the last comfortable step below the ceiling. # Output Contract - One-line verdict: the maximum hammer price to bid, plus the all-in cost at that price. - A short math breakdown: hammer price, buyer premium, sales tax, shipping, other fees, total. - Target resale value and the dollar margin the plan protects. - If the current bid already exceeds the ceiling, say so in the first sentence and do not propose higher bids. # Operating Rules - Never guess the buyer premium, tax rate, or shipping cost; ask for each value if the user has not supplied it, and mark any assumption plainly when the user approves a default. - Never recommend bidding above the computed ceiling. - Never fabricate resale comps; use comps the user confirms or recent sold data, and state the low end of the range. - Never place bids or access an auction account; this is math and planning only.

• Food Ordering

  Orders coffee or food from chat, with fees and total for your approval before it submits.

  Tested in Museprompt packShoppinginstructionspurchase-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.

• Plant Care Scheduler

  Builds a watering and feeding schedule for your houseplants and adjusts it by season.

  Tested in MuseskillHomeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Plant Care Scheduler" skill. Its full source is below. Create it at ~/workspace/skills/plant-care-scheduler/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: plant-care-scheduler description: Build and maintain a watering, feeding, and repotting schedule for your houseplants. Trigger phrases: "schedule my plant watering", "plant care reminders", "track my houseplants". --- # Purpose Keep every plant in the house on a care rhythm matched to its species, pot size, light, and the season, so nothing gets drowned and nothing gets forgotten. The schedule adjusts through the year: most plants need less water and no fertilizer in winter, and more frequent checks in the growing season. # Workflow 1. Take the plant list: species or common name, pot size, soil type if known, and where each plant sits (window direction or distance from a window). 2. For each plant, look up standard care guidance for its species: watering frequency range, light needs, feeding season and dose, and when it typically needs repotting. 3. Set a watering check interval per plant as a range (for example, every 7 to 10 days), not a rigid single day. A check means testing the top two inches of soil; water only if dry. 4. Mark feeding months for plants that need fertilizer, with the dose type (balanced liquid at half strength, or slow release). 5. Flag repotting candidates: roots circling, water running straight through, or growth stalling in season. 6. Build the weekly schedule: which plants get a soil check each week, which get fed this month, and any repotting or pruning tasks due. 7. When the user reports a plant's condition (droopy, yellow leaves, new growth), adjust that plant's interval and note the change. 8. Track care events with dates so intervals stay anchored to what actually happened. # Output Contract A weekly checklist in this order: - Due checks: plant name, what to do (soil check, water if dry), room - Feeding due: plant name, fertilizer type and dose - Watch list: plants showing symptoms, with the last change noted - Held: anything the user asked to skip If nothing is due, say so in one line and do not pad the list. # Operating Rules - Never invent a plant the user did not list. Ask before adding one. - Never change an interval without noting what changed and why. - Never recommend a fertilizer dose stronger than the standard guidance for the species. - A schedule day is a check day, not a pour day: watering is always conditional on the soil check. - If a plant shows possible disease or pests, describe what it looks like and suggest isolation and identification before any treatment. - Keep the plant list as the single source of truth; confirm before removing a plant that died or was given away.

• 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

  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.

• Reward Card Picker

  Picks the best card in your wallet for a purchase, from rewards rates and active offers.

  Tested in MuseskillMoney & financeinstructionsworkflowcard-wallet-profile

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Reward Card Picker" skill. Its full source is below. Create it at ~/workspace/skills/reward-card-picker/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: reward-card-picker description: Choose the best rewards card from your wallet for a specific purchase. Trigger phrases: "which card should I use", "best card for this purchase", "reward card picker". --- # Purpose Answer one narrow question: of the cards already in your wallet, which one pays back the most for this specific purchase, given each card's rewards rates, active offers, and category caps? It never advises on which cards to get or drop; it picks from what you have. # Workflow 1. Read your card profile: each card's flat earn rate, bonus categories, rotating category status, annual fee, and any active offer such as a welcome spend target or 0% APR period. You set this up once and update it when a card changes. 2. Ask for the purchase: store or merchant, category (for example groceries, gas, travel, dining), and the amount. 3. For each card, compute the expected return: apply the card's rate for that category, check whether a quarterly cap or rotating category applies, and check active offers that change the math, such as a welcome spend threshold close to being met. 4. If a card has a 0% APR window and the user says the purchase will be carried, note it separately; it does not change the rewards math. 5. Rank the cards by expected dollar return, highest first. Break a tie by preferring the card with the simpler earn structure, so the user does not have to juggle portals or bonus clocks. 6. If the purchase category does not match any bonus, recommend the highest flat-rate card and say so plainly. 7. If the expected return differs by less than fifty cents between the top two cards, say they are effectively tied and name both. # Output Contract - Winner: the card to use, named exactly as in your profile - Expected return: dollar amount and rate applied (for example, "$4.60 at 4x on groceries") - Why it wins: one line on the category, offer, or cap that made the difference - Runner-up: the second-best card and its expected return, so you have a fallback - If effectively tied: say so and name both cards Keep it to five lines or fewer unless the user asks for more. # Operating Rules - Only pick from the cards in the user's profile. Never recommend applying for a new card or closing one. - Never ask for or store full card numbers, CVVs, or login credentials. Last four digits are enough for naming. - Never encourage carrying a balance to chase rewards. Interest wipes out cash back every time. - If the card profile is missing a rate for the purchase category, ask the user rather than guess. - Do not factor in lounge access, insurance, or other perks in the rewards math. Mention them only if the user asks. - If a rotating category is not activated in the profile, treat it as not active. Never assume the user activated it.

• Deep Work Scheduler

  Turns weekly priorities into protected calendar focus blocks that survive meeting creep.

  Tested in MuseskillProductivitycalendar scanfocus blocksmeeting-creep defenseweekly reset

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Deep Work Scheduler" skill. Its full source is below. Create it at ~/workspace/skills/deep-work-scheduler/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, offer to run the first scheduling pass and wait for the user's priorities before creating anything. --- SOURCE --- --- name: deep-work-scheduler description: Turns a weekly priority list into protected deep-work calendar blocks, then defends them from meeting creep. You bring the priorities; it places the time-boxed sessions where meetings cannot swallow them. Trigger phrases: schedule my deep work, plan my focus time, protect my calendar, book deep work blocks. ## Purpose Plans focused work sessions for the week ahead and places them on your calendar where meetings cannot swallow them. You bring the priorities; the skill turns them into time-boxed blocks with start times, durations, and a clear outcome per block. ## Workflow 1. Collect the week's priorities: ask the user to list 1 to 3 outcomes that need focused work this week, each with a plain-language description and a rough size (small: 30 to 60 minutes, medium: 1 to 2 hours, large: 2+ hours, split into pieces). 2. Read the user's calendar for the week to find free windows and existing commitments. 3. Draft a schedule of focus blocks: - Schedule deep work in the user's peak-energy windows when possible; ask when those are if unknown. - Keep blocks between 45 and 120 minutes, with short breaks between back-to-back blocks. - Leave at least one 30-minute unscheduled buffer per day for the unexpected. - Label each block with the priority it serves and the outcome expected by its end. 4. Present the proposed schedule for approval before creating any calendar events. 5. After approval, create the calendar events, marked private and set to decline new overlapping invites automatically when the calendar supports it. 6. On request, run a weekly reset: review which blocks survived, note what stole the others, and adjust next week's draft accordingly. ## Output Contract - A proposed schedule table with day, start time, duration, priority served, and expected outcome per block. - After approval, the created calendar events, confirmed with their titles and times. - A short summary: total focused hours planned, and which priorities still lack coverage. ## Operating Rules - Never create, move, or delete a calendar event without the user's explicit approval of the plan. - Never read or share calendar details beyond what this skill needs; report only titles and times of the relevant blocks. - If the calendar is fully booked, say so and propose the smallest meeting to reschedule, rather than stacking blocks on top of commitments. - When a block must be cut short, keep the expected outcome attached so the work can resume where it stopped. - Do not invent priorities; only schedule what the user named.

• Toast Writer

  Turns a few real anecdotes into a short, warm toast or celebration speech.

  Tested in MuseskillCreativeinstructionsworkflowexamples

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Toast Writer" skill. Its full source is below. Create it at ~/workspace/skills/toast-writer/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: toast-writer description: Turn a few real anecdotes into a short, personal toast or celebration speech, timed to your slot and tuned to your tone. Trigger phrases: "write my toast", "help with my wedding speech", "draft a best man speech". --- # Purpose Write a toast or short celebration speech that sounds like you, not like a greeting card. It takes the occasion, the people, your real anecdotes, and the tone you want, then drafts a speech that fits your time slot and lands the ending on a genuine wish. # Workflow 1. Ask for the occasion (wedding, birthday, retirement, holiday dinner), the speaker's role (best man, parent, friend, host), and who is being toasted. 2. Ask for 3 to 5 real anecdotes or facts about the person, in the user's own words. If they get stuck, offer simple prompts: how you met, a funny moment, a quality you admire. 3. Ask for the tone: warm, funny, sentimental, or a mix. Ask for any lines, jokes, or topics that are off limits. 4. Ask for the time slot (for example, two minutes, five minutes) and convert it to a target word count at about 130 words per minute of speaking. 5. Draft the speech in this shape: a short opener naming the occasion, two or three anecdote beats in the user's tone, then a closing toast line that raises the wish. Keep sentences short enough to say out loud. 6. Note the estimated speaking time next to the draft. 7. Offer up to two revision passes on tone, length, or a single anecdote, then stop and hand the draft back. # Output Contract - Draft speech in paragraph form, with the final toast line set apart. - Estimated speaking time, based on 130 words per minute. - Revision options: tone, length, or one anecdote, two passes max. # Operating Rules - Never invent anecdotes, facts, or backstories about real people. If the user provides nothing, ask again; do not fill the gap with fiction. - Never name or roast anyone the user flagged as off limits. - Never publish, send, or read the speech to anyone. The draft stays with the user. - Keep the draft within 15% of the target word count. - Prefer concrete detail from the user's own stories over greeting-card lines.

• Dependency Update Triage

  Turns a scary outdated-dependencies list into safe-now, review, and hold buckets.

  Tested in MuseskillDev & automationinstructionsworkflowreport

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Dependency Update Triage" skill. Its full source is below. Create it at ~/workspace/skills/dependency-update-triage/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: dependency-update-triage description: Classify outdated dependencies into safe-now, needs-review, and hold buckets from package manager output, with an upgrade order. Trigger phrases: "triage my dependency updates", "which dependencies are safe to update", "check outdated dependencies". --- # Purpose An outdated-dependencies list is a wall of version numbers that hides the two or three updates that actually matter. Dependency Update Triage reads that list, classifies each jump as patch, minor, or major, checks what is known about each one, and sorts everything into three buckets: safe now, needs review, and hold. The result is an upgrade plan with an order of operations, not a guessing game. # Workflow 1. Collect the outdated list. The user pastes the output of a command like `npm outdated`, `pip list --outdated`, `cargo outdated`, or `composer outdated`, or points the assistant at the project directory and has it run the read-only listing command there. 2. For each package, record the current version, the latest available version, and the jump type: patch, minor, or major. 3. For every major jump, look at the actual changelog or release notes. Record whether breaking changes are documented, whether a migration guide exists, and whether any linked issue is still open. 4. Check each package for deprecation notices, yanked versions, and published security advisories. Note the source of each finding. 5. Assign every package to exactly one bucket: - Safe now: patch or minor jumps with no advisories and no breaking indicators. - Needs review: major jumps, anything with an open security advisory, or a package whose changelog cannot be read. - Hold: deprecated packages, abandoned maintainers, or updates known to conflict with another dependency in the list. 6. Order the safe-now bucket from lowest risk to highest: patches first, then minors with the smallest version distance. 7. Write the report in the Output Contract shape and send it. # Output Contract One line per package, grouped by bucket in this order: Safe now, Needs review, Hold. Each line carries: - Package: name - Current to latest: "1.4.2 to 1.4.9" - Jump: patch, minor, or major - Note: one short reason for the bucket (for example, "major with migration guide" or "CVE-2026-1140 fixed in latest") End with a suggested order: apply Safe now first, lowest risk to highest, then tackle Needs review one at a time. Include the exact commands for each step so the user can approve and run them. # Operating Rules - Never run an install, upgrade, or migration command without the user approving that exact command first. - Never edit package.json, requirements files, Cargo.toml, lockfiles, or vendored code. Classification is read-only work. - Never invent changelog contents. If the changelog cannot be read, put the package in Needs review and say the changelog is unknown. - Treat a major jump with no readable changelog as Needs review, not Safe now. - If the project's test suite exists, recommend running it after each bucket before moving on, but do not run it without approval.

• 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

  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.

• Alt-Text Writer

  Writes accurate, concise alt text for any image, for accessibility and SEO.

  Tested in MuseskillMarketinginstructionsworkflowrules

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Alt-Text Writer" skill. Its full source is below. Create it at ~/workspace/skills/alt-text-writer/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: alt-text-writer description: Generate accurate, concise alt text for images, tuned for accessibility and SEO. This is not a caption writer: it describes the image for people who cannot see it. Trigger phrases: "write alt text for this", "alt text for this image", "describe this image for screen readers". --- # Purpose Alt-Text Writer turns an image into good alt text: a short, factual description of what the image shows, written for screen readers and search engines. Unlike a caption, which adds personality or a call to action, alt text replaces the image. It should tell a person who cannot see the image what matters in it, in plain words. # Workflow 1. Look at the image the user provides (a file, a URL, or a detailed description of what the image shows). 2. Ask what the image is for if it is not obvious: a product photo, a blog illustration, a chart, or a decorative banner. Decorative images get empty alt text, not a description. 3. Describe the essential content first: the subject, the action, and the setting. Add colors, text in the image, or data points only when they matter to understanding it. 4. Keep it under 125 characters when possible. If the image needs more (a chart, an infographic), write a short alt plus a longer text alternative the user can place next to the image. 5. Suggest a short SEO-friendly variant only when the user asks for one, with the page's focus keyword worked in naturally. # Output Contract Every result has three parts, in this order: - Alt text: the final alt attribute text, quoted and ready to paste. - Character count: the length, so the user can see it fits. - Long description (only for complex images): a fuller text alternative for charts, diagrams, or infographics. # Operating Rules - Describe only what is visible; never guess at names, places, or events that cannot be seen. - Never start with "image of" or "picture of"; screen readers already announce it is an image. - Never write alt text designed to mislead: no keyword stuffing, no claims the image does not support. - Mark decorative images with empty alt text and say why. - If the image is unclear or the request is ambiguous, ask before writing. - Keep each alt text to one sentence unless a longer alternative is genuinely needed.

• Contract Reader

  Turns dense contracts into plain-language summaries with key dates, fees, and red flags.

  Tested in MuseskillMoney & financeinstructionsworkflowreport-format

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Contract Reader" skill. Its full source is below. Create it at ~/workspace/skills/contract-reader/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: contract-reader description: Read a contract or terms of service and get a plain-language summary with key dates, fees, cancellation terms, and red flags. Trigger phrases: "read this contract", "summarize this agreement", "what does this contract say". --- # Purpose Contracts are written to be precise, not readable. Contract Reader takes any contract, agreement, or terms of service and turns it into a plain-language summary: what you are agreeing to, the dates and money that matter, and the clauses that deserve a second look before you sign. # Workflow 1. Accept the contract text or the key sections the user pastes in. Ask which sections matter most if the document is very long. 2. Extract the essentials: the parties, what each side must do, the term length, renewal and termination terms, payment amounts and schedules, fees and penalties, liability limits, and any auto-renewal or arbitration clauses. 3. Flag red flags in plain words: one-sided terms, broad liability waivers, vague deliverables, long lock-in periods, or fees that are easy to miss. 4. Present the summary with the most important facts first, then the flags, then the questions the user should ask before signing. 5. Remind the user this is an explanation, not legal advice, and to consult a lawyer for anything binding. # Output Contract Every summary has four parts, in this order: - Plain-language summary: what the agreement says in a few sentences. - Key terms table: dates, amounts, renewal, cancellation notice, and penalties. - Red flags: clauses that could cost the user money or flexibility, quoted and explained. - Questions to ask: the open items to raise with the other party before signing. # Operating Rules - Never provide legal advice or say the contract is safe to sign. - Never draft new legal terms or fill in signature blocks. - Use only what is in the document; never invent terms, dates, or amounts. - Quote the exact clause text before paraphrasing it. - Say plainly which sections could not be found or were unclear. - Keep the summary short enough to read in five minutes.

• Paint Color Record

  Keeps the exact brand, color, and finish for every wall, trim, and door in the house.

  Tested in MuseskillHomeinstructionsworkflowlog-format

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Paint Color Record" skill. Its full source is below. Create it at ~/workspace/skills/paint-color-record/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: paint-color-record description: Record and recall the exact paint brand, color, and finish for every wall, trim, and door in your home. Trigger phrases: "log this paint color", "what color is the guest room", "record my paint". --- # Purpose Remember every paint in the house so a touch-up, a patch, or a new gallon always matches. The record captures the exact brand, color name or code, finish (sheen), surface painted, and date, so you never have to guess or match by eye again. # Workflow 1. Collect a paint detail: the brand, color name, color code, finish, and where it was used (room, surface, number of coats). Accept it from the user, from a can label photo, or from a store receipt. 2. Store it as a record keyed by room and surface, with the date recorded and the purchase source if known. 3. When a new room is painted, add a new record. When a room is repainted, keep the old record with a repaint date and mark the new one as current. 4. On a recall request ("what color is X"), return the exact details for the current record only. 5. On a log request, confirm the parsed details with the user before saving. # Output Contract - A record line: room, surface, brand, color name, color code, finish, date recorded. - A recall answer: the current record for the asked room and surface, plus where it was bought if recorded. - No match: say so plainly, and ask for the can label or receipt. # Operating Rules - Never guess a color from a wall photo; wall photos shift color in light. Ask the user to read the can label or receipt when the code is not confirmed. - Never overwrite a prior record when a room is repainted; keep history with dates. - Keep records in plain text the user can read and export; no special software required. - Never invent a color code; if the code is unknown, record the color name and finish and mark the code as missing.

• Invoice Chaser

  Drafts polite, escalating payment reminders for overdue invoices.

  Tested in MuseskillMoney & financeinstructionsworkflowtemplates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Invoice Chaser" skill. Its full source is below. Create it at ~/workspace/skills/invoice-chaser/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: invoice-chaser description: Draft polite, escalating payment reminders for overdue invoices: gentle nudge, firm follow-up, and final notice. Trigger phrases: "chase my invoice", "draft a payment reminder", "follow up on overdue invoice". --- # Purpose Help freelancers and small businesses get paid on time without the awkwardness. Invoice Chaser takes an overdue invoice and drafts the right reminder for the moment: a friendly nudge early on, a firmer follow-up when silence stretches, and a final notice when patience runs out. # Workflow 1. Collect the facts: client name, invoice number, amount, original due date, days overdue, and any contact already attempted. 2. Choose the stage by days overdue and prior contact: - Stage 1 (1-14 days): gentle nudge, assumes an oversight. - Stage 2 (15-44 days): firm follow-up, asks for a payment date. - Stage 3 (45+ days): final notice, states consequences from the contract and a deadline for response. 3. Draft the reminder in the stage's tone, using only facts the user provided or confirmed. 4. Include a clear subject line, the invoice details, the amount due, and one specific ask (pay by a date, or reply with a date). 5. Save the client, invoice number, stage, and date to memory, so the next run escalates instead of repeating the same message. # Output Contract Each reminder has three parts, in this order: - Subject: one line, includes the invoice number and amount. - Body: short, professional, stage-appropriate tone. - Next step: what to do if this one gets no reply (for example, "escalate to Stage 2 after 7 days"). Never send. Present the draft and wait for the user's approval. # Operating Rules - Never send a reminder without the user's explicit approval. - Never invent an invoice number, amount, due date, or payment terms. Use only what the user provides. - Never mention late fees, interest, or penalties unless the user's contract includes them. - Never threaten legal action, collections, or public complaints. - Keep every message professional and brief. Frustration stays out of the draft. - If the client already paid or disputed the invoice, stop and say so instead of drafting.

• 1:1 Agenda Builder

  Turns scattered notes into a tight agenda for your next 1:1.

  Tested in Museprompt packProductivityprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "1:1 Agenda Builder" prompt pack. Its full source is below. Save it to ~/workspace/prompts/one-on-one-agenda-builder.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack turns scattered notes into a 1:1 meeting agenda. Paste it into Muse along with your notes. > Turn these notes into a 1:1 agenda for [person, role]. Sort > into: (1) updates I owe them, 2 minutes max, (2) things I > need from them, each as a clear ask, (3) topics to discuss: > with my position stated briefly, and (4) anything sensitive, > flagged so I handle it with care. Cut anything that doesn't > need a conversation, if it could be an email, say so and > drop it from the agenda. Keep the whole thing fittable in > 30 minutes, hardest items first.

• Bill Negotiation Script

  A call script to lower cable, internet, and insurance bills, with replies to pushback.

  Tested in Museprompt packMoney & financeprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Bill Negotiation Script" prompt pack. Its full source is below. Save it to ~/workspace/prompts/bill-negotiation-script.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack writes a call script for negotiating a lower bill. Paste it into Muse along with your bill details. > Write me a phone script for negotiating down my [cable / > internet / insurance] bill. Current bill: [amount], paying > for [plan details]. Include: (1) the opening line and the > exact ask, (2) responses to the five most common pushbacks > ("that's the best we can do", "let me transfer you", > retention offers that aren't really discounts), (3) what > competing offers to cite, look up current competitor pricing > for my area if you can, and (4) when to ask for a supervisor > and when to hang up and call back. Keep it firm but polite. > No bluffs I can't back up.

• Cold Outreach Drafter

  Prospecting emails built from real research on the lead, not templates.

  Tested in Museprompt packMarketingprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Cold Outreach Drafter" prompt pack. Its full source is below. Save it to ~/workspace/prompts/cold-outreach-drafter.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack drafts a cold outreach email from lead research. Paste it into Muse along with what you know about the lead. > Draft a cold outreach email to [name, role, company]. What I > know about them: [research notes]. Structure: subject line > under 8 words, one opening line that proves I researched them > (specific, not "I love what you're doing"), one sentence on > the problem I solve for companies like theirs, one proof > point (a result, not a claim), and one low-friction ask. > Rules: under 120 words total, no "I hope this finds you well", > no exclamation marks, no fake familiarity. If my research > notes are too thin to write a specific opener, say so and > tell me what's missing instead of faking it. Do not send; > draft only.

• Daily Brief

  Weekday mornings: your calendar, weather that matters, and top 3 tasks.

  Tested in MuseworkflowProductivityinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Daily Brief" workflow. Its full source is below. Default schedule: weekdays at 07: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: daily-brief description: Weekday morning brief, today's calendar, weather that affects your plans, and your top 3 tasks in one short message. Trigger phrases: "morning brief", "what's today look like", "daily briefing". schedule: weekdays at 07:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "morning brief" request. steps: 1. Pull today's calendar events with times and locations. 2. Check the weather for the user's location. Mention it only if it affects plans: rain during commute hours, extreme temps, anything that changes what to wear or whether to drive. 3. Pull the user's task list. Pick the top 3 by deadline and stated priority. If the list is empty, say so instead of inventing tasks. 4. Flag conflicts: overlapping events, or a task deadline colliding with a packed day. 5. Write the brief in the Output shape and send it. Keep it short enough to read in 30 seconds. output: - Today: events in order with times, one line each - Weather: only if it affects plans, one line - Top 3: the day's priorities, one line each - Heads up: conflicts or tight spots, one line each rules: - 30-second read. If it needs scrolling, it's too long. - Weather gets mentioned only when it changes a decision. - Tasks come from the user's list, not from inference. - Run only on the confirmed schedule or when asked.

• Git Commit Writer

  Your diff in, conventional-commit message out.

  Tested in Museprompt packDev & automationprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Git Commit Writer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/git-commit-writer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack writes a conventional commit message from your diff. Paste it into Muse along with the diff. > Write a conventional commit message for this diff. Format: > type(scope): short imperative summary, max 72 chars. Then a > body of 2-4 lines explaining what changed and why, not how, > the diff shows the how. Rules: (1) pick the right type > (feat, fix, docs, refactor, test, chore), (2) if the diff > mixes unrelated changes, say so and suggest splitting into > two commits instead of writing one message, (3) flag anything > that looks like a secret or credential in the diff before > anything else, (4) no filler words like "various" or > "updates". Do not commit; just write the message.

• Home Inventory

  Yearly photo inventory of valuables for insurance, room by room.

  Tested in MuseworkflowHomeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Home Inventory" workflow. Its full source is below. Default schedule: once a year, first Saturday of October at 10:00 local time. Ask me to confirm or change this 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: home-inventory description: Yearly home inventory for insurance, a room-by-room photo checklist of valuables, with values and serials recorded where it matters. Trigger phrases: "home inventory", "document my valuables", "insurance inventory". schedule: yearly, first Saturday of October at 10:00 local time. Confirm with the user before the first scheduled run. trigger: the scheduled time, or a manual "home inventory" request. steps: 1. Send the room-by-room checklist: living areas, bedrooms, kitchen, office, garage, storage. For each room: photograph everything, then log the items worth over $200 with brand, model, serial number, and approximate value. 2. Priority list first: electronics, jewelry, instruments, bikes, tools, collectibles, the things insurers ask about. 3. As the user reports items, organize them into the inventory table. Ask for what's missing (serials are the usual gap). 4. At the end: total estimated value, the completeness check (which rooms are done), and where to store the photos (cloud backup, not just the phone). 5. Save the inventory for next year's update run. output: - Inventory table: room, item, brand/model, serial, value - Total estimated value - Completeness: rooms done vs. remaining - Storage reminder: back the photos up off the phone rules: - The photos stay with the user. This workflow organizes the list; it stores nothing itself. - Values are the user's estimates. Never appraise. - Serials matter more than photos for claims. Say that. - Never contact the insurer. The user files their own claims. - Run only on the confirmed schedule or when asked.

• Moving Checklist

  8-week moving plan: what to do each week, from movers to address changes.

  Tested in MuseskillHomeinstructionsworkflowchecklist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Moving Checklist" skill. Its full source is below. Create it at ~/workspace/skills/moving-checklist/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: moving-checklist description: Build an 8-week moving plan, week-by-week tasks from booking movers to the last address change, sized to your home. Trigger phrases: "moving checklist", "plan my move", "we're moving in two months". --- # Purpose Moves go wrong in the last two weeks because the first six had no plan. This skill builds the 8-week plan up front: what to do each week, in order, sized to the home you're leaving. # Workflow 1. Ask the user for: move date, current home size, moving distance (local vs. long-distance), and whether they're hiring movers or DIY. 2. Build the 8-week plan: - Weeks 8-6: book movers or truck, declutter room by room, gather records (medical, school, vet) - Weeks 5-3: address changes (USPS, banks, subscriptions, voter registration), transfer utilities, pack non- essentials - Weeks 2-1: confirm movers, pack essentials, the "first night" box, defrost the freezer - Moving week: final walkthrough checklist, meter readings, keys and handoff 3. Size it: studio apartments skip the declutter month; long-distance moves get the records and car-shipping items earlier. 4. Report in the Output Contract shape. # Output Contract - 8-week plan: week by week, tasks in order, one line each - Book now: the 2-3 things to book this week (movers sell out) - First-night box: the packing list for night one in the new place # Operating Rules - The plan fits the move date given. If the date is under 8 weeks out, compress honestly, say what's cut. - "Book now" items are the time-sensitive ones. Everything else can slip a week. - Never book movers, change addresses, or contact anyone. The user executes. - One plan per move. Update it when the date changes.

• Net Worth Snapshot

  Monthly one-page net worth with the month-over-month change.

  Tested in MuseworkflowMoney & financeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Net Worth Snapshot" 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: net-worth-snapshot description: Monthly net worth snapshot, every account in one page, with the month-over-month change and what moved. Trigger phrases: "net worth snapshot", "what is my net worth", "monthly money summary". 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 "net worth snapshot" request. steps: 1. Pull balances from the user's connected accounts: checking, savings, investments, retirement, debts. 2. Compute total assets, total liabilities, net worth. 3. Compare against last month's snapshot. Note the change in dollars and percent, and which accounts moved the most. 4. One line per account: name, balance, change. Then the totals. 5. Write the snapshot in the Output shape and send it. Save it for next month's comparison. output: - Net worth: total, with month-over-month change - Assets: one line per account with balance and change - Liabilities: one line per account with balance and change - What moved: the 2-3 biggest movers, one line each rules: - Read only. Never move money or change anything. - Balances come from connected accounts, not estimates. If an account can't be read, list it as "unavailable" rather than guessing. - Keep the first snapshot as the baseline even if it's partial; note what's missing. - Run only on the confirmed schedule or when asked.

• Photo Caption Writer

  Photo in, caption options out, matched to the platform.

  Tested in Museprompt packCreativeprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Photo Caption Writer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/photo-caption-writer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack writes captions for a photo. Paste it into Muse along with the photo and where it's going. > Write 5 caption options for this photo, for [Instagram / > X / Facebook]. Mix the styles: one straightforward, one > funny, one minimal (under 6 words), one with a question to > drive replies, one storytelling (2-3 sentences). Rules: > match my voice, [describe it, or say "match the tone of my > last 3 posts"], no hashtags in the caption itself (list 5-8 > separately), no emojis unless I ask, and never invent details > about the photo that aren't visible, if you're unsure what > something is, keep it general.

• Playlist Builder

  Event plus vibe plus length: a sequenced playlist brief.

  Tested in Museprompt packCreativeprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Playlist Builder" prompt pack. Its full source is below. Save it to ~/workspace/prompts/playlist-builder.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack builds a sequenced playlist brief. Paste it into Muse along with the event details. > Build me a playlist brief for [event]: [vibe], about [length]. > Structure it in arcs: the opener (first 3 songs set the > tone), the build (energy rises), the peak (the 20 minutes > everyone remembers), and the landing (wind down or last-call > energy). For each song: title, artist, and one line on why > it's here. Rules: sequence for flow, no jarring genre jumps > between adjacent songs, keep it to songs I'd actually know > or that fit the crowd ([describe the crowd]), and end with > 3 swap-in alternates in case the mood shifts.

• README Writer

  Points at a repo, gets a real README draft: setup, usage, config.

  Tested in Museprompt packDev & automationprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "README Writer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/readme-writer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack drafts a README from a repository. Paste it into Muse along with the repo path or contents. > Write a README for this repo. Structure: (1) one-paragraph > what and why, (2) quickstart, the exact commands to go from > clone to running, (3) configuration, every env var and > config file with what it does, (4) usage, the main commands > or API with one example each, (5) development, how to run > tests and contribute. Rules: every command must come from > the repo itself (package.json, Makefile, docs), never > invent a command, (2) mark anything you couldn't verify with > [unverified], (3) keep it scannable, headers, code blocks, > no paragraphs over 4 lines. Do not commit; just draft it.

• Recall Checker

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

  Tested in MuseskillShoppinginstructionsworkflowreport-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.

• Restock Alert

  Watches out-of-stock items and pings you the moment they're back.

  Tested in MuseworkflowShoppinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

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

• Test Case Generator

  Paste a function, get the test cases including the edge cases you'd skip.

  Tested in Museprompt packDev & automationprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Test Case Generator" prompt pack. Its full source is below. Save it to ~/workspace/prompts/test-case-generator.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack generates test cases for a function. Paste it into Muse along with the function code. > Write test cases for this function in [framework]. Cover: > (1) the happy path with realistic inputs, (2) edge cases: > empty, null, zero, boundaries, and max sizes, (3) error > cases, invalid inputs and what the function should do with > each, and (4) one test for the bug most likely to hide here, > with a comment saying why it's likely. Rules: each test gets > a name that says what's being verified, no testing the > framework itself, and if the function is untestable as > written (hidden dependencies, no seams), say so and suggest > the smallest refactor that fixes it instead of writing > brittle tests.

• Testimonial Collector

  Quarterly: picks happy customers and drafts the ask.

  Tested in MuseworkflowMarketinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Testimonial Collector" workflow. Its full source is below. Default schedule: first Monday of each quarter 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: testimonial-collector description: Quarterly testimonial collection, picks the right customers to ask, drafts each ask personally, and tracks who replied. Trigger phrases: "collect testimonials", "ask for reviews", "testimonial drive". schedule: quarterly, first Monday of Jan/Apr/Jul/Oct at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "collect testimonials" request. steps: 1. First run: ask the user for the customer list with notes on who had a good outcome, and where testimonials should go (site, Google, etc.). 2. Each quarter: pick 3-5 customers with the best outcomes who haven't been asked in the last year. 3. Draft each ask personally: reference their specific result, suggest 2-3 prompts they can answer (not "write whatever"), and keep it short enough to say yes to. 4. Track: asked, replied, published. Carry non-responders one quarter, then rotate them out. 5. Write the report in the Output shape. The user sends the asks themselves. output: - This quarter's asks: customer, why them, the drafted ask - Waiting on: asked last quarter, not yet replied - Published: newly collected testimonials to post rules: - Drafts only. Never send anything to a customer. - Every ask references a specific result. No generic "would you review us" blasts. - Don't ask the same person twice in a year. - Run only on the confirmed schedule or when asked.

• Travel Day Brief

  Flight day: times, terminal, delays, and what to have ready.

  Tested in Museprompt packProductivityprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Travel Day Brief" prompt pack. Its full source is below. Save it to ~/workspace/prompts/travel-day-brief.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack builds a flight-day brief from your booking details. Paste it into Muse along with your flight info. > Build my travel-day brief for [flight number, date]. Include: > (1) the timeline working backward, when to leave home, when > to be at the airport, boarding time, (2) terminal and gate if > known, plus how I'm getting there and the backup plan, > (3) the current status, on time, delayed, or cancelled, with > what that means for connections, (4) what to have ready: > ID, boarding pass, and anything this specific trip needs > (international docs, checked-bag rules), and (5) the one > thing most likely to go wrong today and the fix. Times in > my local timezone.

• Auction Ending Alert

  Watches your saved auctions; pings before close with your max bid.

  Tested in MuseworkflowDeal huntinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Auction Ending Alert" workflow. Its full source is below. Default schedule: every 30 minutes. 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: auction-ending-alert description: Watch a list of auctions and alert before each one closes, with the current price, your max bid, and whether the deal still clears your bar. Trigger phrases: "watch these auctions", "alert me before my auctions end", "track my bids". schedule: every 30 minutes. Confirm the cadence with the user before the first scheduled run. trigger: the scheduled time, or a manual "watch these auctions" request with links. steps: 1. Ask the user for the auction links and a max bid for each. Save the watch list. 2. Each run: check the current price, bid count, and time remaining for every watched auction. 3. Alert rules: - Ending within 2 hours: send the pre-close alert. - Price already above the user's max: mark "over your max" and stop watching it unless told otherwise. - Auction ended: report the outcome (won/lost, final price) once, then drop it from the list. 4. The pre-close alert uses the Output shape. output: - Ending soon: item, time left, current price, your max bid - Deal check: current price vs. your max, one line - Over your max: listed separately, dropped from watch - Ended: outcome, one line each rules: - Read only. Never place a bid, never snipe, never contact the seller. - Max bids are the user's. Ask once per item, reuse until it ends. - One alert per auction per stage. No repeat pings. - Run only on the confirmed cadence or when asked.

• Birthday Radar

  Monthly: who's coming up, with enough lead time to get the gift.

  Tested in MuseworkflowProductivityinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Birthday Radar" 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: birthday-radar description: Monthly birthday and anniversary scan: who's coming up in the next 30 days, with gift lead time and past gift notes. Trigger phrases: "whose birthday is coming up", "upcoming birthdays", "birthday reminders". schedule: first of each month at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "whose birthday is coming up" request. steps: 1. Pull birthdays and anniversaries from the user's contacts for the next 30 days. 2. First run: ask the user which contacts matter (close circle vs. everyone) and save the preference. 3. For each upcoming date: name, date, days away, relationship note if the user has mentioned one. 4. Gift lead time: flag anything within 7 days as "order now", 8-14 days as "this week", the rest as "plenty of time". 5. If the user has mentioned past gifts, include the note so nothing gets repeated. 6. Write the report in the Output shape and send it. output: - Coming up: name, date, days away, lead-time flag - Gift lead time: flag anything within 7 days as "order now", 8-14 days as "this week", the rest as "plenty of time" - Quiet months: "Nobody on your list this month." rules: - Read only. Never message or post anything to anyone. - Dates come from the user's contacts, not from the web. Never look up someone's birthday online. - "Close circle" is the user's definition. Ask once, reuse. - Run only on the confirmed schedule or when asked.

• Competitor Watch

  Monthly: what competitors launched or posted, in one brief.

  Tested in MuseworkflowMarketinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Competitor Watch" workflow. Its full source is below. Default schedule: first Monday 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: competitor-watch description: Monthly competitor brief: what each named competitor launched, posted, or changed, and what it means for you. Trigger phrases: "watch my competitors", "competitor update", "what did competitors do this month". schedule: monthly, first Monday at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "competitor update" request. steps: 1. First run: ask the user for the competitor list (3-8 names) and what counts as signal (launches, pricing changes, big hires, notable posts). 2. Each run: check each competitor's public pages, blog/changelog, pricing page, social accounts, for the past 30 days. 3. For each item: what happened, when, and one line on why it matters to the user. 4. Close with "so what": the 2-3 moves worth a response, and the rest as noise. 5. Write the brief in the Output shape and send it. output: - Per competitor: what happened this month, one line each with dates - So what: the moves worth responding to, and the suggested response - Noise: everything else, one line total rules: - Public pages only. Never sign up for trials, newsletters, or demos as the user. - "Why it matters" is one line, not a strategy memo. - If a competitor did nothing notable, say so. Padding is noise. - Run only on the confirmed schedule or when asked.

• Contractor Bid Comparator

  Paste two or three quotes; get them normalized line by line.

  Tested in Museprompt packHomeprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Contractor Bid Comparator" prompt pack. Its full source is below. Save it to ~/workspace/prompts/contractor-bid-comparator.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack normalizes contractor quotes so you can compare them. Paste it into Muse along with the quotes. > Compare these contractor quotes line by line. Normalize them > into one table: labor, materials, permits, timeline, warranty, > payment schedule. Then tell me: (1) which bid is actually > cheapest once scope is equalized, (2) what each bid leaves > out that the others include: the gaps are where surprise > charges hide, (3) any red flags: no license number, full > payment upfront, vague materials ("quality shingles"), > timeline with no start date, and (4) three questions to ask > each contractor before deciding. Do not recommend a winner > outright: lay out the trade-offs and let me choose.

• Dupe Finder

  Name a product; get cheaper alternatives that don't suck.

  Tested in Museprompt packShoppingprompt-text

  by Muse Skills editors · Written for this directory

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

• Error Message Translator

  Paste a stack trace; get what it actually means and likely fixes.

  Tested in Museprompt packDev & automationprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Error Message Translator" prompt pack. Its full source is below. Save it to ~/workspace/prompts/error-message-translator.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack turns a cryptic error into a human explanation. Paste it into Muse along with the error text. > Translate this error message into plain English. Tell me: > (1) what the error actually means, in one sentence, (2) the > three most likely causes, ranked, with how to check each, > (3) the single most probable fix to try first, and (4) what > to search for if that fix doesn't work. Assume I know the > language but not this specific failure. Do not run anything; > reason from the message text.

• Estate Sale Scout

  Thursday-night scan of weekend estate sales, ranked by your categories.

  Tested in MuseskillDeal huntinginstructionsworkflowreport-format

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Estate Sale Scout" skill. Its full source is below. Create it at ~/workspace/skills/estate-sale-scout/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: estate-sale-scout description: Scan weekend estate-sale listings Thursday night and rank them by your collecting categories, so Friday morning you know where to go. Trigger phrases: "scout this weekend's estate sales", "any good estate sales coming up", "plan my Saturday sales route". --- # Purpose Estate sales reward the early and the informed. This skill reads the weekend's listings Thursday night and ranks them against what you actually collect, so you spend Saturday at the two sales worth your time instead of driving to six. # Workflow 1. Ask the user once for: home base (for drive time), search radius, and collecting categories in priority order (e.g. vinyl, cameras, tools, mid-century furniture). 2. On request (or Thursday evening if scheduled): pull the weekend's estate-sale listings from the main listing sites within the radius. 3. Score each sale: category matches in the listing photos or description (2 points per top-category match, 1 per lower), minus 1 point per 15 minutes of drive time over 30. 4. Report the top 5 in the Output Contract shape, with the rest as one-line honorable mentions. # Output Contract - Weekend shortlist: top 5 sales, ranked: address, day/hours, why it scored (which categories matched), drive time - Honorable mentions: one line each for the rest - Suggested route: the order to hit the top picks on Saturday morning - Slow weekends: "Nothing in your categories this week." # Operating Rules - Public listings only. Never contact organizers or RSVP. - Scores come from the listing text and photos, not from assumptions. If a listing is vague, say so instead of inflating it. - Drive time is an estimate. Name the source (maps); never present it as exact. - One scan per request or per scheduled Thursday run. No drip-feed alerts through the weekend.

• Launch Checklist

  Product launch promo plan: announcements, posts, emails, in order.

  Tested in MuseskillMarketinginstructionsworkflowchecklist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Launch Checklist" skill. Its full source is below. Create it at ~/workspace/skills/launch-checklist/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: launch-checklist description: Build an ordered launch promotion plan: announcements, posts, and emails sequenced across launch week, sized to a solo founder or small team. Trigger phrases: "plan my launch", "launch promotion checklist", "how do I announce this". --- # Purpose Launches fail quietly when the announcement plan is "post once and hope." This skill turns a launch into an ordered checklist across the week, sized for one person, not a marketing department. # Workflow 1. Ask the user for: what is launching, launch date, one sentence on who it is for, and where they already have an audience (newsletter size, social accounts, communities). 2. Build the plan in four phases: - T-7 to T-2 (tease): 2-3 short posts, one email teaser - T-1 (eve): checklist of logistics: links live, analytics on, support ready - Launch day: announcement post, email, community posts in order, with times - T+1 to T+7 (follow-through): thank-yous, first-user stories, one "how it works" post 3. Size everything to the user's actual audience. No "hire a PR firm" for a 200-subscriber newsletter. 4. Report in the Output Contract shape. # Output Contract - Launch week timeline: day by day, task by task, with the channel and the one-line point of each piece - Logistics checklist: links, analytics, support: the unglamorous half - Cut list: what a solo founder should skip, stated plainly # Operating Rules - One person can execute the whole plan in the week. If a task needs a team, it gets cut or simplified. - Every piece has a point in one line. No content for content's sake. - Never post or email anything. Drafts are the user's to approve. - The plan fits the audience they have, not the one they wish they had.

• New-Repo Setup Doctor

  Fresh-repo checklist that ends 'works on my machine' syndrome.

  Tested in MuseskillDev & automationinstructionsworkflowchecklist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "New-Repo Setup Doctor" skill. Its full source is below. Create it at ~/workspace/skills/new-repo-setup-doctor/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: new-repo-setup-doctor description: Diagnose a fresh repo checkout that won't build or run, environment, dependencies, and config checks in order, with the fix for each failure. Trigger phrases: "this repo won't build", "help me set up this repo", "diagnose my dev environment". --- # Purpose Fresh checkouts fail for boring reasons: wrong runtime version, missing env vars, a step the README forgot. This skill runs the checks in the order that finds the boring reason fastest. # Workflow 1. Ask the user for the repo path (or use the current directory) and what "working" means: builds, tests pass, dev server starts. 2. Run the checks in order, stopping at the first failure with its fix: - Runtime version vs. what the repo declares (.nvmrc, .python-version, go.mod, package.json engines) - Package manager and lockfile present; dependencies installed (node_modules, venv, etc.) - Required env vars / config files (.env.example vs .env) - External services the README mentions (database, redis) reachable or clearly mocked - Build / test / dev-server command from the README 3. For each failure: what failed, why it matters, the exact command or edit to fix it. Then re-run the check. 4. Report in the Output Contract shape. # Output Contract - Verdict: working, or the step it fails at - Checks: pass/fail per check, one line each - Fixes applied: what was changed, in order - Still broken: the failing step, the error, and the next thing to try # Operating Rules - Read-only diagnosis first. Propose every fix before running it; apply only what the user approves. - Never invent credentials. Missing secrets get a "create this" instruction, not a placeholder that gets committed. - Never commit, push, or force-install. The repo's history is the user's. - If the README's setup steps are wrong, say so and note the correction: that feedback is half the value.

• 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

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

• Seasonal Maintenance Reminders

  Furnace filter, gutters, hose bibs, before they break.

  Tested in MuseworkflowHomeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Seasonal Maintenance Reminders" workflow. Its full source is below. Default schedule: first of March, June, September, and December at 09:00 local time. Ask me to confirm or change this 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: seasonal-maintenance-reminders description: Quarterly home-maintenance reminders: the seasonal tasks people forget until something breaks, with the why behind each one. Trigger phrases: "home maintenance checklist", "what should I do around the house this season", "seasonal home tasks". schedule: quarterly, March 1, June 1, September 1, December 1 at 09:00 local time. Confirm with the user before the first scheduled run. trigger: the scheduled time, or a manual "home maintenance checklist" request. steps: 1. First run: ask the user for home type (house, condo, apartment) and heating type (furnace, boiler, heat pump) so the list fits. 2. Each quarter, send the season's checklist: - Spring: gutters, AC service, hose bibs on, dryer vent - Summer: deck check, pest sweep, fridge coils - Fall: furnace filter, heating service, hose bibs off and drained, gutters again, chimney if applicable - Winter: pipe insulation check, ice-dam watch, furnace filter 3. One line per task: what to do and the one-sentence why. 4. Mark the 2-3 "don't skip" items per season: the ones that cause expensive damage. output: - Season checklist: one line per task, what, and why - Done tracking: check off what the user reports done; carry the rest to next quarter rules: - Reminders only. Never schedule service or contact contractors. - The list fits the home type. Apartment renters don't get chimney items. - "Don't skip" is earned: only tasks where skipping causes real damage. - Run only on the confirmed schedule or when asked.

• SQL Explainer

  Paste a query; get a plain-English walkthrough of what it does.

  Tested in Museprompt packDev & automationprompt-text

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "SQL Explainer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/sql-explainer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack turns any SQL query into a plain-English walkthrough. Paste it into Muse along with your query. > Explain this SQL query in plain English. Walk through it > clause by clause in execution order (not written order): > what each part filters, joins, or computes, and what the > final result set looks like. Then give: (1) a one-sentence > summary of what the query answers, (2) any performance > red flags you see: full table scans, unindexed joins, > SELECT *, N+1 patterns, and (3) one suggested rewrite if > a red flag is serious. Assume I know basic SQL. Do not > run the query; explain it from the text.

• Tax Doc Gatherer

  February checklist of expected tax documents; tracks what arrived.

  Tested in MuseworkflowMoney & financeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Tax Doc Gatherer" workflow. Its full source is below. Default schedule: every Monday in February 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: tax-doc-gatherer description: February tax-season checklist: builds the list of expected documents from your income sources, watches the inbox, and reports what arrived and what is still missing. Trigger phrases: "gather my tax docs", "what tax documents am I missing", "tax season checklist". schedule: every Monday in February at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "gather my tax docs" request. steps: 1. First run: ask the user for income sources (employer, freelance clients, banks, brokerages, crypto, rental, retirement accounts). Save the list for the season. 2. Map each source to expected documents: W-2, 1099-NEC, 1099-INT, 1099-DIV, 1099-B, 1098, K-1, etc. 3. Search the inbox for tax documents from the past 60 days: "tax document", "1099", "W-2", "available for download". 4. Mark each expected doc as arrived or missing. For missing ones, note the issuer's typical send date if known. 5. Write the report in the Output shape and send it. Save the checklist state so next week's run shows progress. output: - Arrived: one line each, with where it was found - Still missing: one line each, with issuer and typical timing - Ready to file: yes or no rules: - Read only. Never download documents to shared storage, never send anything to a preparer or service. - The income-source list is the user's. Ask once, reuse all season. - Never guess a missing document's contents. The checklist is about arrival, not numbers. - Run only on the confirmed schedule or when asked.

• Warranty Tracker

  Logs purchase dates and warranty windows; pings before they expire.

  Tested in MuseworkflowMoney & financeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

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

• API Debugger

  Paste the request and the error; get an ordered diagnosis checklist.

  Tested in MuseskillDev & automationinstructionsworkflowdiagnosis-checklist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "API Debugger" skill. Its full source is below. Create it at ~/workspace/skills/api-debugger/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: api-debugger description: Diagnose a failing API call from the request and the error: an ordered checklist from most to least likely cause. Trigger phrases: "debug this API call", "why is this request failing", "diagnose this error". --- # Purpose Turn "it returns a 400 and I don't know why" into an ordered list of things to check, most likely first, instead of random guessing. # Workflow 1. Read what the user pastes: the request (method, URL, headers with secrets redacted, body) and the full error (status code, response body, and any SDK or client error text). 2. Classify the failure: auth (401/403), client error (400/404/ 422), server error (5xx), network/timeout, or SDK misuse. 3. Build the checklist ordered by likelihood for that class: - Auth: expired token, wrong scope, key in the wrong header, clock skew. - Client error: malformed body field, wrong content type, missing required param, URL encoding issue. - Server error: retry with backoff, check the provider status page, isolate with a minimal request. - Network: DNS, proxy, TLS version, firewall. 4. For each item, give the one concrete check to run ("decode the JWT at jwt.io and read the exp claim" beats "check your token"). 5. Report in the Output Contract shape. # Output Contract - Classification: one line (auth / client / server / network / SDK misuse) - Checklist: ordered items, each with the concrete check to run - Fastest test: the single quickest check that would confirm or rule out the top hypothesis # Operating Rules - Never ask for a real API key, token, or credential. If the user pastes one, tell them to revoke it and redact before continuing. - Never send any request on the user's behalf. Diagnosis only. - Order by likelihood, not by category textbook order. The most probable cause goes first. - If the error text is too thin to classify, say which two pieces of information would unblock the diagnosis.

• Appointment Prep

  Who you're seeing and why: the context worth re-reading first.

  Tested in Museprompt packProductivityinstructionsprep-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Appointment Prep" prompt pack. Its full source is below. Save it at ~/workspace/prompts/appointment-prep.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: "prepare for an appointment", "brief me for my appointment", "what should I ask at my appointment". --- SOURCE --- # Appointment Prep How to use: name the appointment (person, doctor, contractor, interview: anything). It pulls the relevant history and hands you a one-page brief: what this is about, what happened last time, and what to ask or bring. Trigger phrases: "prepare for an appointment", "brief me for my appointment", "what should I ask at my appointment". Save it as a reusable prompt pack named "Appointment Prep". ## The prompt Prep me for this appointment. I will tell you who it is with and what it is about. 1. Find the calendar event and any related emails, notes, or threads about this person or topic. 2. Summarize: what this appointment is for, in 2-3 sentences. 3. Recap what happened last time (if there was a last time): what was decided, what was left open. 4. List what to bring or prepare: documents, questions, numbers to have on hand. 5. Suggest 3 questions worth asking, specific to this appointment, not generic small talk. Rules: use only what the sources contain; do not invent history. If there is no prior history, say so and build the brief from the appointment details alone. Keep it to one page.

• Bill Due Radar

  Weekly inbox scan; one list of every bill due in the next 14 days.

  Tested in MuseworkflowMoney & financeinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Bill Due Radar" workflow. Its full source is below. Default schedule: Sunday at 18: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: bill-due-radar description: Weekly scan of the inbox for bills and statements; one list of what is due in the next 14 days, with amounts and due dates. Trigger phrases: "what bills are due", "check upcoming bills", "run bill radar". schedule: weekly, Sunday at 18:00 local time (cron: 0 18 * * 0). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "what bills are due" request. steps: 1. Search the inbox for billing statements, payment reminders, and autopay notices from the last 30 days, through the assistant's own connected accounts. 2. For each biller, take the most recent statement: amount due and due date. 3. Keep only bills due within the next 14 days. Drop anything already marked paid or covered by an autopay confirmation. 4. Sort by due date, soonest first. 5. Write the report in the Output shape and send it. If nothing is due, send the all-clear line and nothing else. output: - One line per bill: biller, amount, due date, autopay status (yes / no / unknown) - Total due across the list - All-clear line when nothing is due: "Nothing due in the next 14 days." rules: - Read only. Never pay a bill, open a payment page, or move money. - Never ask the user for banking logins or payment credentials. - If a statement is ambiguous about the amount or date, mark it "check manually" rather than guess. - Run only on the confirmed schedule or when asked.

• Bulk Lot Evaluator

  Point it at a lot listing; get a max bid and a walk-away price.

  Tested in MuseskillDeal huntinginstructionsworkflowvaluation-method

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Bulk Lot Evaluator" skill. Its full source is below. Create it at ~/workspace/skills/bulk-lot-evaluator/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: bulk-lot-evaluator description: Evaluate a bulk lot listing (records, games, cameras, tools) from its photos and description: per-item value estimate, a max bid, and a walk-away price. Trigger phrases: "evaluate this lot", "what's this lot worth", "should I buy this lot". --- # Purpose Decide fast whether a bulk lot is worth buying, and at what price. Built for listings where the seller doesn't know what they have: one photo, a vague description, a single asking price. # Workflow 1. Read the listing: photos, description, asking price, location. 2. Identify every item you can see or reasonably infer. Group them: clearly visible, partially visible, described-but-unseen. 3. For each clearly visible item of value, estimate a conservative resale value from recent sold comps (lowest of matches, never the average). 4. For partially visible or unseen items, assign $0 in the base case and note the upside only as speculation. 5. Add the conservative values. Apply the lot discount: multiply by 0.6 (you will not sell everything, and condition is uncertain). 6. Set the max bid at 50% of the discounted total. If the asking price exceeds the max bid, the call is "negotiate to $X" when the gap is small and "walk away" when it is not. 7. Report in the Output Contract shape. # Output Contract - Lot: listing title and link - Ask: dollar amount - Visible value: itemized conservative values, one line each - Discounted total: the 0.6-adjusted sum - Max bid: dollar amount - Walk-away: "buy" / "negotiate to $X" / "walk away", with one line of reasoning - Speculative upside: items that could add value but were not counted # Operating Rules - Never count value for items you cannot see or verify. Unseen = $0 in the base case. - Never use asking prices as comps; sold data only, low end of the range. - If the photos are too poor to identify anything of value, say so and stop. - Report only. Never contact the seller, bid, or negotiate on the user's behalf.

• Changelog Compiler

  Weekly: commits in, release-notes draft out.

  Tested in MuseworkflowDev & automationinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Changelog Compiler" workflow. Its full source is below. Default schedule: Friday at 17: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 which repos to include. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- name: changelog-compiler description: Weekly digest of git history turned into a release-notes draft, grouped for humans. Trigger phrases: "compile the changelog", "what shipped this week", "draft the release notes". schedule: weekly, Friday at 17:00 local time (cron: 0 17 * * 5). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "compile the changelog" request. repo_list: the repos to include, set once with the user and remembered. steps: 1. Read the commit history since the last run for each repo in the list. 2. Drop noise: merge commits, version bumps, typo-only commits, and CI config churn, unless the user asks otherwise. 3. Group the rest for humans: Added, Changed, Fixed. One bullet per change, written as an outcome ("Checkout retries failed payments automatically"), never as a commit message. 4. Flag anything that looks breaking: migration, removed endpoint, changed default, renamed config. Put these first under a "Heads up" section. 5. Write the draft in the Output shape and send it. If nothing shippable landed, say so in one line. output: - Heads up (breaking or migration-worthy changes, if any) - Added / Changed / Fixed sections, one outcome-bullet each - Quiet weeks: "Nothing shippable this week." rules: - Never invent a change. Every bullet must trace to a real commit. - Outcomes, not commit messages. Rewrite ruthlessly. - Never commit, tag, or publish the changelog. Draft only. - Run only on the confirmed schedule or when asked.

• Chief of Staff Briefing

  A morning brief with today's priorities, meeting prep, and inbox items to answer.

  Tested in Museprompt packProductivityinstructionsgoal-state-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Chief of Staff Briefing" prompt pack. Its full source is below. Save it at ~/workspace/prompts/chief-of-staff-briefing.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: "prepare my morning briefing", "brief me on today", "run chief of staff briefing". --- SOURCE --- # Chief of Staff Briefing How to use: run this each morning, or on a schedule you set. Keep a goal file up to date; the prompt reads it each run and does not change it. ## Goal state file Maintain a short file, for example `goals.md`, with one active goal per line: ``` - [Goal name]: [current status in one line] - [Goal name]: [current status in one line] ``` Update it yourself as goals change. The briefing reads this file; it never edits it. Trigger phrases: "prepare my morning briefing", "brief me on today", "run chief of staff briefing". ## The prompt You are my chief of staff for this morning's brief. Read my calendar for today, my inbox for unread and flagged messages from the last 24 hours, and my goal file at ~/workspace/goals.md. Use only what these three sources contain. Do not invent a meeting, an email, or a goal that is not in them. Build the brief in this exact order: 1. **Today's three priorities.** Pick the three items that matter most today, drawn from calendar commitments, time-sensitive inbox items, and open goals. State each as one line: what it is and why it made the cut. 2. **Meetings with prep notes.** List today's meetings in time order. For each: time, title, attendees, and one prep note (the open question, the decision needed, or the document to bring). If a meeting needs no prep, say so in one line rather than inventing a note. 3. **Inbox items needing a reply.** List unread or flagged messages from the last 24 hours that need a response from me, oldest first. For each: sender, subject, and what the reply needs to resolve. Skip anything already answered or informational-only. 4. **One goal nudge.** Pick exactly one goal from the goal file and name one concrete next action for it today. Pick the goal that has gone longest without a status change, or the one closest to a deadline if any goal states one. Keep the whole brief scannable: short lines, no restating the question, no summary at the end. If a section has nothing to report (no meetings today, no inbox items needing reply), say so in one line instead of skipping the heading silently. Never draft or send a reply, never create or edit a calendar event, and never edit the goal file. This is a read-and-report task only. If ~/workspace/goals.md does not exist, ask the user where their goals file lives before the first run.

• Code Reviewer

  Reviews a diff against its surrounding code and ranks bugs before style.

  Tested in MuseskillDev & automationinstructionsworkflow

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Code Reviewer" skill. Its full source is below. Create it at ~/workspace/skills/code-reviewer/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: code-reviewer description: Repo-aware code review of a diff. Reads the changed lines and the surrounding file, then reports correctness bugs first, security issues second, and a minimal fix for each. Trigger phrases: "review this diff", "review my changes", "code review this", "check this PR for bugs". --- # Purpose Review a code change with the context of the repo around it, not the diff alone. Rank findings by what breaks the program first, then by what an attacker could exploit. # Workflow 1. Read the diff. List every file and line range it changes. 2. For each changed file, read the full file, not only the changed lines. Read a function the diff calls or that calls the diff, when the file does not show enough context. 3. Check each changed line for a correctness bug: wrong logic, an off-by-one, a null or undefined path the code does not handle, a type mismatch, a race condition, a resource the code does not release. 4. Check each changed line for a security issue: unvalidated input, a secret in source, an injection path, a missing authorization check, a dependency with a known vulnerability. 5. For each finding, write the smallest diff that fixes it. Do not redesign the function around the fix. 6. Order the findings: all correctness bugs first, ranked by how badly the program breaks; then all security issues, ranked by how easily an attacker reaches them. 7. Do not edit the repo. Return the findings and the proposed patches as text. # Output Contract A numbered list. Each entry has: - `file:line` of the finding. - The failure scenario: the input or sequence that triggers the bug, in one or two sentences. - The proposed fix, as a unified diff hunk (`---`/`+++`/`@@`) scoped to the smallest change that resolves it. Correctness findings appear before security findings. Within each group, order by severity, most severe first. If the diff has no findings, say so in one line and stop. # Operating Rules - Never write, edit, or stage a file. Every fix ships as a proposed patch, never applied. - Never run a linter, test suite, or build step that writes to the repo or a remote. - Never invent a finding the code does not support. Cite the exact line for each one. - Never ask the user for a credential, API key, or token. - Never contact a third-party service (a dependency database, a CVE feed) unless the user has already connected one and asks for it by name. - Style, naming, and formatting issues are out of scope. Report them only if asked, and keep them in a separate section after the ranked list.

• Content Calendar

  Topic and cadence in; a four-week calendar of post ideas out.

  Tested in MuseworkflowMarketinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Content Calendar" workflow. Its full source is below. Default schedule: first Monday 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: content-calendar description: Monthly content calendar: four weeks of post ideas for your topic and cadence, with hooks written. Trigger phrases: "plan next month's content", "content calendar for", "what should I post". schedule: monthly, first Monday at 09:00 local time. Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "plan next month's content" request. inputs: topic, platforms, posts per week per platform, any themes or launches coming up. steps: 1. Confirm the inputs with the user the first time: topic, platforms, cadence. Remember them. 2. Build four weeks of ideas. Mix the formats: teach (how-to), show (behind the scenes), prove (results or testimonials), ask (questions and polls). 3. Every idea gets: the working title, the hook (first line), the format, and the platform. 4. Tie at least two ideas per month to something timely: a launch, a season, a trend in the topic. 5. Write the calendar in the Output shape and send it. output: - Week-by-week calendar: day, platform, working title, hook, format - Format mix summary (counts of teach / show / prove / ask) - Two "banked" backup ideas for weeks when nothing gets written rules: - Ideas, not finished posts. Hooks written, bodies left to the user. - Never invent launches, numbers, or testimonials. Mark placeholders clearly. - No posting, scheduling, or publishing. Planning only. - Run only on the confirmed schedule or when asked.

• Coupon Stacker

  Before checkout, finds stackable codes and the best combo.

  Tested in MuseskillShoppinginstructionsworkflowcode-testing

  by Muse Skills editors · Written for this directory

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

• Deal Hunter

  Watches new private-seller listings and flags the mispriced ones.

  Tested in MuseskillDeal huntinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Deal Hunter" skill. Its full source is below. Create it at ~/workspace/skills/deal-hunter/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: deal-hunter description: Scan marketplace listings for brand-new, private-seller items priced well below conservative resale value. Trigger phrases: "run deal hunter", "check for underpriced listings", "scan marketplace for deals". --- # Purpose Find listings that are mispriced by a wide margin, not merely cheap. A candidate meets three conditions at the same time: the listing is new since the last run, the seller is a private party, and the ask sits well under a conservative resale value. # Workflow 1. Read the watch config: category or keyword list, target marketplaces, and area or radius. The user sets these once, and Deal Hunter reuses them until the user changes them. 2. Pull listings posted since the last successful run. Discard any listing already seen in a prior run. 3. Discard any listing from a dealer, a store account, or a seller with a storefront profile. Keep private-party listings only. 4. For each remaining listing, estimate a conservative sold value. Use recent sold or completed listings for the same item and condition, and take the lower end of that range, not the average. 5. Compute the ask as a percentage of the conservative sold value, and the upside in dollars: conservative sold value minus the ask. 6. Keep a listing only if the ask is at most 50% of the conservative sold value AND the upside is at least $40. 7. Sort the surviving candidates by upside, highest first. 8. If no candidate survives, end the run. Send nothing. 9. If at least one candidate survives, write the report in the Output Contract shape and send it. 10. Record the run timestamp and the listing IDs seen, so the next run only looks at what is new. # Output Contract A short list, one line per candidate, in this order: - Listing: title and link - Ask: dollar amount - Conservative comp: dollar amount and how it was set (for example, "lowest of 3 sold comps") - Upside: dollar amount No candidates: no message at all. This is a quiet job by design. # Operating Rules - Never message, offer on, or contact a seller. Report only. - Never place a bid, a hold, or a purchase. - Never ask the user for a marketplace login, cookie, or API key. Use the assistant's own connected browsing session. - Never treat an average or asking-price comp as the conservative value; use the low end of actual sold data. - If sold data is too thin to set a confident comp, skip the listing rather than guess. - Run only on the schedule the user confirms; do not run ad hoc without being asked.

• Decision Log

  Log decisions with context; query them instead of re-litigating.

  Tested in MuseskillProductivityinstructionsworkflowdecision-file

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Decision Log" skill. Its full source is below. Create it at ~/workspace/skills/decision-log/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: decision-log description: Keep a running log of decisions: what was decided, why, by whom, and when to revisit. Query it instead of re-litigating. Trigger phrases: "log this decision", "record a decision", "what did we decide about". --- # Purpose End the "wait, why did we do it this way?" loop. Every decision gets one entry: the call, the reasoning, who made it, and when it should be revisited. Six months later, the answer is in the file. # Workflow 1. When the user reports a decision, capture: date, the decision in one sentence, the context and reasoning (2-3 sentences), who decided, and any alternatives considered and rejected. 2. Ask for a revisit date when one makes sense ("revisit after the holiday traffic spike"); otherwise mark "no revisit set". 3. Append the entry to decisions.md in the workspace, newest at the bottom, with a simple header per entry. 4. On query ("what did we decide about X"), search the log and quote the entry, decision, reasoning, date, decider, then stop. Do not re-argue the decision. 5. On request ("what needs revisiting"), list entries whose revisit date has passed. # Output Contract - decisions.md: one entry per decision with date, decision, reasoning, decider, alternatives, revisit date - Query answers: the quoted entry plus its date, nothing more - Revisit lists: entries past their revisit date, oldest first # Operating Rules - Record what was decided, not what should have been decided. No editorializing. - Never invent reasoning the user didn't give. Ask for the "why" if it's missing, one question, then log it. - The log is append-only. Corrections go in as new entries referencing the old one; never rewrite history. - The file stays in the user's workspace. Nothing is sent anywhere.

• eBay Comp Checker

  Paste any item description; get a conservative resale value from real sold comps.

  Tested in Museprompt packDeal huntinginstructionscomp-methodconfidence-rating

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "eBay Comp Checker" prompt pack. Its full source is below. Save it at ~/workspace/prompts/ebay-comp-checker.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: "comp this item", "find eBay comps", "price this eBay item". --- SOURCE --- # eBay Comp Checker How to use: paste an item description with as much detail as you have: brand, model, size or variant, condition, and anything that affects value (edition, year, completeness). Ask for "comp this" any time you are staring at a listing and wondering if the price is real. Trigger phrases: "comp this item", "find eBay comps", "price this eBay item". ## The prompt You are pricing a used item from eBay sold data. Work in this order: 1. Search eBay's sold and completed listings for the closest matches: same brand and model, same size or variant, comparable condition. 2. Collect the 5 most recent matching sold prices. Ignore active listings, asking prices, and outliers more than 2x the median. 3. Set the conservative comp to the LOWEST of the matched sold prices, not the average, not the median. 4. Report in this shape: - Item: what you matched on - Sold comps: the matched prices, newest first, with dates - Conservative comp: $X (lowest of N matches) - Confidence: high / medium / low, with one line on why 5. If fewer than 3 solid matches exist, say so plainly and mark confidence low. Never pad thin data with guesses. 6. Never invent a sold listing. If you cannot find real sold data, say that instead of estimating. Rules: report only. Never contact a seller, place a bid, or suggest a listing strategy beyond the comp itself.

• Expense Receipt Wrangler

  Photo a receipt; it logs merchant, date, total, and category.

  Tested in MuseskillMoney & financeinstructionsworkflowexpense-log

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Expense Receipt Wrangler" skill. Its full source is below. Create it at ~/workspace/skills/expense-receipt-wrangler/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: expense-receipt-wrangler description: Turn receipt photos into a running expense log: merchant, date, total, and category appended to one CSV. Trigger phrases: "log this receipt", "add this expense", "track this receipt". --- # Purpose Keep a running expense log with zero bookkeeping effort. The user photos a receipt; the skill extracts the fields and appends one row. # Workflow 1. Read the receipt photo. Extract: merchant name, transaction date, total amount, and payment method if shown. 2. Assign a category from the user's category list. Ask the user to set the list once; until then use: groceries, dining, transport, home, health, entertainment, other. 3. If any field is unreadable, ask the user for that field only. Never guess an amount. 4. Append one row to expenses.csv in the workspace: date, merchant, category, total, payment method, photo file name. 5. Confirm back in one line: merchant, total, category. 6. On request ("summarize my spending"), total by category for a date range the user names. # Output Contract - expenses.csv: date,merchant,category,total,payment_method,photo - Confirmations: one line per receipt - Summaries: category totals for the requested range, plain text # Operating Rules - Never guess a total or a date. Ask when the photo is unclear. - Never move, rename, or delete the receipt photo. - The log lives in the user's workspace only. Nothing is sent anywhere. - Never ask for banking logins or card numbers; the photo is the only input.

• Facebook Ad Copy Drafter

  Product and audience in; three ad variants with different hooks out.

  Tested in Museprompt packMarketinginstructionsad-templates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Facebook Ad Copy Drafter" prompt pack. Its full source is below. Save it at ~/workspace/prompts/facebook-ad-copy-drafter.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: "write Facebook ad copy", "draft ad variants", "create ad copy". --- SOURCE --- # Facebook Ad Copy Drafter How to use: describe the product and the audience. It returns three ad variants with different hooks, each with primary text, headline, and description, ready to paste into Ads Manager. Trigger phrases: "write Facebook ad copy", "draft ad variants", "create ad copy". Save it as a reusable prompt pack named "Facebook Ad Copy Drafter". ## The prompt Draft Facebook ad copy. I will give you: the product (what it is, price, key benefit), the audience (who they are, what they care about), and the goal (clicks, signups, purchases). 1. Write three variants, each with a different hook: - Variant A: the direct benefit ("what you get"). - Variant B: the pain point ("what's broken now"). - Variant C: social proof or specificity (a number, a testimonial shape, a concrete detail). 2. Each variant gets: primary text (under 125 characters so it doesn't truncate), headline (under 40 characters), and description (one line). 3. Match the tone to the audience, plain language for most, jargon only if the audience actually uses it. 4. End with one line per variant: who this hook is for and when to use it. Rules: no false urgency ("only 3 left!") unless it is true. No claims you can't back up. Never create or launch a campaign: drafts only.

• Fit Finder

  Your measurements plus a brand: estimated size and watch-outs.

  Tested in Museprompt packShoppinginstructionssize-template

  by Muse Skills editors · Written for this directory

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

• Follow-up Radar

  Finds your unanswered promises and flags the ones that went quiet.

  Tested in MuseworkflowProductivityinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Follow-up Radar" workflow. Its full source is below. Create it at ~/workspace/skills/follow-up-radar/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, propose the default schedule (Monday at 08:00 local time) and wait for me to confirm or change it before you create any recurring job. --- SOURCE --- name: follow-up-radar description: Weekly scan of sent mail for "I'll get back to you" promises; flags the ones with no reply after 7 days. Trigger phrases: "any follow-ups due", "check my promises", "run follow-up radar". schedule: weekly, Monday at 08:00 local time (cron: 0 8 * * 1). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "any follow-ups due" request. steps: 1. Search sent mail from the last 30 days for follow-up promises: phrases like "I'll get back to you", "I'll send that over", "let me check and revert", "I'll circle back", "I'll follow up". 2. For each promise, check the thread for a fulfilling reply from the user, or any reply activity in the last 7 days. 3. Keep only promises with no fulfilling reply and no thread activity in 7 days. 4. Sort oldest first. Write the report in the Output shape and send it. If nothing is overdue, send nothing at all. output: - One line per overdue promise: thread subject and person, the promise quoted, days quiet, and a suggested next step - Quiet weeks: no message rules: - Read only. Never send a follow-up email on the user's behalf. - Quote the promise; do not paraphrase it into something stronger than what was written. - A thread with any reply in the last 7 days is not overdue, even without a fulfilling reply. - Run only on the confirmed schedule or when asked.

• Garage Sale Route Planner

  Friday-night sweep of yard and estate sales, mapped into a Saturday route.

  Tested in MuseworkflowDeal huntinginstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Garage Sale Route Planner" workflow. Its full source is below. Create it at ~/workspace/skills/garage-sale-route-planner/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, propose the default schedule (Friday at 19:00 local time) and wait for me to confirm or change it before you create any recurring job. --- SOURCE --- name: garage-sale-route-planner description: Friday-evening sweep of yard sales, garage sales, and estate sales near the user, scored against an interest list and mapped into a Saturday morning route. Trigger phrases: "plan my Saturday route", "find weekend sales", "plan my garage sale route". schedule: weekly, Friday at 19:00 local time (cron: 0 19 * * 5). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "plan my Saturday route" request. route_config: area, radius in miles (default 20), and interest keywords (for example: vinyl records, film cameras, tools, mid-century furniture). The user sets these once; the workflow reuses them until changed. steps: On first run, ask the user for area, radius, and interest keywords, and store them for later runs. 1. Sweep local listings for Saturday sales: Craigslist garage/yard sale section, Facebook Marketplace local sale posts, and estate-sale aggregators covering the user's area. 2. Keep sales within the radius happening Saturday morning. Drop sales with no address or no start time. 3. Score each sale on interest-keyword hits in its listing text. Sales mentioning a keyword rank above general sales. 4. Order the kept sales into a route: earliest start time first, then nearest to the previous stop. Estimate total driving miles. 5. Write the route in the Output shape and send it Friday night. If nothing scores above a general sale, say so in one line instead of sending a thin route. output: - One numbered stop per sale: start time, sale type, address, and the keyword hit that earned its place - Total driving distance for the route - One line on anything worth skipping rules: - Report only. Never contact a seller or RSVP to anything. - Never use asking prices or sale hype as a signal; keywords and proximity only. - Run only on the confirmed schedule or when asked.

• Gift Finder

  Asks five questions about the recipient, then returns five gift ideas with links.

  Tested in MuseskillShoppinginstructionsinterview

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall 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 packShoppinginstructionslist-template

  by Muse Skills editors · Written for this directory

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

• Inbox Triage

  Sorts new email into reply, delegate, archive, or later, then drafts your replies.

  Tested in MuseworkflowProductivityscheduleworkflowdraft repliesapproval step

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Inbox Triage" workflow. Its full source is below. Create it at ~/workspace/skills/inbox-triage/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, propose the default schedule (weekdays at 07:30 local time) and wait for me to confirm or change it before you create any recurring job. --- SOURCE --- name: inbox-triage description: Scheduled email triage. Classifies new mail into reply, delegate, archive, or later, drafts replies for the reply set, and holds every draft for approval before send. Trigger phrases: triage my inbox, sort my email, draft my replies. schedule: weekdays at 07:30 local time (cron: 30 7 * * 1-5). Confirm the time with the user before the first scheduled run. A user change to the time takes effect on the next run. trigger: the scheduled time, or a manual "run inbox triage now" request. steps: 1. Read all mail that arrived since the last successful run, using the user's own connected email account. Never sign in with credentials the user has not already connected. 2. Classify each message into exactly one bucket: - reply: needs a response from the user. - delegate: needs action from someone else the user has already named as a delegate. - archive: no action needed (receipts, notifications, newsletters with no ask). - later: needs the user's attention but not a reply today (long threads, decisions that need more context). 3. For every message in the reply bucket, draft a reply in the user's own voice, using the thread history for context. Keep each draft under 150 words unless the source message needs a longer answer. 4. For every message in the delegate bucket, draft a one-line forward note to the named delegate. Never send it without approval. 5. Present the full batch: bucket counts, then each reply and delegate draft in full, with the original message it answers. 6. Wait for the user's decision on each draft: approve, edit, or discard. Send only the drafts marked approved, exactly as approved or as edited by the user. 7. Apply the archive and later labels only after the user has seen the batch summary. Never archive a message the user has not at least seen listed. output: a batch report per run: counts by bucket, then the full text of every reply and delegate draft awaiting approval. If no new mail arrived, or every new message fell into archive or later, the report says so in one line and includes no drafts. stop_conditions: - Stop and ask the user if a message looks like it needs a password, payment, or legal commitment. Never draft a reply that commits money or signs an agreement. - Stop the whole run and report the error if the mail account disconnects mid-run. - Never retry a send. A failed send is reported, not resent automatically. operating_rules: - Never send a message without per-message approval, every run, no exceptions. - Never delegate mail to anyone not already named by the user as a delegate. - Never ask the user for their email password or any credential. Use only the account they already connected. - Never forward or quote a message to a third party outside delegation the user set up. - A quiet run (no reply or delegate drafts) sends nothing beyond the one-line summary.

• Interview Prep Coach

  Role and company in, likely questions and talking points out.

  Tested in Museprompt packProductivityinstructionsprep-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Interview Prep Coach" prompt pack. Its full source is below. Save it at ~/workspace/prompts/interview-prep-coach.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: "prep me for this interview", "practice interview questions", "build my interview prep". --- SOURCE --- # Interview Prep Coach How to use: give the role, the company, and the interview round (screen, hiring manager, panel, final). It researches the company and returns likely questions, your talking points, and questions to ask them. Trigger phrases: "prep me for this interview", "practice interview questions", "build my interview prep". Save it as a reusable prompt pack named "Interview Prep Coach". ## The prompt Prep me for this interview. I will give you: the role title, the company, the interview round, and a short version of my background. 1. Research the company: what it does, recent news, and anything relevant to this role. Keep it to 5 bullets. 2. List 8-10 likely questions for this round: mix role-specific, behavioral ("tell me about a time"), and company-specific. 3. For each question, give a 2-line talking point drawn from my background, a direction, not a script. 4. Give me 4 questions to ask them: 2 about the role and team, 1 about the company's direction, 1 that shows I did the reading. 5. End with one honest weak spot to prepare for: the likeliest hard question about my background, and how to answer it directly. Rules: talking points, not scripts: no one should memorize paragraphs. If my background doesn't obviously fit a question, say so instead of inventing experience.

• Marketplace Scout

  Finds flip candidates for your watchlist across Facebook, Craigslist, and eBay.

  Tested in MuseskillDeal huntinginstructionsworkflowwatchlist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Marketplace Scout" skill. Its full source is below. Create it at ~/workspace/skills/marketplace-scout/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: marketplace-scout description: Search Facebook Marketplace, Craigslist, and eBay for a watchlist of items and report flip candidates by margin after fees and shipping. Trigger phrases: "run marketplace scout", "check my flip watchlist", "find flip deals". --- # Purpose Turn a plain list of item names into a ranked list of listings worth buying to resell, after fees and shipping are subtracted from the expected sale price. # Workflow 1. Read the watchlist: one item name per line, each with an optional target condition and an optional max price. The user maintains this list. 2. For each watchlist item, search Facebook Marketplace, Craigslist, and eBay active listings. 3. For each listing found, estimate the resale price from recent eBay sold or completed listings for the same item and condition. Use the median of at least 3 comps; skip the listing if fewer than 3 comps exist. 4. Estimate the total cost to acquire and resell: - the listing price - marketplace or payment fees on the resale (use the platform's published fee rate) - estimated shipping if the item will ship, $0 if local pickup 5. Compute the margin: estimated resale price minus listing price minus fees minus shipping. 6. Keep a listing only if the margin is positive and at least $25. 7. If the watchlist item set a max price, discard any listing above it. 8. Sort surviving candidates by margin, highest first, grouped by watchlist item. 9. If nothing survives, end the run and send nothing. 10. If something survives, write the report in the Output Contract shape and send it. # Output Contract Grouped by watchlist item, one line per candidate: - Listing: title, source (Facebook, Craigslist, or eBay), and link - Price: listing price - Est. resale: median of the sold comps used - Margin: dollar amount after fees and shipping No candidates: no message at all. # Operating Rules - Never message a seller, place a bid, or complete a purchase. Report only. - Never ask the user for a marketplace login, cookie, or API key. Use the assistant's own connected browsing session. - Never estimate resale price from asking prices; use sold or completed listings only. - If comps are too thin (fewer than 3), skip the listing rather than guess a margin. - Run only on the schedule the user confirms.

• Meal Macro Estimator

  Photo a meal; get rough calories and macros logged to a daily file.

  Tested in MuseskillProductivityinstructionsworkflowdaily-log

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Meal Macro Estimator" skill. Its full source is below. Create it at ~/workspace/skills/meal-macro-estimator/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: meal-macro-estimator description: Estimate calories and macros from a meal photo and log them to a daily file, with a running daily total. Trigger phrases: "log this meal", "what are the macros", "track this food". --- # Purpose Frictionless food logging. The user photos a meal; the skill estimates calories, protein, carbs, and fat, appends the entry to today's log, and reports the running daily total. # Workflow 1. Look at the meal photo. Identify the foods and estimate portions in familiar units (a palm of chicken, a cup of rice). 2. Estimate calories, protein (g), carbs (g), and fat (g) per item. Mark every number as an estimate; never present it as measured. 3. Append one entry to food-log/YYYY-MM-DD.md in the workspace: time, foods, and the four numbers. 4. Report the meal's totals plus the running daily total in one short block. 5. On request ("how did I eat today"), summarize the day: total calories and macros, no judgment, no advice unless asked. # Output Contract - food-log/YYYY-MM-DD.md: one entry per meal with time, foods, calories, protein, carbs, fat - Each report: meal totals, then "Day so far: X cal | P xg | C xg | F xg" # Operating Rules - Every number is an estimate. Say so every time. - Never give medical or diet advice. If the user asks for advice, suggest talking to a professional. - Never shame or praise food choices. Report the numbers, nothing else. - The log stays in the user's workspace. Nothing is sent anywhere.

• Meeting Agenda Builder

  Goal plus attendees becomes a tight agenda with timeboxes.

  Tested in Museprompt packProductivityinstructionsagenda-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Meeting Agenda Builder" prompt pack. Its full source is below. Save it at ~/workspace/prompts/meeting-agenda-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 a meeting agenda", "timebox this meeting", "plan this meeting". --- SOURCE --- # Meeting Agenda Builder How to use: give the meeting goal, the attendees, and the time available. It returns a timeboxed agenda where every item earns its slot. Trigger phrases: "build a meeting agenda", "timebox this meeting", "plan this meeting". Save it as a reusable prompt pack named "Meeting Agenda Builder". ## The prompt Build the agenda for this meeting. I will give you: the goal of the meeting (the decision to make or problem to solve), the attendees, and the time available. 1. State the goal at the top in one sentence, phrased as an outcome ("Decide the Q4 hiring plan", not "Discuss hiring"). 2. Build the agenda backwards from the goal: only items that serve the decision earn a slot. 3. Timebox every item; the boxes must sum to the available time minus 5 minutes of buffer. 4. Mark each item: (info) 2-minute updates, (discuss) the real debate, (decide) the call to make. At least one (decide) item is required: if nothing needs deciding, say the meeting should be an email. 5. End with: owner and deadline for anything decided. Rules: if the goal is vague, ask one clarifying question before building. Never pad a 20-minute decision into a 60-minute agenda.

• Meeting Notes Polisher

  Turns raw meeting notes into decisions, owned action items, and a three-line summary.

  Tested in Museprompt packProductivityprompt

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Meeting Notes Polisher" prompt pack. Its full source is below. Save it at ~/workspace/prompts/meeting-notes-polisher.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: "polish my meeting notes", "clean up these notes", "structure my meeting notes". --- SOURCE --- # Meeting Notes Polisher Trigger phrases: "polish my meeting notes", "clean up these notes", "structure my meeting notes". Paste raw meeting notes below the line. Turn them into a structured record. Rules: 1. Read the notes once. List every decision made in the meeting. 2. List every action item. For each one, give the task, the owner, and the deadline. 3. If an action item has no named owner, write "No owner assigned" next to it instead of guessing a name. 4. If an action item has no deadline, write "No deadline set" next to it. 5. List every open question the notes raise but do not answer. 6. Write a three-line summary of the meeting. Each line covers one idea. 7. Do not add a decision, action item, or question that the notes do not state. 8. Do not invent an owner, a deadline, or a next step. Output format: ## Decisions - [Decision 1] - [Decision 2] ## Action items - [Task] | Owner: [Name or "No owner assigned"] | Deadline: [Date or "No deadline set"] ## Open questions - [Question 1] ## Summary [Line 1] [Line 2] [Line 3] --- NOTES --- [Paste raw meeting notes here]

• Packing List Generator

  Trip details in, complete packing checklist out.

  Tested in Museprompt packProductivityinstructionslist-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Packing List Generator" prompt pack. Its full source is below. Save it at ~/workspace/prompts/packing-list-generator.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: "make a packing list", "what should I pack", "pack for this trip". --- SOURCE --- # Packing List Generator How to use: give the destination, dates, trip type, and anything special (a wedding, hiking, a work presentation). It returns a complete checklist grouped by category, adjusted for weather and trip length. Trigger phrases: "make a packing list", "what should I pack", "pack for this trip". Save it as a reusable prompt pack named "Packing List Generator". ## The prompt Build my packing list. I will give you: destination, dates, trip type (beach / city / hiking / business / family visit), and any special events. 1. Check the weather forecast for the destination and dates. 2. Scale clothing quantities to the trip length (a 3-day trip and a 10-day trip pack differently; say which assumption you used). 3. Group the list: Documents & money, Clothing, Toiletries & health, Tech, Extras for the trip type. 4. Add a "day before" section: charge devices, water plants, take out trash, hold mail, the leaving-the-house checklist. 5. Flag anything easy to forget that is hard to replace at the destination (medications, chargers, ID). Rules: no generic filler. Every item should earn its place for this specific trip. Keep it to one page.

• Pantry Cook

  Photo the fridge; get three things you can make tonight.

  Tested in Museprompt packCreativeinstructionsrecipe-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Pantry Cook" prompt pack. Its full source is below. Save it at ~/workspace/prompts/pantry-cook.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: "cook from my pantry", "what can I make with these ingredients", "suggest pantry dinners". --- SOURCE --- # Pantry Cook How to use: photo your fridge, pantry, or both, or paste a list of what you have. It suggests three dinners you can make right now, ranked by how little you are missing. Trigger phrases: "cook from my pantry", "what can I make with these ingredients", "suggest pantry dinners". ## The prompt Look at my ingredients and suggest 3 dinners I can make tonight. 1. List what you can see, grouped loosely: proteins, vegetables, carbs, dairy, sauces and seasonings. 2. Suggest 3 meals, ranked by fewest missing ingredients first. 3. For each meal: name, the 3-5 key steps (short), time estimate, and any missing ingredient clearly marked as "you'd need to buy: X". 4. At least one suggestion must use only what is visible: no missing ingredients at all. 5. Keep each recipe to 5 steps or fewer. No preamble about your love of cooking. Rules: never assume an ingredient that is not visible or listed. If the photo is unclear, ask about the 2-3 items that matter most instead of guessing.

• PR Description Writer

  Paste a diff; get a clear PR title and description.

  Tested in Museprompt packDev & automationinstructionspr-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "PR Description Writer" prompt pack. Its full source is below. Save it at ~/workspace/prompts/pr-description-writer.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: "write my PR description", "draft a pull request", "summarize these changes for a PR". --- SOURCE --- # PR Description Writer How to use: paste a diff, a commit list, or a plain-English summary of what changed. It returns a PR title and description in the template below. Trigger phrases: "write my PR description", "draft a pull request", "summarize these changes for a PR". Save it as a reusable prompt pack named "PR Description Writer". ## The prompt Write the title and description for this pull request. Read the diff or summary I paste and produce: **Title:** one line, imperative mood, under 72 characters ("Add retry logic to checkout", not "fixed stuff"). **Description, in this shape:** - **What:** 2-3 sentences on what changed and why. - **How:** the approach in one short paragraph. Name the key files or modules touched. - **Testing:** how it was verified (tests added, manual steps, or "not yet tested" stated plainly). - **Risk / rollout:** anything reviewers should watch for: migrations, flag flips, breaking changes. Write "None" if there is nothing. Rules: describe outcomes, not file-by-file narration. If the change is unclear from the diff, ask one clarifying question instead of guessing. Keep the whole description under 250 words.

• 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

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

• Record Fair Battle Plan

  Your wantlist plus your budget becomes a one-page fair plan with max prices.

  Tested in MuseskillCreativeinstructionsworkflowwantlist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Record Fair Battle Plan" skill. Its full source is below. Create it at ~/workspace/skills/record-fair-battle-plan/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: record-fair-battle-plan description: Turn a wantlist, a budget, and a fair's vendor list into a one-page battle plan: priority targets with max prices so you never overpay. Trigger phrases: "plan my fair", "record fair plan", "prep for the fair". --- # Purpose Walk into a record fair with a plan instead of a vague hope. The skill takes the wantlist, the budget, and whatever is known about the fair, and produces a one-page sheet: what to hunt, what to pay, what to skip. # Workflow 1. Read the user's wantlist (artist, title, pressing details where known) and the total budget for the fair. 2. For each wantlist item, look up recent sold prices for the matching pressing. Set the max price at the low end of recent solds, minus 10% (fair haggling margin). 3. Rank the wants: top targets (rarely seen for sale, fairly priced max), opportunistic (buy only if under max), skip-at-fair (cheaper online: say so). 4. If a vendor list is available, note which vendors are most likely to carry the top targets (genre specialists first). 5. Divide the budget across the top targets; show the running total so the user sees what fits. 6. Write the one-page plan in the Output Contract shape. # Output Contract A single page: - **Top targets:** up to 5, each with max price and one line on why - **Opportunistic:** the rest of the wantlist with max prices - **Skip at the fair:** items cheaper or easier to find online, with the online price noted - **Budget:** total budget, allocated across top targets, remainder shown # Operating Rules - Max prices come from sold data, low end of the range, never asking prices. - Never inflate a max price because the user "really wants it". The number is the number. - If sold data is too thin for an item, mark it "no comp: set your own ceiling" rather than guessing. - The plan is advice only. It never buys, bids, or contacts a vendor.

• Regex Smith

  Describe the pattern in English; get a tested regex with examples.

  Tested in MuseskillDev & automationinstructionsworkflowtest-cases

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Regex Smith" skill. Its full source is below. Create it at ~/workspace/skills/regex-smith/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: regex-smith description: Turn a plain-English pattern description into a tested regular expression, with match and non-match examples. Trigger phrases: "build me a regex", "regex for this pattern", "write a regex that". --- # Purpose Produce correct regular expressions without the trial-and-error. The user describes the pattern in plain English; the skill returns the regex plus proof it works. # Workflow 1. Read the user's description. Identify: what must match, what must NOT match, and the flavor (JavaScript, Python, PCRE: ask if it matters and wasn't stated). 2. Write the regex. Prefer readability: named groups where the flavor supports them, and a brief annotation of each part. 3. Test it mentally against at least 3 strings that should match and 3 that should not, including edge cases (empty string, boundary characters, unicode if relevant). 4. Report in the Output Contract shape. # Output Contract - Regex: in a code block, with the flavor labeled - Annotated: one line per major part explaining what it does - Should match: 3+ example strings - Should not match: 3+ example strings - Caveats: one line on what the regex deliberately does not handle # Operating Rules - Never return a regex without the match/non-match examples. - If the description is ambiguous (for example, "a date" without a format), ask which format before writing. - Prefer the simplest regex that satisfies the examples; say when a stricter version exists and what it costs in readability. - Nothing is executed anywhere; the "tests" are worked examples, labeled as such.

• Reservation Tracker

  Weekly inbox scan; one list of every upcoming reservation.

  Tested in MuseworkflowProductivityinstructionsworkflowschedule

  by Muse Skills editors · Written for this directory

  ViewCopy install promptSet up the "Reservation Tracker" workflow. Its full source is below. Default schedule: Sunday 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: reservation-tracker description: Weekly inbox scan for upcoming reservations: restaurants, hotels, flights, rentals, in one chronological list. Trigger phrases: "what reservations do I have", "upcoming bookings", "track my reservations". schedule: weekly, Sunday at 09:00 local time (cron: 0 9 * * 0). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "what reservations do I have" request. steps: 1. Search the inbox for confirmation emails: restaurant bookings, hotel and flight confirmations, car rentals, event tickets. 2. Extract for each: what, where, date and time, party size or confirmation code where shown. 3. Keep only reservations in the future. Drop anything already past. 4. Sort chronologically, soonest first. 5. Write the list in the Output shape and send it. If nothing is upcoming, say so in one line. output: - One line per reservation: date/time, what and where, confirmation code if shown - Grouped loosely: this week / later - Quiet weeks: "No upcoming reservations found." rules: - Read only. Never book, change, or cancel a reservation. - Use the most recent confirmation per booking; ignore superseded emails. - If a confirmation is ambiguous, mark it "check manually" rather than guess. - Run only on the confirmed schedule or when asked.

• SEO Meta Writer

  Topic or URL in; title tag and meta description out, within limits.

  Tested in Museprompt packMarketinginstructionsmeta-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "SEO Meta Writer" prompt pack. Its full source is below. Save it at ~/workspace/prompts/seo-meta-writer.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: "write SEO metadata", "write a meta description", "create a title tag". --- SOURCE --- # SEO Meta Writer How to use: give a page URL or a topic plus the target keyword. It returns a title tag and meta description that fit the limits and read like a human wrote them. Trigger phrases: "write SEO metadata", "write a meta description", "create a title tag". Save it as a reusable prompt pack named "SEO Meta Writer". ## The prompt Write the SEO metadata for this page. I will give you a URL or a topic, plus the primary keyword. 1. If I give a URL, read the page first and base the copy on what it actually says. If I give a topic, ask one clarifying question only if the angle is unclear. 2. Title tag: under 60 characters, keyword near the front, written as a promise of what the page delivers. 3. Meta description: 150-160 characters, keyword included naturally, ending with the reason to click. 4. Give two options for each, labeled A and B, with different angles (one direct, one curiosity-driven). 5. Show the character count next to each. Rules: no keyword stuffing, no clickbait that the page can't deliver on. If the page is thin, say what it would need before the metadata matters.

• Social Repurposer

  One long post becomes an X thread, a LinkedIn post, and a caption.

  Tested in Museprompt packMarketinginstructionsplatform-templates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Social Repurposer" prompt pack. Its full source is below. Save it at ~/workspace/prompts/social-repurposer.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: "repurpose this content", "turn this into social posts", "make social versions". --- SOURCE --- # Social Repurposer How to use: paste one piece of long-form content (a blog post, a newsletter section, a thread draft). It returns platform-native versions: an X thread, a LinkedIn post, and a short-form caption. Trigger phrases: "repurpose this content", "turn this into social posts", "make social versions". Save it as a reusable prompt pack named "Social Repurposer". ## The prompt Repurpose this content for social. I will paste the source text. 1. Extract the core idea in one sentence before adapting anything. 2. X thread: 5-8 posts, each under 280 characters. First post is the hook: the most surprising or useful claim, stated plainly. Last post is the takeaway or call to action. Number them. 3. LinkedIn post: 150 words max, conversational, line breaks for readability. Open with the hook, close with a question. 4. Short-form caption (Instagram/Threads): 2-3 sentences plus up to 5 relevant hashtags. 5. Keep the author's voice, match the tone of the source, not a generic "social media voice". Rules: never invent facts not in the source. If the source is too thin for three formats, say which formats work and skip the rest. Never post anything anywhere.

• Standup Writer

  Yesterday's commits plus today's calendar become a tight standup update.

  Tested in Museprompt packDev & automationinstructionsstandup-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Standup Writer" prompt pack. Its full source is below. Save it at ~/workspace/prompts/standup-writer.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: "write my standup", "draft my daily update", "prepare my standup". --- SOURCE --- # Standup Writer How to use: run each morning before standup. It reads yesterday's git history and today's calendar, then drafts the update in yesterday / today / blockers shape. Trigger phrases: "write my standup", "draft my daily update", "prepare my standup". ## The prompt Draft my standup update. Read the git log for the last working day across my active repos, and my calendar for today. Write it in this exact shape: - **Yesterday:** 2-4 bullets, grouped by repo or project. Describe outcomes, not commit messages ("finished the checkout retry logic", not "fix tests"). - **Today:** 2-3 bullets from today's calendar and the natural next steps of yesterday's work. - **Blockers:** only real blockers. If none, write "None." Rules: never invent work. If a commit message is unclear, describe it plainly or omit it. Keep the whole update under 150 words. Ask which repos count as "active" the first time; remember the answer for future runs.

• Subscription Audit

  Finds recurring charges in your email receipts and bank exports, then names what to cut.

  Tested in MuseworkflowMoney & financescheduleworkflowmerchant groupingcut list

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Subscription Audit" workflow. Its full source is below. Create it at ~/workspace/skills/subscription-audit/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Confirm it is installed and tell me the trigger phrases. Then, as a separate step, propose the default schedule (monthly, the 1st at 08:00 local time) and wait for me to confirm or change it before you create any recurring job. --- SOURCE --- name: subscription-audit description: Monthly recurring-charge audit from email receipts and a user-supplied bank export. Groups by merchant, estimates annual cost, and names what to cut with a reason. Read-only, never logs into a bank. Trigger phrases: audit my subscriptions, find recurring charges, what should I cancel. schedule: monthly, the 1st at 08:00 local time (cron: 0 8 1 * *). Confirm the timing with the user before the first scheduled run. trigger: the scheduled date, or a manual "audit my subscriptions now" request, in either case gated on the user supplying a bank export for the period. inputs: - email receipts: read from the user's own connected email account, for the period since the last run. - bank export: a CSV or similar file the user exports from their bank or card portal and provides directly. The assistant never logs into a bank or card site itself, and never asks for banking credentials. steps: 1. At run time, ask the user for the bank export file covering the period since the last run, if it has not already been provided. If the user cannot supply it, end the run and report that the audit needs the export to proceed. 2. Read email receipts from the connected account for the same period. 3. Extract candidate recurring charges from both sources: same or near-identical amount, same merchant name, repeating on a roughly monthly, quarterly, or annual interval. 4. Group extracted charges by merchant. Merge obvious name variants of the same merchant (e.g. "NETFLIX.COM" and "Netflix"). 5. For each merchant group, compute the billing interval, the per-charge amount, and the estimated annual cost (per-charge amount times charges per year). 6. Rank merchant groups by estimated annual cost, highest first. 7. For each group, decide a recommendation: keep, review, or cut. Attach one concrete reason to every "cut" or "review" call (e.g. "no matching login or usage found in receipts for 4 months", "duplicate of another active plan", "price rose 40% since last charge with no note of a plan change"). 8. Produce the report: total estimated annual recurring spend, then the ranked merchant table, then the cut list with reasons. output: a report with three parts. First, total estimated annual recurring spend across all groups. Second, a table of merchant, interval, amount, estimated annual cost, and recommendation. Third, a short cut list naming each "cut" recommendation with its one-line reason. stop_conditions: - Stop and ask if the bank export is missing, unreadable, or covers the wrong period. Never guess at bank data from email receipts alone. - Never treat a single one-off charge as recurring; a merchant needs at least two charges at a consistent interval before it is grouped as a subscription. - Never recommend "cut" without a specific reason tied to the data. operating_rules: - Read-only. Never logs into a bank, card portal, or any financial site. - Never asks the user for a bank password, card number, or any account credential. - Never cancels, pauses, or modifies any subscription. Recommendations only. - Never sends the bank export or its contents to any third party or outside service. - A run with no bank export provided produces no report; it asks for the file instead.

• Trip Planner

  Builds a day-by-day itinerary with time blocks, cost estimates, and links to research.

  Tested in Museprompt packCreativeprompt pack

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Trip Planner" prompt pack. Its full source is below. Save it at ~/workspace/prompts/trip-planner.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: "plan my trip", "build a travel itinerary", "help me plan this trip". --- SOURCE --- # Trip Planner Fill in the slots below, then send the whole prompt. Trigger phrases: "plan my trip", "build a travel itinerary", "help me plan this trip". Plan a trip with these details: - Destination: [destination] - Dates: [start date] to [end date] - Budget: [total budget, or per-day budget] - Travel style: [pace and style, e.g. "relaxed, mid-range hotels, mostly walking" or "packed, budget hostels, public transit"] - Must-dos: [places, activities, or foods that must be in the plan] - Travelers: [number of people, and any constraints such as kids, mobility, or dietary needs] Build a day-by-day itinerary from the arrival date to the departure date. For each day: - Break the day into time blocks (morning, afternoon, evening), each with one main activity and its estimated duration. - Fit every must-do into a specific day and time block. Do not drop one without saying so and why. - Give a cost estimate for each paid activity, meal, and transit leg, in the destination's local currency and in the traveler's stated budget currency if different. - Include one link to research each paid activity or booking (the official site or a well-known booking platform), for the user to verify and book themselves. - Flag anything that needs advance booking (timed tickets, popular restaurants, transit passes) and how far ahead to book it. After the day-by-day plan, give a total cost estimate against the stated budget, and call out anywhere the plan runs over. State clearly, once, at the end: all prices are estimates from research, not live quotes, and the user must verify current prices and availability before booking anything. ## How to use Fill in the six bracketed fields with your trip details, then send the whole prompt to the assistant. Answer any follow-up question about a missing detail (an unclear budget, an ambiguous must-do) so the plan can fit it into a specific day.

• Unclaimed Money Scout

  Checks class-action settlements and unclaimed property for money owed to you.

  Tested in MuseskillMoney & financeinstructionsworkflowclaim-links

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Unclaimed Money Scout" skill. Its full source is below. Create it at ~/workspace/skills/unclaimed-money-scout/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: unclaimed-money-scout description: Search class-action settlements and state unclaimed-property databases for money you may be owed. Trigger phrases: "am I owed any settlement money", "check unclaimed property for me", "find money owed to me". --- # Purpose People leave money on the table every year: class-action settlements they never heard about, forgotten security deposits, uncashed checks sitting in state unclaimed-property funds. This skill checks the public sources and points at what might be yours. # Workflow 1. Ask the user for: full name (and past spellings or maiden name if relevant), and every state they have lived or worked in. Nothing else. Never ask for SSN, bank details, or passwords. 2. Check these public sources: - State unclaimed property: missingmoney.com (multi-state NAUPA search) and each relevant state's official .gov unclaimed-property site. - Open class-action settlements: topclassactions.com and classaction.org: filter to settlements still accepting claims, and match by the user's purchase or membership history (ask what products, services, or employers apply). - FTC refunds: ftc.gov enforcement refunds page for government-administered payouts. 3. For each potential match, report: what it is, the estimated payout range if published, the claim deadline, and the official claim link. 4. Report in the Output Contract shape. # Output Contract - Checked: the sources searched and the name/states used - Potential matches: one line each, what, payout range, deadline, official claim link - Long shots: settlements that might apply but need more info from the user - Nothing found: say so in one line, and suggest re-checking yearly # Operating Rules - Public sources only. Link to official claim sites (.gov or the settlement administrator), never to aggregator sign-up funnels. - Never file a claim on the user's behalf. The user files their own claims. - Never ask for or accept SSN, bank account numbers, or passwords. If the user offers them, the skill refuses and explains why. - Payout ranges come from the published settlement terms, not from anecdotes. If no range is published, say so. - Re-checking is a yearly habit, not a weekly one. Say that.

• Vinyl Vault

  Catalogs your record collection from photos or lists and tracks its value.

  Tested in MuseskillCreativeinstructionsworkflowwantlist

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Vinyl Vault" skill. Its full source is below. Create it at ~/workspace/skills/vinyl-vault/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: vinyl-vault description: Catalogs a vinyl record collection from photos or pasted lists (artist, title, pressing, condition), keeps a wantlist, and estimates collection value from recent sold prices. Trigger phrases: "add these records", "catalog my vinyl", "what's my collection worth", "add to my wantlist". --- # Purpose Track a vinyl record collection: what you own, its condition, its estimated value, and what you want next. # Workflow 1. When the user adds records, accept a photo of album covers or spines, or a pasted text list. 2. For each record, extract or ask for: artist, title, pressing or edition (year, country, label if known), and condition (Mint, Near Mint, Very Good Plus, Very Good, Good, Poor). 3. If condition is missing, ask once. Do not guess a condition. 4. Append each new record to `collection.md` in the workspace, one row per record, with the date added. 5. When the user says a title, artist, or "wantlist", add it to `wantlist.md` with the date added. Remove an item from the wantlist when the same title appears in `collection.md`. 6. When the user asks for collection value, or once a month if the user has asked for a monthly report, look up recent sold prices for each pressing using the assistant's own web search. Match on artist, title, and pressing details. Use the median of the last 5 sold listings in the matching condition band. 7. If no sold listings match a pressing, mark that record "no comp found" and exclude it from the total. Do not estimate from an unrelated pressing. 8. Report the total, the count of records with no comp, and the 5 records that moved most in value since the last report, if a previous report exists. # Output Contract - `collection.md`: a table with columns Artist, Title, Pressing, Condition, Date Added, Last Estimated Value, Comp Date. - `wantlist.md`: a table with columns Artist, Title, Date Added, Notes. - A value report states: total estimated value, number of records counted, number excluded for no comp, and the top movers. - Every value in a report carries its comp date. A value never appears without one. # Operating Rules - Never buy, bid on, or list a record on any marketplace. - Never contact a seller, dealer, or marketplace on the user's behalf. - Never invent a pressing detail or a sold price. State "no comp found" instead. - Do not ask for payment details, login credentials, or an API key for any marketplace. Use only the assistant's own web search for comps. - A monthly report runs only when the user has asked for one, and it sends nothing when the collection has not changed and no new comps exist worth reporting.

• Weekly Feed Brief

  A feed-prompt template that turns your weekly briefing into topics you chose.

  Tested in MuseconfigProductivityconfigfeed-prompt

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Weekly Feed Brief" config template. Its full source is below. Save the template at ~/workspace/prompts/weekly-feed-brief.md exactly as given, with the bracketed fields left as literal placeholders. Confirm it is saved. Then, as a separate second step, ask me for my topics, sources, desired length, and delivery day. Only after I answer, offer to write the feed prompt setting, and wait for my confirmation before writing it. --- SOURCE --- # Weekly Feed Brief config ## Where this lives Assistant settings → Feed → Feed prompt. This snippet replaces or extends the text in that field. ## Config snippet ``` topics_follow: - "[Topic 1, e.g. commercial real estate financing]" - "[Topic 2, e.g. changes to a named regulation]" - "[Topic 3, e.g. a competitor or company name]" sources_prefer: - "[Source 1, e.g. a named trade publication]" - "[Source 2, e.g. a named analyst or outlet]" sources_skip: - "[Source to exclude, e.g. a low-quality aggregator]" - "[Topic to exclude, e.g. general market commentary with no new fact]" output_length: "[short: 3-5 bullets | medium: one paragraph per topic | long: full briefing with links]" delivery_day: "[day of week, e.g. Monday morning]" quiet_rule: "If no topic has a genuine update this week, send nothing rather than a briefing with no news." ``` ## What to change - `topics_follow`: name specific topics, not broad categories. - `sources_prefer`: name outlets or people, not "reputable sources." - `sources_skip`: name what to exclude, whether a source or a category of story. - `output_length`: pick one of the three named lengths. - `delivery_day`: one day and a rough time of day. ## Install steps 1. Fill in each bracketed field from what the user states. 2. Show the completed snippet back to the user. 3. Wait for explicit confirmation. 4. Write the confirmed snippet to the assistant's feed prompt setting. 5. Confirm the write succeeded and name the day the first briefing arrives.

• Weekly Review

  End-of-week review: open loops surfaced, next week's priorities drafted.

  Tested in Museprompt packProductivityinstructionsreview-template

  by Muse Skills editors · Written for this directory

  ViewCopy install promptInstall the "Weekly Review" prompt pack. Its full source is below. Save it at ~/workspace/prompts/weekly-review.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: "run my weekly review", "draft my weekly review", "review my week". --- SOURCE --- # Weekly Review How to use: run this Friday afternoon, or on a schedule you set. It reads your calendar, inbox, and goal file, then drafts the review. You approve the priorities; it never sets them for you. Trigger phrases: "run my weekly review", "draft my weekly review", "review my week". ## The prompt You are running my weekly review. Read my calendar for the past 7 days, my inbox for flagged and unread messages, and my goal file. Use only what these three sources contain. Do not invent a meeting, an email, a goal, or completed work that is not in them. Build the review in this exact order: 1. **Done this week.** The 3-5 most significant completed items, from calendar events and sent mail. One line each. 2. **Open loops.** Anything started but unfinished: unanswered threads, meetings with no follow-up, goals with no movement. One line each, with the next physical action. 3. **Proposed priorities for next week.** Three items, drawn from the open loops and the goal file. Mark them as proposed; the user confirms or edits them. 4. **Calendar check.** Anything next week that needs prep, flagged one line each. Rules: do not mark anything done that is not evidenced in the sources. Keep the whole review under one page. End by asking which of the three proposed priorities to keep.

No skills match your filters.

How it works

1. 1

   Copy

   Choose Copy install prompt on any skill. The install prompt goes to your clipboard.

2. 2

   Paste

   Open your Muse chat and paste the block.

3. 3

   Confirm

   Muse creates the skill, asks before it schedules anything, and tells you the trigger phrases.