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.

• Packing List Builder

  Turns trip details, weather, and activities into a checked packing list grouped by bag, so nothing important stays home.

  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.

• Moving Cost Estimator

  Turns your inventory list, distance, and service level into a realistic moving cost estimate before you call anyone.

  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.

• 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

  Hunts open-box, refurbished, and clearance deals on the exact product you name, and ranks them by real savings over new.

  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 and make promoters feel seen.

  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 home maintenance schedule for your home type and climate: what to do, when, and what to skip.

  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 for you, what is nice to know, 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 structured 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

  Watches incoming reports against rules you set and flags anomalies while the day is still 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

  Scans support tickets, clusters repeat 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 where money is burning, 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 plus a client-ready summary; 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

  Order coffee or food from chat: full review with fees and total, and your approval before anything is submitted.

  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 keeps it honest through the seasons.

  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 store's return deadline, and warns you before the window closes.

  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, based on 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 your 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 true all-in cost of the same 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 for lowering cable, internet, and insurance bills, with answers to their 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 history, not the strikethrough.

  Tested in MuseskillShoppinginstructionsworkflowverdict-format

  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, not the strikethrough, historical low, average, and whether to buy now or wait. Trigger phrases: "is this a good price", "should I buy this now", "check the price history". --- # Purpose Strikethrough prices lie. This skill checks what an item has actually sold for over time and gives a buy-now-or-wait verdict grounded in that history. # Workflow 1. Ask the user for the product link or exact model name. 2. Find price history: camelcamelcamel-style trackers for Amazon items, manufacturer price pages, and recent sold listings for marketplace items. 3. Record: current price, 90-day average, historical low and when it hit it, and any predictable sale pattern (Prime Day, Black Friday, model refresh). 4. Verdict rules: - At or near historical low: "buy" - Within 10% of average with no pattern: "fair: buy if you need it now" - Above average with a known sale window within 60 days: "wait" 5. Report in the Output Contract shape. # Output Contract - Verdict: buy, fair, or wait, one word, then one line why - Price history: current, 90-day average, historical low (with date), sale pattern if any - Caveats: thin history, refurbished vs. new mismatch, or regional pricing differences # Operating Rules - History comes from trackers and sold listings, not from the merchant's "was" price. Say the source. - "Wait" needs a reason: a dated sale window or a pattern, not vibes. - Thin history gets a caveat, not a confident verdict. - Read only. Never buy, never sign up for price trackers.

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