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

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

View source

Ready to copy.

Details

Type: skill
Category: Money & finance
Version: 1.0.0
Added: 7 Oct 2026
Author: Muse Skills editorsWritten for this directory
Includes: instructionsworkflowtemplates
Source: github.com/…/invoice-drafter.md

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

Before you install

A shared skill carries somebody else's instructions. Read the source before you install it.
Never paste an API key, password, or token into anything a skill asks for. Legitimate skills use Muse's own secure flows.
Installing copies the setup into your own environment. It gives the author nothing.

What it does

Invoice Drafter turns a pile of timesheet lines and task notes into a draft invoice you can send with confidence. It groups the work into clear line items written in client language, not internal shorthand, computes subtotal, tax, and total with the math shown, and pairs the invoice with a short prose summary of what was done in the billing period. Anything it had to guess becomes an explicit question, so you verify the assumptions before anything goes out.

It drafts only. It never sends, never contacts the client, never marks anything paid or final. The human reviews and sends every time, which is the whole point: the tedious parts are done, and the judgment calls stay yours.

What it includes

Timesheet and task-note reader with missing-field prompts
Line-item grouping in client-readable language
Subtotal, tax, and total with visible math
A short client-ready prose summary
An assumptions list so nothing unverified goes out

Example

Input: five timesheet lines for a September design retainer, $150/hr.

Output:

DRAFT INVOICE: Acme Co. / September 2026
- Sep 8-12: Homepage wireframes, 8h x $150 = $1,200
- Sep 15-19: Checkout flow revisions, 6h x $150 = $900
Subtotal: $2,100 | Tax: n/a | Total due: $2,100
Terms: Net 15 (placeholder)

CLIENT SUMMARY
September covered two milestones: homepage wireframes and checkout
flow revisions, totaling 14 hours. Total due: $2,100.

QUESTIONS
- Confirm Sep 19 revision counts toward retainer hours.

What this one touches

Drafts only; it never sends the invoice, never contacts the client, and never marks anything paid or final. A human reviews and sends every time.

Install

Copy this block and paste it into your Muse chat. Muse does the install and confirms when it's done.

Install prompt

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

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

Full source

This is the exact text Muse installs. Read it. That's the whole trust model.

SKILL.md

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

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

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