subscription-audit

<skill name="subscription-audit"> <overview> Keep SaaS spend honest without turning into weekly noise. A cron re-prompts a persistent session that pulls recurring charges from Plaid, reads the subscription register in {{subscription_sheet}}, and reconciles the two: duplicate or overlapping tools, seats that look unused, price hikes since the last check, renewals coming up soon, and shadow IT — recurring charges with no matching row in the register. Only new or changed findings get reported; an unresolved item from last week doesn't repeat as if it were new. Proactive and schedule-driven; read-only against Plaid and the register, with a single Slack digest as the only output. The agent recommends; it never cancels, pauses, downgrades, or otherwise modifies a subscription. </overview> <when-to-load> - The weekly cron fires the spend-audit run. - A human asks for a manual check of SaaS spend or a specific vendor. - The subscription register is updated and needs a fresh reconciliation pass. </when-to-load> <workflow> ## Step 0 — Orient and resume ```sh cat .kortix/memory/saas-spend-audit-log.md 2>/dev/null || echo "(no ledger yet — first run)" ``` Read the last recorded state for every tracked subscription: its last known price, when it was last flagged, what was recommended, and whether it's still open. This run diffs against that history — a subscription flagged last week with nothing new to say gets skipped, not repeated. ## Step 1 — Pull recurring charges from Plaid Fetch card and bank transactions for a trailing window (60–90 days) wide enough to catch both monthly and annual cadences. Group by merchant/payee and amount to identify which charges are actually recurring — a one-off purchase is not a subscription. ## Step 2 — Read the subscription register Read every row in {{subscription_sheet}}: vendor, plan, seat count, price, renewal date, and owning team, where present. This is the source of truth for what the business believes it's paying for. ## Step 3 — Reconcile charges against the register Match each recurring charge to a register row by vendor and amount (allow small tolerance for currency conversion or a prorated period). A recurring charge with no matching row, after checking obvious name variants (`Acme Inc.` vs `Acme, Inc` vs `ACME*SUBSCRIPTION`), is **shadow IT**. ## Step 4 — Detect the five waste signals | Signal | How to detect | |---|---| | **Duplicate / overlapping tools** | Two or more register rows serving the same category (e.g. two project-management tools, two e-signature tools) with active charges on both. | | **Unused seats** | A register row's seat count against any usage/active-user data available (register notes, admin exports mentioned in the sheet); flag a gap wide enough to matter, not a single idle seat. | | **Price hikes** | This charge's amount vs. the last price recorded in the ledger or register for that vendor — flag anything above the skill's threshold (default: >5% or any absolute jump worth a person's attention). | | **Upcoming renewals** | A register renewal date within the next 30 days, especially on an annual plan, so there's time to act before it auto-renews. | | **Shadow IT** | A recurring charge from Step 3 with no matching register row at all. | ## Step 5 — Filter against the ledger Drop anything unchanged from a prior week's report. Keep: brand-new findings, findings where something material changed (price moved again, renewal is now closer, a previously-unused seat is still unused N weeks later), and anything a human marked in the ledger as "recheck." Never drop shadow IT until it's either added to the register or explicitly dismissed by a human. ## Step 6 — Compose and post the digest One message to {{alert_channel}} per run: - Group by signal type (duplicates, unused seats, price hikes, renewals, shadow IT). - Each line: the vendor, the evidence (charge amount, register row or its absence, the specific numbers involved), and a suggested action — cancel, downgrade, consolidate onto one tool, renegotiate before renewal, or "add to register and confirm owner" for shadow IT. - A quiet week (nothing new or changed) gets a single brief line, not a re-post of every still-open item in full. Every recommendation is phrased as a suggestion for a person to execute — the agent never implies it has taken or will take the action itself. ## Step 7 — Update the ledger Update `.kortix/memory/saas-spend-audit-log.md` with the current state of every tracked subscription (see `<ledger-format>`) and a dated log line of what was reported this week. </workflow> <ledger-format> Lives at `.kortix/memory/saas-spend-audit-log.md`. Maintains, per vendor: the last known price, the last charge date and amount, the register match status (matched / shadow IT), the most recent recommendation and its status (open / dismissed by a human / register updated). Below that, dated **Run log** entries with what was newly reported, what stayed silent because it was unchanged, and any reconciliation the agent couldn't resolve (e.g. ambiguous vendor name match) for a human to confirm next run. </ledger-format> <guardrails> - **Recommend-only.** The agent suggests cancellations, downgrades, and consolidations. It never cancels, pauses, downgrades, or otherwise modifies a subscription or a payment method — no billing API write access exists. - **Read-only connectors.** Plaid and the subscription register are read-only. The agent never writes a row, a price, or a status into either system. - **No repeat noise.** The ledger is checked before every post — an unresolved finding from a prior week is not re-reported as new. - **Shadow IT is flagged, not judged.** A charge with no register match is reported with its evidence; the agent doesn't assume it's unauthorized or recommend blocking the card, only that a human confirm and register it. - **Secrets scoped.** The Plaid access token and Sheets credentials are injected at runtime, scoped to this agent's grant. - **Audit rules are code.** Waste thresholds (e.g. the price-hike percentage) live in this skill and change through a reviewed change request, not an ad hoc instruction mid-run. </guardrails> </skill>