TL;DR
Mam vault w Obsidianie, w którym chcę, żeby Claude Code umiał czytać i pisać. Nie jako kolejne narzędzie do notatek — jako spoiwo między tym, co już mam: NotebookLM (research), Linear (issues), voice-inbox (głos → tekst). Plan: obsidian-mcp-server + trzy konkretne hooki/skille. To jest stan „wiem co chcę, robię to w małych krokach”, nie „zrobiłem, działa produkcyjnie”.
Kontekst
Prowadzę 30+ projektów klienckich jako freelancer. Notes były rozsypane: trochę w iOS Notes, trochę w Apple Reminders, trochę w Linear jako descriptions, trochę w markdown w repo projektu. Konsekwencja: co drugi dzień przeszukuję gdzie to było, zamiast pracować.
Vault w Obsidianie założyłem tydzień temu z prostą strukturą:
00-Daily/ # capture bufor, timestampy — tu wpada wszystko z głowy
10-Projects/ # aktywny projekt = MOC (Map of Content)
20-Learning/ # notatki techniczne, AHA-moments
30-Resources/ # linki, PDF-y, reference
90-Meta/ # templatesFlow: capture ląduje w daily note → weekly review (piątek) przesiewa → Projects/Learning zyskuje strukturę.
Na razie mam 8 notatek. Cały system testuję „na sobie”. Dopiero jak się okaże że ta architektura mi pasuje, wchodzi automacja.
Dlaczego nie same notatki + CC w terminalu
Bo tracę kontekst. Claude Code w terminalu nie wie co napisałem wczoraj w daily note. Nie przeczyta project MOC, żeby zorientować się w stanie projektu. A ja nie chcę za każdym razem wklejać mu 500 linijek kontekstu.
Vault powinien być stanem, który CC czyta jak bazę danych. Zapisałem „klient X chce feature Y do końca tygodnia, blokerem jest auth” — następnej sesji CC to wie, bez mojego kopiowania.
Plan: trzy integracje
1. obsidian-mcp-server — read/write do vaulta
cyanheads/obsidian-mcp-server to MCP server (nieoficjalny, aktywny), który wystawia vault jako tools dla CC: read_note, write_note, list_notes, search. Wymaga zainstalowania w Obsidianie pluginu Local REST API (oficjalny, core community plugin) i wrzucenia config do ~/.claude/claude_desktop_config.json.
Co to daje: – „Zobacz co mam w 10-Projects/stroniarz-pl.md, dopisz sekcję z dzisiejszego commita.” – „Znajdź wszystkie notatki z tagiem #blocker i zrób mi z nich tabelę.” – „Dopisz do dziennika pod dzisiejszą datą: deploy voice-inboxa na żywo, działa.”
Status: zbadane, plugin do zainstalowania, config do napisania. Nie uruchomione jeszcze — bo najpierw chcę mieć co pisać (patrz punkt 2 i 3), a dopiero potem jak.
2. Voice-inbox → daily note (automatycznie)
Mój voice-inbox (lokalna appka, głos → tekst, PWA na iPhonie) już nagrywa dyktafony. Dziś ląduje w logu aplikacji i znika.
Plan: każdy voice capture z PWA leci POST-em na lokalny endpoint → CC (przez MCP) appenduje do dzisiejszego 00-Daily/2026-04-24.md pod sekcją ## Głos:
## Głos
- 08:12 — pomyśl o tym, żeby rozdzielić voice-inbox na dwa serwisy
- 08:45 — klient Kowalski, przypomnij się w piątek w sprawie faktury
- 11:03 — pomysł na wpis: dlaczego używam single-file skryptów zamiast PythonaKażda bullet to linkowalny atom. W weekly review decyduję: wyrzucam, przekierowuję do Projects (klient Kowalski → jego MOC), przenoszę do ideas.
3. Auto-Log z Linear przy zamknięciu issue
Linear MCP już pouszczam z CC (używam codziennie do search/update issue). Brakuje jednej rzeczy: gdy zamykam issue, chcę żeby do project MOC automatycznie trafiły 2-3 zdania podsumowania — co zrobiłem, dlaczego to było ważne, co to odblokowało.
Flow: hook reagujący na Linear webhook → CC czyta issue + powiązane komentarze → pisze 2-3 zdania → appenduje do sekcji ## Log w odpowiednim MOC-u w 10-Projects/.
To jest rzecz, której nie dostanę kupując oprogramowanie. Jest zbyt specyficzna dla mojego flow. Dlatego CC, nie Zapier — koszt napisania 50 linijek skillu jest mniejszy niż koszt utrzymywania automacji w zewnętrznej platformie.
Dlaczego w tej kolejności
Klasyczny błąd: zacząć od najbardziej „AI” fragmentu (tu: Log z Linear). Zrobić skill w weekend. Okazać się, że nie ma co logować, bo nie zamykam dużo issue. Skill leży, motywacja znika.
Dlatego zacznę od (2) — voice capture → daily note. Dlaczego: – Częstotliwość: 5-10 dyktafonów dziennie. Będę widział efekt natychmiast. – Niski ryzyk: jak zawali, daily note ma pustą sekcję. Nic się nie zepsuje. – Uczy mnie vaulta: zmusi mnie do weekly review, bo bez review 00-Daily/ się zapcha.
Punkt (1) — MCP server — jest warunkiem koniecznym dla (2) i (3), więc idzie równolegle.
Punkt (3) — Log z Linear — dopiero gdy mam zaufanie do MCP pipeline’u i mam ustabilizowany flow.
Czego nie robię
- Nie przenoszę do vaulta wszystkiego naraz. Iwan-Grozny import z Apple Notes to obietnica bez wartości. Przenoszę notatkę wtedy, kiedy jej potrzebuję — i zostawiam w vault.
- Nie używam AI-generowanych notatek jako głównego contentu. CC może summaryzować, taggować, łączyć. Ale pisanie notatki to moja robota — bo to pisanie mnie uczy.
- Nie pakuję wszystkiego w jeden mega-skill. Trzy osobne hooki, każdy jedno zadanie. Łatwiej debuggować.
Co mnie zastanawia (uczciwie)
- Sync między urządzeniami: vault trzymam w iCloud Drive. Obsidian Sync kosztuje, iCloud jest free. Ale iCloud czasem lubi się zamulić. Jeśli będę pisał do vaulta z CC na Macu i równolegle edytował z Obsidian mobile na iPhonie, obstawiam że prędzej czy później trafię na konflikt. Plan B: Obsidian Sync albo Git-based vault.
- Privacy:
obsidian-mcp-serverdziała lokalnie, ale CC w trakcie sesji może wysyłać fragmenty notatek do Anthropic. Nie trzymam tam cudzych tajemnic, ale warto świadomie odfiltrować katalogi które mają trafić do AI od tych, które nie mają. - Granica między „capture” a „to-do”: voice capture „klient Kowalski, przypomnij się w piątek” to powinno być Reminder, nie notatka. Nie wymyśliłem jeszcze jak wygodnie decydować, co ląduje gdzie. Może kolejny skill — klasyfikator capture.
Linki
- cyanheads/obsidian-mcp-server — nieoficjalny MCP do Obsidiana
- Local REST API — wymagany plugin w Obsidianie
- voice-inbox — moja lokalna głosówka
Będzie follow-up, jak pierwszy pipeline (voice → daily note) pójdzie na żywo. Ile by to nie miało zająć — miesiąc, trzy.