nanobot-runtime/results/2026-06-07_todo-skill-unification-analysis.md

Analýza: /todo skill a unifikace /note, /remind, /keep

1. Současný stav — co každý skill dělá

Skill	Storage	Příkazy	Klíčová vlastnost	Problémy
/keep	keep.md (plain markdown)	add, list	Okamžitá persist, žádná struktura	Append-only, žádné mazání/úpravy, žádné kategorie, plaintext
/note	db/note.sqlite	add, list, search, delete, edit	Plné CRUD, kategorie, vyhledávání	Není "task-oriented", žádný status/due date
/remind	reminder.yaml + .reminder_state.json	add, delete	Časové plánování, Telegram notifikace	YAML race conditions, žádný list, žádné edit, fragile dedup
/todo (navrhovaný)	—	—	Seznam úkolů bez časového plánování	Neexistuje

1.1 Překryv funkcionality

/keep add "koupit mléko"          →  plaintext záznam
/note add "koupit mléko" --cat shopping  →  strukturovaný záznam
/todo add "koupit mléko"          →  úkol (co se liší od note?)
/remind add "koupit mléko" at 18:00  →  úkol + časová notifikace

Základní entita je stejná: text + metadata. Rozdíl je v chování (notifikace, status tracking).

---

2. Požadavky na /todo

Z uživatelova popisu: "podobný jako remind, jen tam není to přesné časové odesílání".

To znamená:

• Přidat úkol
• Označit jako hotový
• Seznam aktivních/dokončených úkolů
• Smazat úkol
• Možná priorita, kategorie, due date (bez notifikace)

To je 90% funkcionality /note + jeden sloupec status.

---

3. Architektonické varianty

Varianta A: Jeden univerzální skill /task (nebo /item)

Koncept: Jeden SQLite DB, jedna tabulka items:

CREATE TABLE items (
    id INTEGER PRIMARY KEY,
    type TEXT CHECK(type IN ('note','todo','reminder','keep')),
    content TEXT NOT NULL,
    category TEXT,
    status TEXT CHECK(status IN ('active','done','archived')),
    due_at TIMESTAMP,          -- pro todo + reminder
    schedule TEXT,             -- cron expr pro reminder
    notify_channel TEXT,       -- telegram, etc.
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Příkazy:

/task note add "obsah" --cat prace
/task todo add "udělat review" --priority high --due 2026-06-10
/task remind add "zavolat" --at 2026-06-08T10:00
/task keep add "zapamatuj si heslo"
/task list --type todo --status active
/task done <id>
/task delete <id>

Výhody:

• Jednotné API — uživatel se učí jeden skill
• Jeden storage — žádná duplicita dat
• Flexibilní — úkol může "proměnit" z todo na remind přidáním schedule
• Fulltext search přes všechny typy najednou
• Jedna codebase na CRUD

Nevýhody:

• Velká změna — migrace 3 existujících skillů
• /remind potřebuje minutový cron — to nelze udělat uvnitř LLM agenta
• Risk "one size fits none" — kompromisy v UI každého typu
• Složitější permission model (co když chci remind bez todo?)

Verdikt: Příliš monolitické. /remind cron mechanismus je technický důvod pro separaci.

---

Varianta B: Zachovat separaci, přidat orchestraci

Koncept: Existující skilly zůstanou. Nový skill /task (nebo /items) je "meta-skill" — analyzuje záměr a deleguje na správný pod-skill.

Uživatel: "připomeň mi zítra v 10 zavolat"
→ /task rozpozná "připomeň" + čas → volá /remind

Uživatel: "zapiš si že Ollama má 5h limit"
→ /task rozpozná "zapiš si" → volá /note

Uživatel: "mám udělat review PR"
→ /task rozpozná úkol bez času → volá /todo

Výhody:

• Zachovává specializaci každého skillu
• Postupná adopce — nemusí se migrovat existující data
• /remind zůstane samostatný pro cron

Nevýhody:

• Orchestrace přes LLM je nespolehlivá (záměr se může špatně klasifikovat)
• Uživatel stále potřebuje znát 4 commandy
• Duplicitní kód (list, delete, search se opakují v každém skillu)
• "Magie" — uživatel neví, kam se data vlastně uložila

Verdikt: Přidává komplexitu bez jasného benefitu. Klasifikace záměru je problém, který LLM agent řeší už teď implicitně.

---

Varianta C: Konvergence — sloučit /keep do /note, /todo jako rozšíření /note

Koncept:

1. /keep se stane aliasem na /note add --cat keep + /note list --cat keep
2. /note se rozšíří o sloupec status (NULL = note, 'active'/'done' = todo)
3. /todo je nový skill, ale volá stejný SQLite DB jako /note — jen s default filtrem status IS NOT NULL
4. /remind zůstane samostatný (YAML + cron), ale může číst z note DB pro kontext

Schéma rozšíření:

ALTER TABLE notes ADD COLUMN status TEXT CHECK(status IN ('active','done','archived'));
ALTER TABLE notes ADD COLUMN due_date TIMESTAMP;  -- optional, bez notifikace
ALTER TABLE notes ADD COLUMN priority INTEGER DEFAULT 0;  -- -1 low, 0 normal, 1 high

Příkazy:

/note add "Ollama limit 5h" --cat knowledge        →  klasická poznámka
/note add "koupit mléko" --cat shopping --status active --due 2026-06-10  →  todo v note DB
/todo add "udělat review" --priority high          →  shortcut pro note s status=active
/todo list                                           →  note list --status active
/todo done <id>                                      →  note edit <id> --status done
/keep add "heslo je xyz"                            →  alias: note add --cat keep

Výhody:

• /note a /todo sdílejí storage — žádná duplicita
• /keep se zjednoduší (odpadne custom markdown parser)
• Uživatel může používat /note pro vše, nebo /todo pro rychlý přístup
• Postupná migrace — /keep.md se může naimportovat do note DB
• /remind zůstane nezměněný (žádný cron refactoring)

Nevýhody:

• /todo skill je technicky tenká vrstva nad /note — může působit zbytečně
• Dvě cesty k jednomu cíli (/note add --status active vs /todo add)

Verdikt: Nejpragmatičtější. Zachovává existující investici, minimalizuje duplicitu.

---

Varianta D: /todo jako samostatný skill s vlastním storage

Koncept: Úplně nový skill, vlastní SQLite DB db/todo.sqlite, žádná vazba na /note.

Výhody:

• Čistá separace concerns
• Nezávislý vývoj
• Jednoduché schéma optimalizované pro task tracking

Nevýhody:

• Další DB, další skill, další maintenance
• Uživatel musí rozhodnout: dát to do /note, /todo, nebo /remind?
• Překryv s /note je obrovský (90% kódu by bylo stejné)

Verdikt: Nepřijatelné. Vytváří problém, který řešíš.

---

4. Doporučená architektura

Fáze 1: Rozšířit /note o task tracking (okamžitě)

Rozšířit note.py o:

• status sloupec (NULL = note, 'active'/'done'/'archived' = task)
• due_date sloupec (optional)
• priority sloupec (optional)
• Příkazy: --status, --due, --priority v add a edit
• list filtry: --status, --due-before, --priority

Fáze 2: Vytvořit /todo jako thin wrapper (lehký skill)

/todo skill s vlastním SKILL.md, ale volá stejný note.py skript s přednastavenými parametry:

# /todo add "udělat review" → interně:
uv run scripts/note.py add "udělat review" --status active

# /todo list → interně:
uv run scripts/note.py list --status active --sort priority,due_date

# /todo done <id> → interně:
uv run scripts/note.py edit <id> --status done

Toto je podobné patternu, který používá např. git switch jako alias na git checkout.

Fáze 3: Deprecate /keep (postupně)

• Přidat do /note kategorii keep
• Migrace: keep.md → import do note DB s cat=keep
• /keep skill zůstane jako read-only legacy, nebo se stane aliasem

Fáze 4: /remind integrace (volitelně, později)

• /remind může číst z note DB — když uživatel řekne "připomeň mi úkol #5", /remind najde note s id=5 a vytvoří reminder
• Nebo: /remind může ukládat do note DB místo YAML (ale cron skript by musel číst SQLite — možné, ale větší změna)

---

5. Technické detaily /todo skillu

5.1 Schéma dat (rozšířené /note)

CREATE TABLE notes (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    content TEXT NOT NULL,
    category TEXT,
    status TEXT CHECK(status IN ('active','done','archived')),
    due_date TIMESTAMP,
    priority INTEGER DEFAULT 0 CHECK(priority IN (-1, 0, 1)),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_notes_status ON notes(status);
CREATE INDEX idx_notes_due ON notes(due_date);
CREATE INDEX idx_notes_priority ON notes(priority);
CREATE INDEX idx_notes_category ON notes(category);

5.2 Příkazy /todo

Příkaz	Akce	Ekvivalent v /note
todo add "text" [--cat] [--priority] [--due]	Vytvoří aktivní úkol	note add "text" --status active
todo list [--cat] [--all]	Seznam aktivních	note list --status active
todo done <id>	Označí hotové	note edit <id> --status done
todo undo <id>	Vrátí do aktivních	note edit <id> --status active
todo delete <id>	Smaže	note delete <id>
todo search <query>	Fulltext	note search <query> --status active

5.3 Proč thin wrapper místo vlastního skriptu?

• Jedna codebase: Bugfix v note.py se projeví v obou skillech
• Jedna migrace: Když se změní schéma, stačí jeden skript
• Konzistence: todo search najde i poznámky, pokud uživatel chce
• Jednoduchost: /todo SKILL.md je ~50 řádek, žádný Python kód

---

6. Srovnání variant

Kritérium	A: Monolit	B: Orchestrace	C: Konvergence	D: Samostatný
Jednotné UI	✅	⚠️ magie	✅ /note+/todo	❌
Jednotný storage	✅	❌	✅	❌
Zachová /remind cron	❌	✅	✅	✅
Minimální změna existujícího	❌	✅	✅	✅
Žádná duplicita kódu	✅	❌	✅	❌
Postupná migrace	❌	✅	✅	✅
Uživatel se učí 1 command	✅	❌	⚠️ 2 (/note, /todo)	❌
Spolehlivost	⚠️ komplex	❌ LLM klasifikace	✅	✅

---

7. Konkrétní doporučení

Implementuj variantu C s /todo jako thin wrapper nad /note.

Kroky:

1. Rozšířit note.py:

   • Přidat status, due_date, priority do schématu (s migrací existující DB)
   • Přidat --status, --due, --priority do add a edit
   • Přidat --status, --due-before, --priority do list
   • Upravit výstup list — pro status != NULL zobrazit [ ] / [x] prefix

2. Vytvořit /todo skill:

   • SKILL.md s příkazy, které volají note.py s přednastavenými parametry
   • Žádný vlastní Python kód (nebo minimální wrapper skript)
   • todo add → note add --status active
   • todo list → note list --status active --sort priority,due_date
   • todo done → note edit --status done

3. Deprecate /keep:

   • Přidat do /note podporu pro --cat keep
   • Volitelně: import skript pro keep.md
   • /keep SKILL.md upravit na aliasy

4. Ponechat /remind nezměněný:

   • YAML + cron je technicky odůvodněný
   • Později: integrační bod — /remind může číst z note DB

Příklad použití po implementaci:

# Rychlá poznámka
> note add "Ollama limit 5h" --cat knowledge

# Úkol bez deadlinu
> todo add "refactor auth module" --priority high

# Úkol s deadlinem (bez notifikace)
> todo add "odeslat fakturu" --due 2026-06-10 --priority high

# Připomínka s notifikací
> remind add "odeslat fakturu" at 2026-06-10T09:00

# Seznam všech aktivních úkolů
> todo list
[ ] #12 refactor auth module [high]
[ ] #15 odeslat fakturu [high] due: 2026-06-10

# Seznam všech poznámek a úkolů
> note list --cat knowledge
#7  Ollama limit 5h [knowledge]

# Hotovo
> todo done 12

# Hledání přes všechno
> note search "faktura"
#15 [active] odeslat fakturu

---

8. Rizika a mitigace

Riziko	Mitigace
Migrace existující note DB	note.py musí detekovat staré schéma a přidat sloupce automaticky
/todo jako wrapper je "podvod"	Dokumentovat v SKILL.md — uživatel chápe, že /todo je pohled na /note
Uživatel ztratí přehled co kam dát	Jasné pravidlo: potřebuješ notifikaci? → /remind. Úkol bez notifikace? → /todo. Čistá informace? → /note.
/keep uživatelé ztratí data	Import skript + /keep zůstane read-only dočasně

---

9. Závěr

Nejlepší cesta je konvergence, ne monolit.

• /note se stane univerzálním storage pro všechny "item" typy (poznámky, úkoly, keep)
• /todo je pohled (view) na /note — uživatelsky přívětivý, technicky tenký
• /remind zůstane samostatný kvůli cron architektuře
• /keep se postupně absorbuje do /note --cat keep

Toto dává:

• Jednotný storage (SQLite)
• Jednu codebase na CRUD (note.py)
• Specializované UI pro každý use case (/note, /todo, /remind)
• Postupnou migraci bez big-bang
• Technickou správnost (cron zůstává mimo LLM agenta)