kalender

## Zweck Termine erfassen, abfragen und verwalten — mit wählbarem Backend. Der Core (`kalender_core.py`) arbeitet immer mit dem **lokalen SQLite-Store** als Default. Das LLM wählt bei Bedarf ein alternatives Backend anhand von `assist/prefs.json`. **Flag 3 — Backend-Wahl:** | `kalender_backend` in prefs.json | Verhalten | |---|---| | `local` (Standard/Default) | SQLite-Store in diesem Skill-Ordner | | `google` | Google-Calendar-MCP (nur LLM-Pfad, nicht in core.py) | | `routinika` | Routinika-Kalender via module-installer (nicht impl. v0.1) | | `uptoday` | UpToday-Kalender via module-installer (nicht impl. v0.1) | | nicht gesetzt | LLM fragt den Nutzer interaktiv nach bevorzugtem Backend | > `kalender_core.py` implementiert ausschließlich das `local`-Backend. > Google-Calendar-MCP und weitere Backends sind LLM-gesteuert und werden > im SKILL.md dokumentiert, nicht im Core. --- ## Trigger | Phrase | Aktion | |---|---| | „Trag Termin ein" | Neuen Termin erfassen | | „Was steht heute an?" | Heutige Termine abfragen | | „Was steht diese Woche an?" | 7-Tage-Überblick | | „Termin [Titel] am [Datum]" | Termin mit Datum anlegen | | „Alle Termine im [Monat]" | Monatsübersicht | | „Termin löschen [ID]" | Termin entfernen | | „Termin exportieren" | ICS-Export aller/einzelner Termine | --- ## Workflow 1. **Backend prüfen**: `assist/prefs.json` → `kalender_backend` lesen. 2. **Ohne Präferenz**: LLM fragt Nutzer: lokaler Kalender, Google Calendar oder anderer? 3. **Local-Backend**...