Money & finance

Skills that read your receipts and statements and tell you what to cut.

14 of 14 skills

type

Moving Cost Estimator
Turns your inventory list, distance, and service level into a realistic moving cost estimate before you call anyone.
skillinstructionsworkflowestimate-templatemover-questions
by Muse Skills editors · Written for this directory
ViewInstall 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.
Reconciliation Checker
Compares two money sources line by line and flags every mismatch.
skillinstructionsworkflowreport format
by Muse Skills editors · Written for this directory
ViewInstall 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.
Invoice Drafter
Turns completed work and timesheet lines into a draft invoice plus a client-ready summary; a human always sends it.
Tested in Museskillinstructionsworkflowtemplates
by Muse Skills editors · Written for this directory
ViewInstall 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.
Reward Card Picker
Picks the best card in your wallet for a purchase, based on rewards rates and active offers.
Tested in Museskillinstructionsworkflowcard-wallet-profile
by Muse Skills editors · Written for this directory
ViewInstall 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.
Contract Reader
Turns dense contracts into plain-language summaries with key dates, fees, and red flags.
Tested in Museskillinstructionsworkflowreport-format
by Muse Skills editors · Written for this directory
ViewInstall 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.
Invoice Chaser
Drafts polite, escalating payment reminders for overdue invoices.
Tested in Museskillinstructionsworkflowtemplates
by Muse Skills editors · Written for this directory
ViewInstall 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.
Bill Negotiation Script
A call script for lowering cable, internet, and insurance bills, with answers to their pushback.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall 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.
Net Worth Snapshot
Monthly one-page net worth with the month-over-month change.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet 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.
Tax Doc Gatherer
February checklist of expected tax documents; tracks what arrived.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet 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 Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet 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.
Bill Due Radar
Weekly inbox scan; one list of every bill due in the next 14 days.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet 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.
Expense Receipt Wrangler
Photo a receipt; it logs merchant, date, total, and category.
Tested in Museskillinstructionsworkflowexpense-log
by Muse Skills editors · Written for this directory
ViewInstall 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.
Subscription Audit
Finds recurring charges in your email receipts and bank exports, then names what to cut.
Tested in Museworkflowscheduleworkflowmerchant groupingcut list
by Muse Skills editors · Written for this directory
ViewInstall 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.
Unclaimed Money Scout
Checks class-action settlements and unclaimed property for money owed to you.
Tested in Museskillinstructionsworkflowclaim-links
by Muse Skills editors · Written for this directory
ViewInstall 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.