Paweł Domański
14 KiB
title, source, author, published, created, description, tags
| title | source | author | published | created | description | tags | ||
|---|---|---|---|---|---|---|---|---|
| Budowanie osobistego asystenta AI z użyciem SQLite, Claude Code i GTD | https://medium.com/@marc.bara.iniesta/building-a-personal-ai-assistant-with-sqlite-claude-code-and-gtd-0ae12dc18d3e |
|
2026-03-14 | 2026-06-02 | Zmęczyło mnie klikanie. Teraz rozmawiam z moją listą zadań. |
|
Zmęczyło mnie klikanie. Teraz rozmawiam z moją listą zadań.
Asystent AI mieści się w folderze Dropbox. Jedna baza danych, jeden plik HTML, jeden CLAUDE.md kontrakt.
Agenci AI sprawili, że stałem się leniwy. Po tygodniach obserwowania, jak Claude Code czyta bazy kodu, odwołuje się do dokumentów i wykonuje wieloetapowe zadania na podstawie jednego zdania, nie mogę już znieść klikania po tablicy Notion, by sprawdzić, ile jestem winien klientowi w tym tygodniu. Chcę powiedzieć "co obiecałem temu klientowi w zeszłym tygodniu" i uzyskać odpowiedź od kogoś, kto zna moje projekty, kalendarz i priorytety. Notion ma API, tak. Ale nie chcę pisać wywołań API, które będą komunikować się z moją własną listą zadań. Chcę porozmawiać z moją listą zadań. Na przykład tak:
> what did I promise the training client last week?
You committed to delivering the updated course outline by Friday March 14.
Task status: to_do, assigned to project "PM Training 2026".
No due date set. You have a meeting with them on Thursday at 10:00.
Want me to set the due date to Wednesday and block two hours tomorrow?
Tak właśnie powstał MarcOS. Na razie jest to osobisty asystent. Jeśli kiedykolwiek zacznie prowadzić moje zajęcia i wysyłać faktury bez pytania, stanie się moim klonem i wtedy nie będzie jasne, który z nas jest zbędny. Obecnie powtarza się teza, że SaaS umarł, że agenci AI zastąpią całe kategorie produktów. Po piętnastu latach zmiany narzędzi produktywności na coś lepszego, z Notion jako najnowszym przystankiem (martwe knowledge, kolekcje linków, do których nigdy nie wracam, 140 osieroconych pomysłów w bazie danych, której przestałem przeglądać), postanowiłem przetestować tę pracę na sobie.
Szukałem, jak wyglądałby osobisty system GTD, gdybym zbudował go od zera, korzystając z narzędzi dostępnych w 2026 roku. GTD (Getting Things Done, metoda Davida Allena) sprowadza się do: uchwycenia wszystkiego, wyjaśnienia, czym jest każda rzecz, uporządkowania według projektu, przeglądu co tydzień i działania. Metoda ta ma już czterdzieści lat. Narzędzia, których ludzie używają do prowadzenia, zmieniają się co trzy lata. Nie prototyp. To nie weekendowy hack. System, którego faktycznie używałem codziennie do prowadzenia praktyki konsultingowej, koordynowania kursów w kilku szkołach biznesu, zarządzania mentoringiem startupów oraz śledzenia faktur. Ograniczenie było proste: każdy element musi być wymienny, nic nie wymaga subskrypcji, a całość musi działać bez połączenia z internetem, poza synchronizacją. Rdzeń działał w tydzień. Dashboard i automatyzacje wymagały jeszcze kilku sesji. Oto jak to działa.
Stos
Rdzeń to baza danych SQLite w folderze Dropbox. Jeden plik,, zawierający cztery stoły: klienci, projekty, zadania i faktury. Ścisła hierarchia, w której każde zadanie należy do projektu, a każdy projekt do klienta, bez wyjątków.gtd.db
Klient nigdy nie jest przechowywany w zadaniach ani fakturach: pochodzi z projektu przez JOIN. Pomysły to zadania o statusie. Zadania przechwycone z e-maila zachowują oryginalny tekst w kontekście dla kontekstu.someday email_source
Pomysły żyją jako zadania o statusie wewnątrz hierarchii, a nie w osobnej tabeli, ponieważ już próbowałem podejścia z oddzielnymi tabelami w Notion i obserwowałem, jak pomysły przez miesiące gniją na rozłączonej liście.someday
Interfejs dzienny to plik HTML, który odczytuje bazę danych bezpośrednio w przeglądarce za pomocą sql.js (SQLite skompilowany do WebAssembly). Trzy widoki: dziś (oś czasu z wydarzeniami w kalendarzu przeplatanymi kolejnymi akcjami), tydzień (siedem kolumn z terminami i obciążeniem) oraz GTD (skrzynka odbiorcza, kolejne akcje według projektu, oczekiwanie z upływem dni, aktywne projekty z postępem). Brak serwera, brak tokenów, brak wywołań API. Otwórz plik, zobacz wszystko.
Kod Claude'a wchodzi wtedy, gdy potrzebuję informacji, a nie gdy muszę sprawdzać listę. Claude Code to narzędzie do kodowania agentycznego Anthropic: działa w terminalu, odczytuje i zapisuje pliki, wykonuje skrypty oraz tłumaczy cały twój folder projektu. Pomyśl o tym jak o programisty, który widzi cały twój system i rozmawia z tobą o nim. Jeśli jutro pojawi się lepszy agent (Codex CLI od OpenAI lub cokolwiek następnego), migracja jest CLAUDE.md przepisania, bo warstwa danych to tylko SQLite i pliki. Zinterpretuj przekazany e-mail i stwórz odpowiednie zadania. Porównaj to, co klient obiecał w mailu, z tym, co faktycznie jest planowane. Wygeneruj fakturę w formacie PDF. Przygotuj cotygodniową recenzję. Zbuduj nowy skrypt automatyzacji, który potem działa samodzielnie bez tokenów. Schemat jest taki: Claude Code buduje maszynę, maszyna działa za darmo.
Reszta stosu to infrastruktura: Dropbox do synchronizacji między laptopami, GitHub do kopii zapasowych i wersjonowania. Sama baza danych jest dostępna, ponieważ pliki SQLite są binarne i Git nie może ich differować. Zamiast tego wersjonowany jest SQL w formie zwykłego tekstu: czytelny, zróżnicowany, lekki. Skrypt wsadowy w Windows Task Scheduler zrzutuje, zatwierdza i wypycha co godzinę, gdy blokuję ekran. Jeśli nie jestem przy laptopie, GitHub Codespaces daje mi dostęp do tego samego repozytorium przez przeglądarkę..gitignore
Struktura teczek jest celowo płaska:
gtd/ ← Dropbox folder, GitHub repo
├── CLAUDE.md ← contract for the agent
├── memory.md ← what Claude Code learns about me
├── decisions.md ← design decisions with date and reason
├── log.md ← significant changes
├── gtd.db ← SQLite (in .gitignore)
├── gtd.sql ← SQL dump, versioned in Git
├── index.html ← local dashboard
├── inbox/ ← parsed emails (JSONs + attachments)
├── attachments/ ← task attachments, referenced by path
├── notes/ ← free-form markdown
└── scripts/
├── process_inbox.py ← processes inbox/ without tokens
├── sync.bat ← dump + git commit + push
└── pull_calendar.py ← morning calendar snapshot
Przechwytywanie e-maili zasługuje na własne wyjaśnienie. Tok jest następujący: widzę w Outlooku e-mail, który wymaga działania, przekieruję go na dedykowany adres Gmail, Cloudflare Worker go analizuje i wrzuca JSON wraz z załącznikami do folderu przez API Dropbox. Gdy otwieram laptopa, odczytuje JSON, tworzy zadania w bazie danych, przenosi załączniki do, i usuwa przetworzone pliki. Cały łańcuch działa bez żetonów. Na około 10 maili dziennie, które trzeba uchwycić, to jest więcej niż wystarczająco. W przypadku okazjonalnych niejasnych lub złożonych e-maili proszę Claude Code o przetworzenie skrzynki odbiorczej i pozwolenie mu podjąć decyzję.inbox/ process_inbox.py attachments/
Całkowity miesięczny koszt: zero przyrostów. Dropbox już istniał, GitHub darmowy tier, Cloudflare free tier dla pracowników mailowych. Jedynym nowym kosztem jest subskrypcja Claude, którą już płacę za inne prace.
Decyzje projektowe, które miały znaczenie
Hierarchia była najważniejsza. Puryści GTD mogą sprzeciwiać się zmuszaniu każdego zadania do projektu, a każdego do klienta. Luźne zadania wydają się bardziej zwinne. Ale zarządzam projektami od ponad 20 lat i wiem, co się dzieje z zadaniami bez domu: nagromadzają się, tracą kontekst i nikt ich nie przegląda. Zadanie należące do projektu, który należy do klienta, zawsze można znaleźć, zapytać i zgłosić. Zadanie unoszące się w skrzynce odbiorczej nie może. W przypadku naprawdę osobistych rzeczy klient o nazwie "Personal" z projektami takimi jak "Household" sprawdza się dobrze.
Podział między lokalnym HTML a kodem Claude był decyzją, która ukształtowała wszystko inne. Każda operacja, którą wykonuję więcej niż raz dziennie, nie powinna kosztować żadnych tokenów. Sprawdzam kolejne kroki, patrzę na dzisiejszy harmonogram, przetwarzam e-maile z folderu w skrzynce: wszystko to działa lokalnie za pomocą skryptów lub panelu HTML. Claude Code obsługuje to, czego skrypty nie potrafią: rozumienie języka naturalnego, podejmowanie decyzji, zapytania do bazy danych w sposób, którego się nie spodziewałem, tworząc dashboard, porównywanie zadań z mailami i notatkami, generowanie dokumentów. To nie jest optymalizacja kosztów. To decyzja architektoniczna. Jeśli polegam na API dla podstawowej widoczności zadań, zbudowałem gorszy Notion.
Kontrakt CLAUDE.md
Plik CLAUDE.md to miejsce, gdzie system staje się czymś więcej niż bazą danych z ładnym interfejsem. To umowa między mną a agentem, który działa na moich danych. Zawiera schemat, reguły hierarchii, strukturę pliku oraz ograniczenia behawioralne: aktualizację po poznaniu czegoś nowego o moich preferencjach, logowanie decyzji projektowych z datą i powodem, rejestrowanie istotnych zmian w.memory.md decisions.md log.md
Zawiera także cotygodniową listę kontrolną w formie czytelnej maszynowo. Status oczekiwań na zadania od ponad 7 dni: oznacz je. Kiedyś zadania nieprzejrzane w ciągu 30 dni: oznacz je. Aktywne projekty bez określonego następnego działania: oznacz je. Faktury zawieszone na ponad 30 dni: oznacz je. Dokumenty niezaktualizowane w ciągu 90 dni: proponuję archiwizację. To nie jest pytanie, które piszę co piątek. To stała instrukcja, którą Claude Code wykonuje na bazie danych za każdym razem, gdy powiem "cotygodniowy przegląd", tworząc uporządkowane podsumowanie, na które mogę zareagować w ciągu 15 minut.invoiced
Plik pamięci zasługuje na osobną wzmiankę. Sesje Claude Code są bezstanowe. Każda rozmowa zaczyna się od zera. Ale trwa przez sesje, ponieważ znajduje się w repozytorium. Kiedy Claude Code dowiaduje się, że wolę faktury w określonym formacie, albo że konkretny klient zawsze płaci z opóźnieniem, albo że nigdy nie umawiam pracy na środowe popołudnia, bo odbiorę córkę, zapisuje to na pamięć. Na następnej sesji czytamy to. Przez tygodnie system gromadzi wiedzę operacyjną, której generyczne narzędzie SaaS nie ma mechanizmu do przechwycenia.memory.md
Znane słabe punkty
Integracja z Google Calendar jest najbardziej delikatnym elementem i najbardziej ambitnym. Cel jest dwukierunkowy: wydarzenia kalendarzowe trafiają do pulpitu, dzięki czemu mogę zobaczyć swój dzień, ale Claude Code też może się odpierać. "Stwórz zadania przygotowawcze na każde spotkanie w tym tygodniu." "Zablokuj dwie godziny na ten zadanie, znajdź lukę." "Czy mam w tym tygodniu spotkania, na które nie mam żadnych zadań?" CLAUDE.md zawiera ograniczenia, które Claude Code musi przestrzegać: niektóre popołudnia są przeznaczone dla rodziny, a niektóre poranki na intensywną pracę. Planuje wokół nich, nie przez nie.
Pragmatyczna pierwsza wersja pomija kalendarz czasu rzeczywistego w panelu HTML Dashboard. Każdego ranka uruchamia się skrypt, pobiera wydarzenia dnia przez API kalendarza, zapisuje je do pliku JSON, a HTML odczytuje ten dokument. Nieeleganckie. Funkcjonalny. Dwukierunkowe zapisy (blokowanie czasu, tworzenie zdarzeń) przechodzą bezpośrednio przez kod Claude przez MCP lub API, które teraz działa, ale zależy od świeżości tokenów OAuth.
Workflow SQL dump będzie się kumulował. Co godzinę pełny zrzut bazy danych trafia do pliku tekstowego, który jest wersjonowany w Gicie. Przy tysiącach zadań przez miesiące ten plik się powiększa. Łagodzenie jest proste: zrzucać tylko aktywne dane (wykluczać ukończone i anulowane) lub przejść na zatwierdzenia inkrementalne. Ale to znany punkt konserwacji, co nie jest zaskoczeniem.
Największe ryzyko nie jest techniczne. To dyscyplina. Ten system działa, jeśli codziennie przetwarzam skrzynkę odbiorczą, robię cotygodniową kontrolę i utrzymuję czystość hierarchii. Zakład jest taki, że utrzymywanie go za pomocą naturalnego języka ("przetwarzanie skrzynki odbiorczej", "przeprowadzenie cotygodniowej recenzji", "jakie projekty nie mają kolejnej akcji") zmniejsza tarcie na tyle, że faktycznie to zrobię. Każdy poprzedni system wymagał klikania, przeciągania, filtrowania i nawigacji. To wymaga ode mnie mówienia.
Plan awaryjny to cron-kronik GitHub Actions. W każdy piątek o 9 rano workflow odczytuje zrzut SQL, uruchamia zapytania do przeglądu i wysyła mi maila z wynikami. Nie wymaga, żeby mój laptop był włączony. Nie wymaga ode mnie pamiętania. Działa, czy mam na to ochotę, czy nie.
Co będzie dalej
Może tak właśnie wyglądają osobisti asystenci w pracy: nie kolejny SaaS z listą oczekujących, ale lokalna baza danych, agent, który ją czyta, i rozmowa zastępująca interfejs. Nie generowanie aplikacji demonstracyjnych, nie rozwiązywanie zagadek Advent of Code, ale wykonywanie żmudnej, nieefektownej pracy zarządzania zadaniami, śledzenia faktur i przypominania konsultantowi, że nie przeglądał swojej listy "someday" od pięciu tygodni. MarcOS się narodził. Czy stanie się lepszym klonem, czas pokaże. Będę aktualizować ten artykuł, gdy tylko pojawią się dane.
Marc Bara jest konsultantem ds. zarządzania projektami i edukatorem z doktoratem z inżynierii elektrycznej. Pisze o AI, pracy i zarządzaniu projektami. Znajdź go na LinkedIn.