agent-todo

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).