Money Leak Auditor

Money leak auditor

Rebuild the user's entire software and vendor spend from screen capture, price it, and find the leaks.

Purpose

This works because half of a solo operator's or small agency's spend never reaches a finance tool. It lives in billing emails, Stripe receipts, vendor dashboards, and card decline alerts. Between 30% and 40% of large-organization IT spend is already outside the system of record, card-bought expensed software grew 267% year over year, and a one-person business has no procurement system at all [references/research/distilled-saas-spend-leakage.md, section 2]. Screen capture reads all of those surfaces. That is the entire premise.

The skill looks backward at spend that already happened and asks what is wasted: what is paid for and never opened, what is failing and about to delete data, and what is priced above what the user would pay today. The forward-looking half, what is about to charge and what can still be stopped, belongs to renewal-sentinel. Do not build a renewal calendar here.

Littlebird MCP calls used

Trigger

Invoke when the user says any of: subscription audit, where is my money going, cancel unused tools, find zombie subscriptions, failed payments, SaaS spend review, cut software costs, what am I paying for, why did my card get declined, what is this charge.

Also invoke after the monthly spend sentinel fires with anything marked REPEAT or ESCALATED.

Routine cadence

Monthly, plus on demand. The monthly sentinel observes and notifies. The on-demand session does the audit, the drafts, and the approvals.

Routines can be created from an interactive session, so this skill offers to create its own sentinel rather than telling the user to go set one up by hand. Only a running routine is blocked from calling LB_INTERNAL_CREATE_ROUTINE [references/littlebird-mcp-reference.md, Routine tools]. See the routine wiring section below for the exact prompt text and schedule.

Capability gate

This skill requires the Littlebird MCP server on a Power or Pro plan.

1. List the available tools before calling anything. Use the real tool names from the live server. Do not assume the names in references/littlebird-mcp-reference.md are still current; that file records what was verified on 2026-08-17 and is a starting point, not a guarantee.
2. If no Littlebird MCP tools are present, stop and tell the user this skill needs the Littlebird MCP connected. Do not attempt the audit from any other source.
3. If tools are present but plan status is in doubt, call LB_INTERNAL_GET_SUBSCRIPTION_STATUS and report what it says.

Evidence standards

Read references/evidence-standards.md before producing output. It is not optional background. The rules that govern this skill most directly:

• Every claim carries a receipt in the canonical format [Tuesday, August 11, 2026 23:40 EDT | chrome] (rule 1).
• Every line is observed, inferred, external, or unknown, and which one is visible to the reader (rule 2).
• "No evidence of use in 90 days" and "unused" are different claims. Only the first is supportable (rule 2). This governs the entire zombie section.
• Confidence ratings are stated, and a Low-rated claim never drives an irreversible action (rule 3).
• Capture shows what the user was viewing, not what they bought (rule 4).
• Confirm before encoding, and confirm before sending (rule 6).
• Raw capture never ships (rule 7).
• Empty retrieval ends the run (rule 9).

The pricing rule specific to this skill: never assert a price the capture did not show. An amount seen once is Medium. An amount seen across three consecutive billing periods is High.

Output

The skill writes three files into the working directory, dated with the run date:

If the user names a different location, use it. If nothing was found, write only the report, and have it say what was searched and what came back empty.

Process

Seven phases. Do not skip phase 4.

Phase 1: scope

Ask the user two things before sweeping, using AskUserQuestion:

• How far back to sweep. Default 12 months, walked one month at a time.
• Whether this is personal spend, business spend, or both.

Phase 2: build the candidate ledger

Follow references/vendor-ledger-construction.md steps 1 through 3. Run the five query families, extract candidate lines, and deduplicate.

Use several narrow parallel queries rather than one broad one. A broad query against this server returns 70,000-plus characters and gets dumped to a file instead of returned [references/littlebird-mcp-reference.md, Oversized results].

Run scripts/ledger_math.py on the candidate lines rather than deduplicating by eye. OCR of a billing dashboard repeats lines, and the collapse plus the run-rate arithmetic across four cadences and three confidence tiers is deterministic work.

Phase 3: rate confidence

Follow references/vendor-ledger-construction.md steps 4 and 5. Rate the amount and the cadence separately. A vendor with no observed amount stays on the ledger with amount unknown. A vendor with unknown cadence is excluded from the run rate and reported in its own block.

Phase 4: confirm the vendor list, before pricing anything

This gate is mandatory and it comes before any total.

Capture both misses vendors and invents them. A pricing page the user read, an ad they scrolled past, or a competitor's dashboard in a screen share all put a vendor name and a price into the capture with no payment behind it.

Run AskUserQuestion presenting three groups: confirmed by a payment artifact, named but unpaid in capture, and ambiguous. Ask the open question too: what are you paying for that is not on this list. See references/vendor-ledger-construction.md step 6.

Only after this gate: price, total, and proceed.

Phase 5: zombie detection

Follow references/zombie-detection.md. For every confirmed paid vendor, run the three query families at 30, 60, and 90 days and assign a usage_verdict.

Guard the four traps that guide names, especially the third: infrastructure, APIs, deliverability, monitoring, backups, gateways, and scheduled automation deliver full value with zero screen time. Those are background-suspected, they go to a question, and they never go on a cancel list.

Every zombie finding ships with the sweep that produced it: the windows, the queries, the filters, and the last observation of any kind.

Phase 6: cascade tracing

Follow references/cascade-tracing.md. Harvest failure signals, build a timeline sorted by event time, find the common payment instrument, and report one cause, one fix, and the exceptions rather than N separate problems.

Triage by damage, not by dollar amount. Data deletion outranks a large failing charge, because money is recoverable and data is not.

Cross the cascade against the zombie list. A failing charge on an unused vendor is a cancellation the vendor already started, not a problem to fix.

Phase 7: the action pack

Follow references/action-pack-and-negotiation.md. Produce five lists: cancel, downgrade, consolidate, renegotiate, keep. Every vendor lands in exactly one.

Build the downgrade list first. Underutilization is 51% of licenses against 14% entirely unused, so right-sizing is the larger savings pool and the less painful action [references/research/distilled-saas-spend-leakage.md, section 1].

Report savings by action with the confidence they inherit, and present three totals: confirmed, probable, and a negotiation range kept separate and not added in.

Draft the emails. Hold them. Run the approval gate.

Retrieval brief

The actual queries. Run each family with search_user_context, windowed one month at a time and walked back across the scope agreed in phase 1.

Two retrieval disciplines that matter here specifically:

• Read the relevance scores. Items scoring below 3 are omitted entirely, and a single 3-scored item does not support a claim without corroboration [references/littlebird-mcp-reference.md, Retrieval patterns].
• Sort by timestamp before presenting anything. Results come back in relevance order, not chronological order [references/littlebird-mcp-reference.md, Known limitations].

Empty retrieval branch

If the sweep returns nothing across families A through E, the run ends. Write the report with:

• The date windows searched, month by month.
• The exact queries and filters run.
• The statement that no billing or vendor spend evidence was found in that window.
• What would change the outcome: a wider window, a period when the user was actually doing billing, or a check that Littlebird capture was running.

Do not reconstruct a plausible stack from what a business of this shape usually buys. Do not fill the ledger from training data. A report saying "I found nothing for this window" is the correct output [references/evidence-standards.md, rule 9].

The same rule applies at phase 5: if usage sweeps return nothing even for tools the user uses daily, the sweep is broken, not the stack. Report the malfunction rather than declaring the stack dead.

Guardrail

The cancel list is the dangerous output. Everything else in this report is reversible.

A subscription kept one month too long costs one month of money, and money comes back. A service cancelled because it left no screen evidence can cost DNS, mail deliverability, backups, monitoring, a payment gateway, or a scheduled automation that nothing was watching. That damage does not come back. The asymmetry governs the rules:

• Infrastructure, APIs, deliverability, monitoring, backups, gateways and scheduled automation deliver full value with zero screen time. They are background-suspected, they become a question to the user, and they never reach a cancel list [references/zombie-detection.md, trap 3].
• "No evidence of use in 90 days" and "unused" are different claims, and only the first is supportable [references/evidence-standards.md, rule 2]. Write the one you can defend.
• Every zombie finding ships with the sweep that produced it, so the user can see the windows, the queries and the filters that failed to find usage rather than a bare verdict.
• A Low-rated claim never drives an irreversible action [references/evidence-standards.md, rule 3].
• The phase 4 confirmation gate is mandatory and comes before any total, because capture invents vendors as readily as it misses them. A pricing page read, an ad scrolled past, or a competitor's dashboard seen in a screen share puts a vendor name and a price into capture with no payment behind it [references/vendor-ledger-construction.md, step 6].

The second guardrail is other people's billing. Capture reads whatever crossed the screen, which includes a client's billing dashboard in a screen share, a colleague's invoice, and a vendor portal belonging to someone else. That is not the user's spend. It never enters the ledger as theirs, it never appears in an output file, and it never appears in a draft [references/evidence-standards.md, rules 4 and 7]. No draft quotes raw capture, names other vendors, or describes the user's stack beyond the account being cancelled.

Never draft-and-send

The skill drafts. The user sends. There is no path through this skill that transmits anything to a vendor.

Do not call an email tool. Do not open a compose surface and fill it. Do not offer to send as a convenience. Every draft goes into cancellation-drafts-YYYY-MM-DD.md headed STATUS: HELD FOR APPROVAL. Not sent. and the run stops at the approval gate [references/evidence-standards.md, rule 6].

No draft quotes raw capture, names other vendors, or describes the user's stack beyond the account being cancelled [references/evidence-standards.md, rule 7].

Routine wiring: the monthly spend sentinel

The on-demand audit is the primary mode. The sentinel is a cheap monthly observer that watches for change between audits and hands off when it finds something.

Offer to create it. Show the user the exact title, schedule and prompt text below, get approval with AskUserQuestion, then call LB_INTERNAL_CREATE_ROUTINE. Do not tell the user to go set it up by hand. This works from an interactive session; only a running routine is blocked from creating or editing routines [references/littlebird-mcp-reference.md, Routine tools].

Title: Spend sentinel

Schedule: {"frequency": "monthly", "month_day": 1, "time": "08:00"}

Notifications: enable push. Enable email if the user wants a copy.

Prompt text, verbatim:

You are a monthly spend sentinel. Your job is to detect CHANGE in the user's software
and vendor spend. You do not run a full audit and you do not draft anything.

FIRST, before searching, call LB_INTERNAL_GET_ROUTINE_REPORTS for this routine with
limit 6 and read your own previous reports. You need them to tell new from repeated and
to escalate correctly. Do not skip this step.

Then search the user's captured context for the last 35 days, using several narrow
queries rather than one broad one, covering:

1. NEW CHARGES. Queries: "payment receipt from", "thanks for your payment", "your
   subscription has started", "welcome to your new plan", "receipt for your
   subscription". A vendor is NEW only if it does not appear in any previous report you
   just read.

2. FAILED CHARGES. Queries: "payment failed", "your card was declined", "action
   required to keep your account", "past due balance", "account will be suspended",
   "your data will be deleted", "transaction declined", "insufficient funds". Also
   search message threads for the same, since these arrive as SMS and in-app alerts.

3. PRICE INCREASES. Queries: "we are updating our pricing", "your plan is changing
   price", "your subscription renews on", "annual renewal reminder", "price increase
   effective". Report the old and new amounts only where the capture shows both.

Write a report with exactly these four sections:

NEW THIS MONTH
Each new vendor, with the amount as shown, the date, and the evidence receipt in the
form [Weekday, Month D, YYYY HH:MM TZ | app]. Never state an amount the capture did not
show. If no amount was captured, say the vendor name and "amount not captured".

FAILING NOW
Each failing charge, with vendor, amount, escalation stage, and receipt. If two or more
vendors are failing, check whether the notices name the same card or the same last four
digits, and say so. Do not diagnose the root cause in detail; that is the on-demand
skill's job. State the pattern and hand off.

PRICE MOVED
Each observed price change, with old amount, new amount, and receipt. Flag any increase
above 5 percent, which exceeds the buyer-protective norm, and call out any increase
above 12 percent, which exceeds even the typical vendor ask.

UNCHANGED AND NOTABLE
Anything you expected to see and did not, in one or two lines.

ESCALATION RULE. Compare against the previous reports you read at the start.
- An item appearing for the SECOND consecutive month: mark it REPEAT and say how long
  it has been open.
- An item appearing for the THIRD consecutive month or more: mark it ESCALATED, move it
  to the top of the report, and state plainly that the passive approach is not working
  and it needs a decision, not another notification.
- An item that has resolved since the last report: say so in one line and stop tracking
  it.
Never report the same item in the same words two months running. If nothing about it
has changed, say that nothing has changed and how many months it has now been open.

HANDOFF. End every report with this line, adjusted for what you found:
"Open Cowork and run money-leak-auditor for the full audit. This month's priority: X."
Where X is the single highest-damage item, ranked by data loss first, then service
shutdown, then dollar amount.

If the searches return nothing, say so plainly, name the window you searched, and stop.
Do not fill the report from what you would expect a business like this to be paying
for.

How the handoff works. The routine observes and notifies. It cannot approve, draft, or write files. The user opens Cowork, invokes this skill, and the skill reads the sentinel's own history with LB_INTERNAL_GET_ROUTINE_REPORTS before sweeping, which gives the audit a change log it would otherwise have to reconstruct [references/littlebird-mcp-reference.md, The Routines-observe, Cowork-acts pattern].

When invoked after a sentinel alert, read the last 6 sentinel reports first. Vendors already flagged REPEAT or ESCALATED go to the top of the action pack.

Illustrative receipt

What ordinary capture already yields, before any dedicated sweep. On a real account, a general-purpose daily routine that was not designed for spend auditing surfaced an infrastructure vendor failing repeatedly at $700.19 with a shutdown warning, an AI coding tool at $216 and again at $90, an email infrastructure vendor at $499, a data API at $95, a code review tool at $73.75, a media editor at $65, an AI gateway at $49, a proxy service at $30, plus a secrets manager, a writing tool, an affiliate platform, and an audience tool threatening data deletion. All of it traced to one unfunded business card.

Two things follow. A dedicated sweep will find considerably more than an incidental one. And that daily routine reported twelve problems where a cascade trace reports one cause, one fix, and one exception.

Calibration and honesty notes

• A median company runs 25 active subscriptions and the top 10% run 49 or more [references/research/distilled-saas-spend-leakage.md, section 3]. A confirmed ledger far under 25 lines for an operating business is evidence of a thin sweep, not a lean stack. Say so.
• Do not quote a single industry waste percentage as settled. The sources disagree, using 36%, 46%, 51%, and a 14% plus 51% split, and none of them state a comparable denominator [references/research/distilled-saas-spend-leakage.md, section 1].
• Do not apply enterprise dollar waste averages to a solo operator. The archive explicitly warns those band averages are dominated by the top of their range [references/research/distilled-saas-spend-leakage.md, section 3].
• The 30 / 60 / 90 day zombie windows are this skill's operating convention, not researched thresholds. No source in the archive establishes how long a paid tool must go unopened before cancellation is justified [references/research/distilled-saas-spend-leakage.md, section 9, gap 4]. Present them as conventions and let the user move them.
• Ten of the twelve archived sources are published by companies selling SaaS management, spend control, or dunning tooling, and each has a commercial interest in a large waste number [references/research/distilled-saas-spend-leakage.md, section 9, gap 5]. Quote their figures as vendor estimates.

Related skills

Reference map

Ship Gate removed, research-only skill, produces no committable code.