| name | agent-todo |
| description | Verwaltet Paul Baders zentrale Aufgaben-DB „Assistent-Aufgaben" in Notion — die von Claude/Kleya geführte Aufgaben-Ebene für alles Bereichsübergreifende/Persönliche (Planner, D365, Attio bleiben System-of-Record ihrer Domäne). Drei Aktionen: (1) Aufgabe anlegen aus natürlicher Sprache (Titel, Fälligkeit, Erinnerung, Notiz, Wichtigkeit, Bereich; Batch möglich), (2) Aufgabe abschließen (Fuzzy-Match, bei Mehrdeutigkeit Rückfrage), (3) Überblick über die offenen Aufgaben (gruppiert nach Fälligkeit). Aktivieren bei: "merk dir", "setz auf meine Liste", "neue Aufgabe", "todo", "to-do", "Aufgabe anlegen", "erinnere mich", "hak ab", "erledigt", "schließ ab", "was steht auf meiner Liste", "meine offenen Aufgaben", "Aufgabe verschieben". NICHT für den Tages-/Wochenüberblick über alle Quellen ("was steht heute/diese Woche an", "Briefing") — das macht agent-brief (liest Notion-Aufgaben + Planner + D365 + Outlook). Dieser Skill berührt nur die Notion-DB.
|
Assistent-Aufgaben (Notion)
Zweck & Abgrenzung
Die Notion-DB „Assistent-Aufgaben" (unter der Kleya-Seite) ist der assistentseitige
To-do-Kanal an Paul (Semantik geschärft 2026-08-03): alles darin kommt von Claude — ob von
Paul diktiert („merk dir X") oder von Claude im Lauf proaktiv erkannt. Der Marker ist die Liste
selbst — kein Quelle-Feld nötig, was hier liegt, ist per Definition assistent-authored. Sie hat
die alte Microsoft-To-Do-Liste „Assistent" abgelöst (Entscheid 2026-07-13 — der geplante
headless-Lauf kommt ohne User-M365-Login aus, Notion ist scoped + read-path existiert; die
MS-Liste wurde 2026-08-03 gelöscht).
Harte Boundary:
- Dieser Skill = nur die Notion-DB „Assistent-Aufgaben", nur CRUD + eigener Überblick.
- Nur echte Paul-To-dos — Dinge, die Paul tun muss. Nicht die System-Features, die wir
planen (Memory, Skills, Box …) → die sind Kleya-Roadmap in
memory/state/projects.md. Das ist
die Kern-Abgrenzung des Kanals.
- Private Tasks bleiben in Microsoft To-Do (native App fürs schnelle Erfassen, bewusst
nicht im Brief) — die rührt dieser Skill nie an.
- Bereichsübergreifender Überblick (Notion-Aufgaben + Planner + D365 + Outlook) = agent-brief.
Hier keinen Multi-Quellen-Brief nachbauen — das driftet sonst gegen agent-brief.
- Planner / D365 / Attio bleiben System-of-Record ihrer Domäne. Nicht hierher spiegeln.
- Nicht die Kleya-Roadmap: das Assistenz-System-Tracking liegt in
memory/state/projects.md,
nicht hier. Im Zweifel fragen, welche Liste gemeint ist.
DB & IDs
Alle IDs kommen ausschließlich aus memory/state/notion-ids.json, nie hart hier:
- Schreiben (anlegen/ändern/abschließen) → MCP mit
assistent-todo.todo_data_source
(collection-ID 12fc9e71-…).
- Lesen (Überblick, Kandidaten fürs Abschließen) →
scripts/notion_query.py
mit Alias assistent_todo (Database-ID; read-only-Pfad, headless-tauglich).
Boundary: API/Script liest strukturiert, MCP schreibt. Grund: notion-query-data-sources
(MCP) ist auf Pauls Plan gesperrt — der REST-Read via notion_query.py ist der Lesepfad.
Schema (Property-Namen exakt so):
Aufgabe (title) · Status (Offen/Erledigt) · Fällig (date) · Erinnerung (date) ·
Wichtigkeit (Hoch/Normal) · Bereich (Klientenarbeit/Akquise/Intern/Privat) · Notiz (text).
TOOLS — vor dem ersten Datencall in EINEM Sweep laden
Alle benötigten Tools per tool_search bevor der erste Datencall startet. Nicht inkrementell.
Regel: Kommt ein Tool nach 2 Suchanfragen nicht → aufgeben, Paul Alternative anbieten.
| Zweck | Weg | Wichtige Parameter |
|---|
| Offene Aufgaben lesen | bash scripts/notion_query.py --db assistent_todo --filter "Status=Offen" --ids | --ids gibt _id/_url je Zeile (für Writes) |
| Aufgabe anlegen | MCP notion-create-pages | parent={data_source_id: todo_data_source}, properties (s. u.) |
| Aufgabe ändern/abschließen | MCP notion-update-page | page_id (aus _id), properties |
Empfohlene tool_search-Queries: notion create pages, notion update page.
Der Read läuft über bash, nicht über ein MCP-Tool.
Property-Mapping beim Schreiben (MCP-Eigenheit, verbindlich)
notion-create-pages/notion-update-page nehmen Properties als flache SQLite-Werte. Datumsfelder
über die expandierten Schlüssel setzen, nicht als nacktes Objekt:
- Titel:
"Aufgabe": "…"
- Status:
"Status": "Offen" (beim Anlegen immer Offen) bzw. "Erledigt" beim Abschließen
- Fälligkeit ohne Uhrzeit:
"date:Fällig:start": "2026-07-20"
- Erinnerung mit Uhrzeit:
"date:Erinnerung:start": "2026-07-20T08:00:00", "date:Erinnerung:is_datetime": 1
- Wichtigkeit:
"Wichtigkeit": "Hoch" (nur bei „wichtig"/„dringend"; sonst weglassen)
- Bereich:
"Bereich": "Akquise" (nur wenn erkennbar; sonst weglassen)
- Notiz:
"Notiz": "…"
Datum/Zeit-Konventionen
- Heute ist der
currentDate aus dem Kontext. Relative Angaben („morgen", „nächsten
Dienstag", „in 2 Wochen") immer gegen currentDate zu einem absoluten ISO-Datum auflösen,
bevor geschrieben wird.
- Reine Fälligkeit ohne Uhrzeit → nur
date:Fällig:start (ohne is_datetime).
- Abschließen =
notion-update-page mit "Status": "Erledigt". Aufgaben werden nicht
gelöscht — Erledigtes bleibt mit Status=Erledigt stehen.
Aktion 1: Anlegen
Trigger: „merk dir", „setz auf die Liste", „neue Aufgabe", „erinnere mich an …", „todo: …".
Auch Batch („leg an: X, Y, Z") — mehrere Pages in einem notion-create-pages-Call.
Ablauf:
- Aus dem Satz extrahieren: Titel (knapp, handlungsorientiert), Fälligkeit (falls genannt
→ absolut auflösen), Erinnerung, Notiz, Wichtigkeit, Bereich (falls erkennbar).
- Keine Pflicht-Rückfrage. Fehlt ein Fälligkeitsdatum, ohne anlegen — nicht nachfragen.
Nur bei echt unklarem Titel eine kurze Rückfrage.
notion-create-pages unter todo_data_source, Status=Offen. Titel in Pauls knapper
Sprache, kein Consulting-Sprech, keine Floskeln.- Schreiben, dann knapp bestätigen (eine Zeile pro Task: Titel + ggf. Fälligkeit).
Low-Stakes — kein Bestätigungs-Gate vor dem Schreiben (anders als agent-outreach).
Aktion 1b: Proaktiv anlegen (assistant-authored)
Claude erkennt im Lauf einen Next-Step, den Paul tun muss (offener Faden aus einer Session, der
Morgen-Lage, einem Kleya-Lauf), den sonst kein System festhält. Weil die Liste der assistentseitige
Kanal ist (alles darin kommt von Claude), darf Claude hier proaktiv anlegen — ohne dass Paul
„merk dir" sagt. Das ist die stehende Anweisung von Paul (Entscheid 2026-08-03).
Zwei-Stufen-Autonomie (verbindlich):
- Interaktiv (laufende Session, Morgen-Lage, Kleya): direkt anlegen und in derselben Antwort
sagen — write-then-tell, wie bei Aktion 1. Kein Gate. Paul kann „nimm das runter" sagen.
- Headless/geplant (Cron-Läufe): nie still schreiben — dort ist kein Reviewer, Flut-Gefahr
ist real. Den Kandidaten stattdessen im Zustellkanal vorschlagen (Kleya-Speicherseite / Brief);
beim nächsten interaktiven Start wandert er in die Liste. Geplante Läufe bleiben read-only.
Filter vor jedem proaktiven Write:
- Ist es ein echter Paul-To-do (Paul muss handeln)? Nein → nicht anlegen. System-/Roadmap-Kram
→
projects.md, nicht hier.
- Gehört es in eine Domäne mit eigenem SoR (Planner/D365/Attio, z. B. ein Nurture-Touch)?
Ja → dort anlegen, nicht hier spiegeln.
- Dedupe: offene Aufgaben lesen (
--filter "Status=Offen") und gegen die Titel prüfen —
kein Duplikat anlegen.
Erst wenn 1 = ja, 2 = nein, 3 = frei: anlegen (Ablauf wie Aktion 1), dann sagen.
Aktion 2: Abschließen
Trigger: „hak X ab", „erledigt", „schließ … ab", „done".
Ablauf:
- Offene Aufgaben lesen:
notion_query.py --db assistent_todo --filter "Status=Offen" --ids.
- Pauls Bezeichnung fuzzy gegen die Titel (
Aufgabe) matchen.
- Genau ein plausibler Treffer →
notion-update-page mit page_id = _id,
"Status": "Erledigt", knapp bestätigen.
- Mehrere/unklar → Kandidaten zeigen und fragen, welche gemeint ist. Erst nach
Klärung schließen. (Die einzige Stelle mit Vorsicht — nichts blind abhaken.)
- Kein Treffer → sagen, dass nichts Passendes offen ist; nicht raten.
- Batch („hak A und C ab") analog, pro Task ein Update.
Aktion 3: Überblick
Trigger: „was steht auf meiner Liste", „meine offenen Aufgaben", „zeig die Assistent-Aufgaben".
Ablauf:
- Offene Aufgaben lesen (
--filter "Status=Offen").
- Gruppieren und innerhalb nach Fälligkeit sortieren:
Überfällig · Heute · Diese Woche · Später · Ohne Datum.
- Pro Aufgabe eine Zeile:
- Titel — Fälligkeit (DD.MM.), ⚠️ bei Wichtigkeit=Hoch/überfällig.
Leere Gruppen weglassen. Keine Methodik, keine Floskeln.
- Nur diese DB. Kein Planner/D365/Outlook — das ist agent-brief.
Reschedule / Edit (klein)
„verschieb X auf Freitag", „benenn um", „mach X wichtig": erst lesen (--ids), dann
notion-update-page mit dem jeweiligen Feld (date:Fällig:start, Aufgabe, Wichtigkeit).
Datum wie oben absolut auflösen. Bei mehrdeutigem Match wie bei „Abschließen" rückfragen.
Autonomer / geplanter Lauf
Bei Schedule-Trigger ohne User-Input ist die sinnvolle Aktion der Überblick (read-only).
Headless nie still schreiben: proaktiv erkannte Paul-To-dos werden vorgeschlagen (Aktion 1b,
Zustellkanal Kleya-Seite/Brief), nicht angelegt — der Write passiert erst beim nächsten
interaktiven Start. Abschließen oder Ändern bleibt autonom immer verboten — die brauchen
Pauls konkretes Wort. Zustellkanal: Default Chat-Output; Push nur auf expliziten Wunsch über
denselben Pfad wie agent-brief (Teams-Selbstchat) — keine eigene Versand-Logik hier einbauen.
Memory / Lernen
Dieser Skill lernt nicht (analog agent-brief / agent-productivity-hacks). Gehört zu keinem
der drei Lern-Loops (Ton / Themenwert / Konstruktion). Kein distill, keine memory/rules/,
keine memory/logs/-Telemetrie. Die einzige Wahrheit ist die Notion-DB selbst (Domänendaten).
Aus memory/state/ wird nur notion-ids.json gelesen (Fakt: DB-/data_source-ID), kein Lern-Layer.
Haltung (gilt immer)
- Sprache: Deutsch, Pauls Voice — knapp, kein Consulting-Sprech, keine Floskeln. Bei längerem
Aufgaben-Text
voice-core mitladen.
- Anlegen ist Low-Stakes → schreiben, dann bestätigen. Abschließen ist die vorsichtige Stelle →
bei Mehrdeutigkeit immer fragen, nie blind abhaken.
- Relative Daten immer absolut auflösen, bevor geschrieben wird.
- Lieber eine präzise Zeile als eine vollständige Tabelle.
- Boundary halten: nur die Notion-DB „Assistent-Aufgaben". Multi-Quellen-Überblick = agent-brief;
private Tasks = MS To-Do (nicht hier).
