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
- Backend prüfen:
assist/prefs.json → kalender_backend lesen.
- Ohne Präferenz: LLM fragt Nutzer: lokaler Kalender, Google Calendar oder anderer?
- Local-Backend: core.py — Termin in SQLite-Store anlegen/abfragen/löschen.
- Google-Backend: LLM ruft Google-Calendar-MCP direkt auf (core.py nicht beteiligt).
- Ausgabe: Lesbare Terminliste oder Bestätigung.
CLI-Einstieg
# Termin anlegen
python kalender_core.py add "Zahnarzt" --date 2026-07-01 --time 10:00 [--duration 60] [--location "Praxis Dr. X"]
# Heutige Termine
python kalender_core.py today
# Wochenübersicht
python kalender_core.py week [--from 2026-06-22]
# Monatsübersicht
python kalender_core.py month [--month 2026-07]
# Alle Termine (optional mit Suchbegriff)
python kalender_core.py list [--search "Zahnarzt"] [--limit 50]
# Termin löschen
python kalender_core.py delete <id>
# ICS-Export
python kalender_core.py export [--id <id>] [--out kalender.ics]
# Backend-Check
python kalender_core.py check-backend
# Alternativer Store (z.B. für Tests)
python kalender_core.py --store /tmp/kal_test.db today --dry-run
Store
| Eigenschaft |
Wert |
| Typ |
SQLite (local-Backend) |
| Pfad (Standard) |
skills/assist/kalender/store.db |
| Override |
--store <pfad> oder Env KALENDER_STORE |
| Tabellen |
events |
Schema
CREATE TABLE IF NOT EXISTS events (
id TEXT PRIMARY KEY, -- UUID (kurz: 8 Hex)
title TEXT NOT NULL, -- Termin-Bezeichnung
date TEXT NOT NULL, -- ISO-Datum YYYY-MM-DD
time TEXT, -- HH:MM (optional)
duration_min INTEGER, -- Dauer in Minuten (optional)
location TEXT, -- Ort (optional)
description TEXT, -- Notiz/Beschreibung
recurrence TEXT, -- ICS RRULE (optional, z.B. "FREQ=WEEKLY")
ics_uid TEXT UNIQUE, -- ICS UID für Import/Export
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
Haltung
- Der Core implementiert nur das
local-Backend — leichtgewichtig, keine externen Deps.
- ICS-Export erzeugt valides RFC 5545-Subset (VCALENDAR + VEVENT), importierbar in alle gängigen Kalender-Apps.
- ICS-Import (Parsing) ist v0.1 noch nicht implementiert — geplant für v0.2.
- Wiederholungsregeln (
recurrence/RRULE) werden gespeichert aber nicht ausgewertet — Auswertung ist v0.2.
Datenschutz
- Lokale Termine bleiben in
store.db — kein Netzwerkzugriff im Core.
- Beim Google-Calendar-Backend-Pfad verarbeitet Google-Calendar-MCP die Daten — Google-Datenschutzbestimmungen gelten.
store.db nicht in Git committen (empfohlen: .gitignore).
Verwandte Ressourcen
- Google-Calendar-MCP (
mcp__claude_ai_Google_Calendar__*) — alternatives Backend, LLM-gesteuert
- Skill
assist/haushalt-manager — Routinika-Integration (Presence-Check-Muster)
tools/module-installer/module_installer.py — für zukünftige Routinika/UpToday-Backend-Integration
Changelog
| Version |
Datum |
Änderung |
| 0.1.0 |
2026-06-22 |
Erstanlage — Flag-3-Logik, local-Backend, ICS-Export |
ellmos-ai