RowanJu/subs

subs – SaaS-Abonnementkosten-Analyse

Analysiere die wiederkehrenden Abonnementausgaben des Benutzers aus Bank-/Kreditkarten-CSV-Exporten und E-Mail-Quittungen. Erstelle eine Ausgabenübersicht, kennzeichne Verschwendung, verfolge Verlängerungen und empfehle Einsparungen.

Das Hauptbuch ist das Rückgrat

subscriptions.yaml im Arbeitsbereich ist die einzige Quelle der Wahrheit. Jeder Durchlauf gleicht neue Daten damit ab – es leitet nie alles von Grund auf neu ab. Dadurch werden Verlängerungsverfolgung und Konsistenz zwischen den Durchläufen real, und „Verschwendung“ wird berechenbar (ein Abo, das monatelang abgebucht wurde und dann plötzlich fehlt = ausgelaufen oder kündigenswert). Überschreibe das Hauptbuch niemals vollständig; gleiche es ab.

Schema eines Hauptbucheintrags (ein Eintrag pro Abonnement):

- vendor: GitHub               # kanonischer Name
  amount: 4.00                 # letzte Abbuchung
  currency: USD
  cycle: monthly               # weekly | monthly | quarterly | semiannual | annual
  category: Dev tools
  first_seen: 2025-01-12       # ISO-Datum der frühesten bekannten Abbuchung
  last_seen: 2026-06-03        # ISO-Datum der letzten Abbuchung
  next_renewal: 2026-07-03     # last_seen + ein Zyklus
  status: active               # active | price_hike | lapsed? | cancelled
  notes: "war seit Anmeldung 4.00"

Voraussetzung: Ein Gmail-Konnektor

Dieser Skill liest Abonnementquittungen aus Gmail über einen Gmail-Konnektor/MCP, der deinem Coding-Agenten zur Verfügung steht (z. B. Claude Codes Gmail-Konnektor). Bestätige vor Schritt 1, dass dein Agent über Gmail-Such-/Lesewerkzeuge verfügt (ein search_threads/get_thread-Paar oder Äquivalent). Wenn keine Gmail-Integration verfügbar ist, stoppe und teile dem Benutzer mit, dass er eine aktivieren soll, und führe den Skill dann erneut aus. Details und Abfragen findest du in email-receipts.md.

Prozess

Arbeite diese Schritte der Reihe nach ab. Berichte erst nach Schritt 5.

0. Arbeitsbereich lokalisieren

Verwende das aktuelle Arbeitsverzeichnis als Arbeitsbereich. Stelle sicher, dass data/statements/, data/receipts/ und reports/ existieren (erstelle sie, falls sie fehlen). Lade subscriptions.yaml, falls vorhanden; andernfalls behandle das Hauptbuch als leer. Erledigt, wenn: die Arbeitsbereichsverzeichnisse existieren und das Hauptbuch geladen ist (ggf. leer). Wenn data/statements/ leer ist UND noch keine subscriptions.yaml existiert UND der Benutzer nicht Plaid verwendet (nächster Abschnitt), teile dem Benutzer mit, dass er seine Bank-/Kreditkarten-CSV-Exporte in data/statements/ ablegen soll, und stoppe – die CSVs sind das Rückgrat der Wiedererkennung.

1. Eingaben sammeln

Bankdaten über die Plaid-CLI (bevorzugt – kein manueller CSV-Export): Stelle sicher, dass die CLI bereit ist, und ziehe Transaktionen gemäß plaid.md in data/statements/plaid-transactions.csv. Andernfalls verwende die CSVs, die der Benutzer in data/statements/ abgelegt hat.

Liste dann jedes CSV in data/statements/ auf. Ziehe Abonnementquittungen aus Gmail gemäß email-receipts.md und lies auch alle ergänzenden .eml/.txt-Dateien in data/receipts/. Erledigt, wenn: jedes CSV in data/statements/ aufgelistet ist und die Gmail-Quittungssuche zurückgekehrt ist (oder der Durchlauf aufgrund eines fehlenden Konnektors gestoppt wurde).

2. Wiederkehrende Abbuchungen erkennen

Führe den deterministischen Detektor über jedes Kontoauszugs-CSV (einschließlich des von Plaid abgeleiteten) aus – überfliege keine Zeilen. <skill-dir> ist das eigene Verzeichnis dieses Skills (in Claude Code: ~/.claude/skills/subs/):

python3 <skill-dir>/scripts/detect_recurring.py data/statements/*.csv

Bei Kandidaten mit low-Vertrauen und Grenzfällen der Händlernormalisierung konsultiere recurrence-detection.md. Kombiniere diese Kandidaten mit den in Schritt 1 gesammelten Gmail-Quittungen – Quittungen erfassen jährliche Abos, die ein kurzer Kontoauszug übersieht, und identifizieren vage Beschreibungen. Erledigt, wenn: jeder wiederkehrende Kandidat einen Händler, einen Rhythmus, einen Betrag und ein Datum der letzten Sichtung hat.

3. In das Hauptbuch einpflegen

Gleiche Kandidaten mit subscriptions.yaml ab:

• Neuer Händler → füge einen Eintrag hinzu; kategorisiere gemäß categories.md.
• Vorhanden → aktualisiere last_seen und next_renewal; wenn der Betrag gestiegen ist, setze status: price_hike und notiere den alten Betrag in notes.
• Im Hauptbuch, aber in aktuellen Daten nicht vorhanden (keine Abbuchung innerhalb von ~1,5 Zyklen ab heute) → setze status: lapsed?.

Erledigt, wenn: der status jedes Hauptbucheintrags einer von active | price_hike | lapsed? | cancelled ist und jeder Kandidat genau einem Hauptbucheintrag zugeordnet ist.

4. Analysieren

Berechne aus dem abgeglichenen Hauptbuch alle vier Punkte:

• (a) Ausgabenübersicht – monatliche Gesamtsumme und annualisierte Gesamtsumme, gruppiert nach Kategorie, nach Händler und nach Abrechnungszyklus. Normalisiere jeden Eintrag auf einen monatlichen Wert ($/Monat): jährlich ÷ 12, halbjährlich ÷ 6, vierteljährlich ÷ 3, monatlich × 1, zweiwöchentlich × 2,17, wöchentlich × 4,33, halbmonatlich × 2. Die Berichte verwenden diesen $/Monat-Wert (einzige Quelle der Wahrheit).
• (b) Verschwendung – Duplikate (gleicher Dienst zweimal), überlappende Tools (zwei Produkte in derselben Kategorie mit gleicher Funktion), Preiserhöhungen (status: price_hike) und ausgelaufene/unbenutzte (status: lapsed?).
• (c) Bevorstehende Verlängerungen – Einträge, deren next_renewal innerhalb der nächsten 60 Tage liegt, zuerst die baldigen.
• (d) Sparvorschläge – Wechsel von jährlich zu monatlich, Downgrades, Konsolidierungen und Kündigungen. Jeder Vorschlag muss einen Hauptbucheintrag und eine Dollarauswirkung nennen.

Erledigt, wenn: alle vier Punkte erstellt sind und jede Empfehlung einen Eintrag + einen Dollarbetrag nennt.

5. Bericht

Speichere das Hauptbuch, schreibe dann beide Berichte daraus:

• Markdown reports/<YYYY-MM-DD>-subscriptions.md gemäß report-template.md;
• Ein eigenständiges HTML-Dashboard reports/<YYYY-MM-DD>-subscriptions.html gemäß html-report.md und öffne es (open <pfad>).

Präsentiere dann eine kurze Zusammenfassung im Chat (Kopfzeilensummen + Top-3-Aktionen). Erledigt, wenn: beide Berichte die Ausgabenübersicht, Verschwendungsmarkierungen, bevorstehende Verlängerungen und bewertete Empfehlungen enthalten und subscriptions.yaml gespeichert ist.