Immutable. This exact content is served forever at /api/v1/blob/460abdba4394cacb.
---
name: kalender
version: 0.1.0
type: assist
author: ellmos-ai
created: 2026-06-22
updated: 2026-06-22
description: Calendar skill with user-adaptive backend selection (Flag 3). Default: local SQLite store. Optional: Google Calendar MCP, Routinika or UpToday as backend — controlled via assist/prefs.json. Without preference the LLM asks the user interactively.
standalone: true
anthropic_compatible: true
bach_compatible: false
bach_origin: false
category: assist
tags: [kalender, termine, events, ics, google-calendar, routinika]
language: de
status: stable
visibility: public
dependencies: {'tools': [], 'services': [{'name': 'Google Calendar MCP', 'optional': True, 'purpose': 'Backend option when kalender_backend=google in prefs.json'}], 'protocols': [{'name': 'ICS / iCalendar', 'optional': True, 'purpose': 'Import/export of appointments (RFC 5545 subset)'}], 'python': []}
provenance: {'origin': 'eigenentwurf', 'origin_path': '', 'origin_version': '', 'origin_repo': '', 'origin_license': 'MIT', 'last_sync_from_origin': '', 'notes': 'Kein BACH-Origin gefunden (kein kalender-Service in BACH/system/). Skill vollständig neu konzipiert mit Flag-3-Logik (user-adaptive backend). ICS-Felder angelehnt an RFC 5545, kein externer ICS-Parser benötigt.\n'}
---
<img src="banner.png" width="100%" alt="kalender banner">
## 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**: core.py — Termin in SQLite-Store anlegen/abfragen/löschen.
4. **Google-Backend**: LLM ruft Google-Calendar-MCP direkt auf (core.py nicht beteiligt).
5. **Ausgabe**: Lesbare Terminliste oder Bestätigung.
---
## CLI-Einstieg
```bash
# 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
```sql
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 |