Claude Code dla product managerów: research, pisanie, kontekst i własny system zadań #EN372

Notatka od autora: Poniższy tekst stanowi zbiór notatek sporządzonych na podstawie rozmowy Claire Vo z Teresą Torres w podcaście How I AI. Wszystkie przedstawione tu metody, opinie i strategie pochodzą od rozmówczyni. Listy kontrolne, biblioteka poleceń oraz kluczowy wniosek na końcu artykułu to moja interpretacja na podstawie informacji z rozmowy.

TL;DR

• Partnerstwo z AI – Torres traktuje Claude Code jako partnera, który wspiera ją nie tylko w kodowaniu, ale również w organizacji pracy, analizie badań i redakcji tekstów.
• Lokalność danych – System zadań został przeniesiony z Trello do plików markdown w Obsidian, co eliminuje uzależnienie od zewnętrznych dostawców i daje pełną kontrolę nad danymi.
• Automatyzacja poranka – Polecenie /today automatycznie generuje codzienną listę zadań, agreguje zaległe pozycje i dostarcza przegląd badań każdego ranka.
• Inteligentny research – Skrypty Python przeszukują arXiv i Google Scholar, a Claude tworzy szczegółowe podsumowania wybranych PDF-ów z naciskiem na metodologię i wielkość efektu.
• Architektura kontekstu – Filozofia małych plików kontekstowych zakłada rezygnację z jednego wielkiego Claude.md na rzecz dziesiątek wyspecjalizowanych plików z mapą indeksową, które Claude ładuje selektywnie.
• Wsparcie, nie automatyzacja – Claude działa jako partner w pisaniu, który nie pisze za Torres, lecz krytykuje szkice według szczegółowego przewodnika stylistycznego, weryfikuje fakty w czasie rzeczywistym i poprawia błędy.
• Przewaga czasowa – Dzięki systemowi Torres zdążyła przeanalizować badanie o purchase intent dzień przed jego rozpowszechnieniem przez Ethana Mollicka na LinkedIn, co pozwoliło jej opublikować krytyczną recenzję jako jednej z pierwszych.

Wstęp

Teresa Torres, autorka książki „Continuous Discovery Habits” i uznany głos w świecie zarządzania produktem, zbudowała system produktywności, który może wydawać się ekstremalny. Cały proces zarządzania zadaniami, researchu akademickiego i pisania prowadzi przez terminal. Bez interfejsów graficznych, bez klikania w kalendarze czy etykiety. Tylko tekst, markdown i Claude Code jako stały partner pracy.

W podcaście How I AI Torres pokazuje ewolucję od standardowych narzędzi SaaS do systemu opartego na lokalnych plikach, automatyzacji i inteligentnym zarządzaniu kontekstem. Jednak to nie jest opowieść o zastąpieniu człowieka przez AI. Torres opisuje sposób zaprojektowania współpracy z LLM, który pozwala być oszczędnym w formułowaniu poleceń, a jednocześnie skutecznym w działaniu.

Jej strategia opiera się na inżynieryjnym koncepcie programowania w parach (pair programming), który zaadaptowała do zarządzania codziennymi obowiązkami, procesu pisania oraz analizy badań naukowych. Skoro inżynierowie mogą pair programmować z Claude, Torres prowadzi wspólne zarządzanie zadaniami, wspólnie pisze, wspólnie robi wszystko.

Od Trello do terminala: ewolucja systemu zadań

Torres rozpoczęła swoją podróż podobnie jak większość użytkowników AI. ChatGPT w przeglądarce, notatki w Trello, standardowy zestaw narzędzi. Z czasem jednak zaczęła myśleć długoterminowo i pojawiło się kluczowe pytanie: jak wydobyć swoje dane z Trello za pięć lat? Co się stanie, jeśli narzędzie zmieni politykę cenową albo po prostu przestanie istnieć?

Głównym problemem okazało się „uwięzienie” notatek w systemach SaaS – vendor lock-in. Dane były zamknięte w GUI, którego Torres nie kontrolowała. Niemożliwe do przeszukania przez AI, nieosiągalne w elastyczny sposób, uwięzione w cudzym formacie.

Przejście na Claude rozpoczęło się od potrzeby lepszego wsparcia w pisaniu. Torres wybrała Claude jako nieco lepszego writera niż ChatGPT. Następnie przyszedł czas na programowanie, choć początkowo nie było to oczywiste. Przez cztery lata mąż przekonywał ją, żeby zaczęła używać IDE zamiast pisać kod bezpośrednio w konsoli AWS. Torres przyznaje otwarcie, że była afraid of IDE. Nie miała nawet version control, a kod pisała w konsoli zarządzania AWS.

Dopiero projekt wymagający prawdziwej kontroli wersji i integracji z produkcyjnym systemem zmusił ją do VS Code i Git. Jak sama to ujmuje, musiała awansować swoją grę w udawanie inżyniera. W VS Code odkryła Claude Code – terminal zintegrowany bezpośrednio w edytorze. Możliwość pair programmingu z AI otworzyła jej oczy na zupełnie nowe podejście.

Torres zauważyła coś fundamentalnego: skoro inżynierowie mogą pair programmować z Claude, dlaczego ona nie miałaby prowadzić wspólnego zarządzania zadaniami, wspólnie pisać, wspólnie robić wszystko? To spostrzeżenie stało się punktem zwrotnym w jej sposobie pracy.

Decydujący moment przyszedł wraz z refleksją nad notatkami. Skoro zapisuje je w narzędziu do zadań, a narzędzie trzyma dane w zamkniętym ekosystemie, może Claude pomoże rozwiązać ten problem? Może istnieje lepszy sposób? Torres zaczęła też zadawać sobie przy każdym zadaniu fundamentalne pytanie: w jaki sposób AI może w tym pomóc? Czy może to zautomatyzować? Czy może to wesprzeć? Czy w ogóle lubię to robić? Czy wolę, żeby AI zrobiło to za mnie?

Anatomia osobistego systemu zadań

System Torres opiera się na jednym poleceniu: /today. Każdego ranka, z kubkiem kawy w ręku, wpisuje tę komendę w Claude Code. Nawet w weekendy. Slash command to po prostu skrót w Claude Code, który można samodzielnie zdefiniować. W jej przypadku Torres napisała bardzo szczegółowe polecenie określające dokładnie, co Claude ma wykonać.

Po wywołaniu /today dzieje się następująco:

• System sprawdza tablicę w Trello (używaną do koordynacji z zespołem) i szuka nowych kart do zaimportowania
• Przeszukuje folder Tasks zawierający pliki markdown
• Wydobywa wszystkie zadania z terminem wykonania na dziś
• Zbiera zaległe zadania, które mogą wisieć od dni, tygodni, czasem miesięcy
• Dodaje Ideas in Progress – długoterminowe projekty bez konkretnego terminu
• Generuje przegląd badań
• Tworzy jeden plik markdown w Obsidian z kompletną listą

Struktura pojedynczego zadania jest prosta. Torres wykorzystuje front matter – koncept Obsidian będący po prostu zestawieniem pól i wartości w formacie YAML. Każde zadanie zawiera type (task), due date i etykiety. Pod tym znajduje się właściwa treść – notatki, kontekst, wszystko związane z danym zadaniem.

---
type: task
due_date: 2025-01-20
tags: [sales, urgent]
---

[Treść zadania i notatki kontekstowe]

Torres podkreśla, że wszystkie notatki zapisuje bezpośrednio w pliku zadania. Jeśli w trakcie pracy nad kursem znajdzie błąd, loguje go w tym samym pliku markdown. Następnego dnia, gdy wraca do zadania, wystarczy jedno pytanie do Claude: „Gdzie zalogowałam tego błędu?”.

Wyszukiwanie stanowi prawdziwą supersiłę systemu. Trello, podobnie jak większość narzędzi GUI, posiada słabą funkcję wyszukiwania kontekstu wewnątrz zadań. Tymczasem Claude próbuje każdej permutacji zapytania. Torres podaje konkretny przykład wyszukiwania rozmytego (fuzzy search): pyta o „task New Blog Post Tomorrow”. Claude odpowiada: „Nie widzę nic o New Blog Post Tomorrow, ale masz Article Wednesday. To tego szukasz?”. I to dokładnie to, czego szukała. Nawet jeśli Torres pamięta słowa źle, Claude radzi sobie z niedoskonałością ludzkiej pamięci.

Tworzenie nowego zadania przebiega równie naturalnie. Wystarczy wpisać w terminalu: „New task: send thank you to Claire. How I AI was a blast.” Claude rozumie intencję. Tworzy plik markdown w folderze Tasks, ustawia termin wykonania na dziś, dodaje odpowiednie etykiety i aktualizuje plik Today. Zero klikania w GUI, zero wybierania z list rozwijanych. Tylko tekst.

Torres ma już skonfigurowany Trello MCP server, ale przyznaje, że nie lubi już tworzyć zadań w Trello. Podczas nagrania podcastu demonstrowała tworzenie zadania na żywo. Claude początkowo próbował automatycznie zaktualizować plik Today, ale Torres przerwała proces. Preferuje ręczne dodanie, ponieważ automatyczna aktualizacja usunęłaby wszystkie pola wyboru, a lubi poczucie, że wykonała swoje zadania.

Torres przyznaje, że brzmi to banalnie, jednak szybkość ma znaczenie. Nie musi otwierać przeglądarki ani klikać przez czternaście przycisków w ciągle zmieniającym się interfejsie. Nie musi walczyć z kalendarzem. Zapisuje myśl w Claude i wraca do pracy. Okno z zadaniami pozostaje zawsze otwarte, a drugie okno Claude Code dedykowane jest bieżącemu projektowi.

Etykietowanie i dynamiczne widoki:

System pozwala na zadawanie pytań typu: „Claude, jaki jest teraz mój sales pipeline?” Ponieważ Claude automatycznie dodaje etykiety do zadań, może wygenerować listę wszystkich zadań sprzedażowych wraz z ich statusem na bieżąco. W większości narzędzi do zarządzania zadaniami użytkownik jest ograniczony do widoków zaprojektowanych przez twórców aplikacji. Można używać etykiet, ale kto naprawdę ręcznie dodaje je do zadań? Torres jest optymistką, że będzie, ale w praktyce nigdy tego nie robi. W jej systemie Claude zajmuje się całym etykietowaniem. Za każdym razem gdy generuje zadanie, zastanawia się nad odpowiednimi etykietami.

W Claude.md dla tego projektu (nie w globalnym pliku!) Torres przechowuje taksonomię używanych etykiet i zarządza nią wspólnie z Claude. To forma współtworzenia.

Dlaczego Obsidian w tym układzie? Torres nie była zaawansowanym użytkownikiem przed wdrożeniem tego systemu. Cofając się o sześć czy osiem miesięcy wstecz, nie czuła się nawet komfortowo z markdown-em. Dlatego Obsidian daje jej trzy kluczowe rzeczy: taktylne pola wyboru (lubi klikać, choć X-owanie w markdown też działa), przeglądarkę plików po lewej stronie oraz zunifikowany dostęp do wszystkich plików. Jej vault jest ustawiony na poziom wyższym niż Tasks – zawiera kontekst LLM, notatki ze wszystkich obszarów, pliki podcastowe, badania, umiejętności i pisanie. Wszystko w markdown, więc wszystko dostępne dla Claude.

Przegląd badań: codzienne śniadanie z nauką

Torres ma aspiracje akademickie i chce śledzić badania w kilku obszarach: synthetic users, team collaboration, creativity, discovery skills, education oraz personas. Ma dostęp do biblioteki uniwersyteckiej, jednak nigdy nie znajduje dyscypliny do przeszukiwania baz danych. Jak sama przyznaje, nigdy nie ma w ciągu dnia momentu, gdzie myśli „och, jestem znudzona, powinnam to zrobić”.

Rozwiązanie polega na automatyzacji z zachowaniem ludzkiego filtra.

Dzienny przegląd badań funkcjonuje następująco:

1. Rano w pliku Today pojawia się lista wyników z arXiv
2. Torres przegląda tytuły przez pięć do dziesięciu minut
3. Pobiera PDF-y, które wyglądają interesująco
4. Zapisuje je do folderów tematycznych (źródła w /sources, notatki w /notes)
5. Następnego dnia otrzymuje szczegółowe podsumowania każdego pobranego PDF-a

Podsumowania nie są ogólnikowymi paragrafami „o czym jest artykuł”. Torres napisała własne polecenie z bardzo konkretnym skupieniem: metodologia i wielkość efektu. Musi pełnić rolę własnego redaktora, ponieważ arXiv to serwer preprintów – miejsce, gdzie obecnie większość artykułów naukowych (dzięki zmianom po Covid) publikowana jest przed oficjalną publikacją. Zaletą jest darmowy i szybki dostęp w czasie rzeczywistym. Wadą – brak redakcji. Trzeba samodzielnie filtrować jakość.

Podsumowania odpowiadają zatem na pytania: czy badanie było dobrze zaprojektowane? Jaka była wielkość efektu? Jakie metody użyto? Czy warto czytać głębiej?

Historia pokazująca wartość systemu:

Dzień po uruchomieniu przeglądu badań Torres przeglądała poranny przegląd. Zauważyła artykuł o purchase intent, więc przeczytała podsumowanie wygenerowane przez Claude. Dzięki formatowi skupiającemu się na metodologii od razu wychwyciła istotną wadę – badanie używało ankiety purchase intent, która nie stanowi wiarygodnej miary intencji zakupowej.

Następnego dnia Ethan Mollick udostępnił ten sam artykuł na LinkedIn. Torres już miała gotową analizę i opublikowała szczegółowy wpis wyjaśniający, dlaczego wyniki tego badania można zignorować. Przedstawiła bardzo krytyczną recenzję. Jak sama podkreśla, jedynym powodem, dla którego mogła to zrobić, był fakt posiadania tego systemu i wcześniejszej analizy właśnie opublikowanego artykułu. Wpis stał się jednym z jej najlepiej performujących tekstów na LinkedIn.

Infrastruktura składa się z dwóch skryptów Python. Pierwszy przeszukuje arXiv codziennie, a Google Scholar raz w tygodniu. Śledzi, które artykuły już widziano i które są nowe. Wykorzystuje plik konfiguracyjny z osobistymi słowami kluczowymi. Drugi skrypt uruchamia się wieczorem, skanuje katalogi źródłowe w folderach badawczych i szuka nowych PDF-ów. Tworzy listę zadań dla polecenia /today, a rano agenty Claude Code generują podsumowania, które trafiają do pliku Research Today. Oba skrypty uruchamiane są automatycznie przez zadania cykliczne (cron jobs).

Torres wyjaśnia, że jedyną częścią wymagającą rzeczywiście AI są podsumowania artykułów. Jednak bez AI w ogóle by tego nie zbudowała. Wyjaśniła Claude: „Oto czego chcę. Chcę codziennego wyszukiwania. Chcę przeglądu na mojej liście zadań. Jak to zrobimy?” Claude pomógł zaprojektować całą infrastrukturę.

Torres celowo nie automatyzuje pobierania PDF-ów. Nawet ręcznie wybierając artykuły do podsumowania, jak sama mówi, to już strumień informacji pod presją. Potrzebuje filtra. Pięć do dziesięciu minut dziennie na przeglądanie przeglądu i pobieranie to jej sposób filtrowania. Bez tego byłaby przytłoczona.

Repozytorium jest publiczne. Ma jednego użytkownika (Torres). Drugi będzie jej mąż. Jeśli ktoś chce być trzeci – używa na własne ryzyko. System nadal jest w fazie rozwoju.

Inne zastosowania przepływu pracy badawczej:

Torres napisała wpis na blogu zatytułowany „Claude Code: What is it? How it’s different and why non-technical people should use it”. W tym tekście pokazała scenariusz prowadzący kompletnego początkującego do „magicznego momentu”. Tym magicznym momentem było: do końca artykułu nauczysz się terminala i Claude Code, a Claude wygeneruje bardzo szczegółową analizę konkurencji dla dowolnych konkurentów z detaliczną tabelą porównania cen i funkcji. To typ zadań, w których Claude sprawdza się naprawdę dobrze – może odpytywać źródła, agregować dane i tworzyć raporty.

Torres zastanawia się nad podobnym systemem dla wpisów LinkedIn istotnych dla jej pracy. Chce brać udział w konwersacjach i komentować, jednak gdy loguje się do LinkedIn, jak sama przyznaje, ma ochotę wydłubać sobie oczy. Potrzebuje filtra, ale LinkedIn API sprawia, że jest to bardzo trudne.

Ogólnie rzecz biorąc, Torres używa Claude do wyszukiwania za siebie. Nie korzysta już z Google.

Mniej to więcej: filozofia zarządzania kontekstem

Torres odkryła coś, co wydaje się oczywiste dopiero po fakcie, ale wymaga doświadczenia: zbyt dużo irrelevantnego kontekstu jest równie szkodliwe jak za mało relevantnego kontekstu.

Początkowo wszystko wrzucała do Claude.md. Każdy szczegół o biznesie, produktach, stylu pisania, informacje osobiste. Problem w tym, że Claude ładuje Claude.md przy każdej interakcji. To niepotrzebne obciążenie, gdy Torres pyta, czy jej pies, który zjadł coś podejrzanego, jest bezpieczny. Claude nie potrzebuje znać jej kanałów marketingowych ani archiwum wpisów blogowych, by poinformować, że pies przeżyje.

Przełom nastąpił z uświadomieniem: kontekst trzeba dokumentować w małych, wyspecjalizowanych plikach.

Torres stworzyła folder LLM Context (czasem przełącza się między Claude a innymi modelami, stąd neutralna nazwa). W środku znajdują się dziesiątki plików. Nie powstały wszystkie naraz – budowane były stopniowo, w czasie. Tok pracy wygląda następująco: po zakończeniu sesji z Claude pyta „Co się dzisiaj nauczyłeś, co powinniśmy zapisać?”. Claude pisze pliki kontekstowe – to proces samodokumentacji AI, gdzie Claude robi to za Torres.

Pierwszy przykład: Przewodnik stylistyczny

Torres rozpoczęła eksperyment w interesujący sposób. Nie powiedziała Claude kim jest. Po prostu poprosiła: „Idź na Product Talk i powiedz mi, jaki według ciebie jest styl pisania autora, kto jest odbiorcą, jaka jest filozofia, jaki ton?”.

Claude przeszedł na jej blog, przeczytał zawartość i zaczął pisać. Torres spojrzała na wynik: „Tak, to jest w pewnym sensie prawidłowe. To nie do końca. Naprawmy to.” Nastąpiło współtworzenie.

Rezultatem jest bardzo długi dokument, którego Torres w ogóle nie pisała samodzielnie – Claude wykonał całą ciężką pracę. Zawiera sekcje o różnicach między stylem książkowym a blogowym, wytyczne dla nagłówków, podtytułów, kluczowe frazy do używania oraz listę zasad typu „nigdy nie rób tego, zawsze rób tamto i co to oznacza”.

Torres rzadko pozwala Claude pisać za siebie, natomiast Claude krytykuje każdy szkic. Dzięki szczegółowemu przewodnikowi stylistycznemu krytyka trafia w sedno – Claude zna cele, odbiorców i sposób pisania.

Przykładowa zawartość folderu LLM Context:

Business: przegląd firmy, kanały marketingowe, architektura treści, zasoby content, metryki, harmonogram publikacji, partnerstwa, produkty (każdy kurs w osobnym pliku).

Personal: profil osobisty, indywidualne zainteresowania.

Torres wyjaśnia kluczową różnicę: ma folder Business i folder Personal. Posiada Business Profile i Personal Profile. Dlatego gdy pyta o psa, Claude nie potrzebuje kontekstu biznesowego. Z kolei gdy pisze wpis blogowy o produkcie, nie potrzebuje szczegółów osobistych.

Pliki indeksowe jako mapa kontekstu:

Business Profile to nie monolityczny dokument, lecz spis treści: „Przegląd firmy jest tutaj. Szczegóły o kursach tutaj. Inne produkty tam”. W globalnym Claude.md znajduje się instrukcja: „Jeśli pytam o biznes, użyj Business Profile. Jeśli pytam o coś osobistego, użyj Personal Profile”.

Claude wybiera, które pliki załadować, bazując na kontekście pytania. Torres może więc być oszczędna w poleceniach. Wystarczy: „Claude, przejrzyj wpis na blogu, daj mi opinię”. Claude analizuje temat, ładuje plik z odbiorcami, sprawdza, którego produktu dotyczy wpis i wydobywa właściwy kontekst.

Analogia Torres: wyobraź sobie szafkę z dokumentami. Musisz wziąć losowego praktykanta z ulicy i dać mu zadanie. Jak strukturujesz szafkę? Jaką instrukcję przyklejasz na górze? To model mentalny dla zarządzania kontekstem.

Torres dodaje istotne rozróżnienie: jeśli pracujemy nad jednym produktem, Claude nie musi wiedzieć o innych produktach. Stąd małe pliki. Wniosek: jeśli rzucisz na biurko 2000-stronicowy podręcznik i powiesz „gdzieś tu jest odpowiedź” – to nie zadziała. Natomiast jeśli zorganizujesz małe foldery z etykietami „jak pisać wpis blogowy”, „jakie mamy produkty” – wtedy praktykant (lub LLM) może być oszczędny i skuteczny jednocześnie.

Partner w pisaniu, nie ghostwriter

Torres kocha pisać, dlatego automatyzacja kontra wsparcie – pytanie, które zadaje sobie przy każdym zadaniu – w przypadku pisania jednoznacznie wskazuje na wsparcie. Nie chce automatyzować pisania.

Istnieją wyjątki. Dwa wpisy blogowe, gdzie LLM wykonał większość pracy pisarskiej. Torres była transparentna co do tego. Pierwszy: wywiady z 11 osobami o używaniu Lovable. ChatGPT przekształcił transkrypty w indywidualne historie. Torres napisała wprowadzenie i zakończenie, a także upewniła się, że brzmi naturalnie. Drugi wpis (miał się ukazać dzień po nagraniu podcastu): tematy z jej podcastu Just Now Possible. Claude wykonał więcej ciężkiej pracy. Jednak to wyjątki od reguły.

Standardowy tok pracy: Torres pisze w Obsidian z Claude Code w terminalu obok. Pisze zdanie i zastanawia się, czy to prawda. „Claude, myślę, że X. Czy są jakieś dowody?” Claude robi badania w tle, podczas gdy Torres wraca do pisania.

Po zakończeniu wprowadzenia: „Claude, napisałam intro. Czy możesz powiedzieć mi, jak wzmocnić zaczep?”. Claude czyta i mówi, co działa, a co nie. Po ukończeniu sekcji: „Claude, przejrzyj sekcję. Co dobre, co nie?”. Opinia nie jest generyczna. Przewodnik stylistyczny definiuje, jak Torres aspiruje pisać, więc Claude krytykuje względem jej własnych celów, które mu przekazała: „Oto jak chcę, żebyś krytykował moje pisanie”.

Ulubiona funkcja? Poprawianie literówek w trakcie pisania. Torres może pisać nonszalancko z błędami ortograficznymi wszędzie, a Claude to czyści na bieżąco.

Dowód: fancy nails. Torres ostatnio sobie na nie pozwala. Wcześniej fancy nails oznaczało wolniejsze pisanie plus więcej błędów, co prowadziło do frustracji. Teraz: fancy nails plus Claude poprawiający literówki równa się zero frustracji. Claire śmieje się, że też ma fancy nails i ludzie widzieli ją „strasznie pisać” w podcastach.

Kiedy Claude pisze samodzielnie? Gdy Torres potrzebuje sprawdzenia faktów lub badań w czasie rzeczywistym podczas pisania. Także gdy potrzebuje opinii na szkic lub ma gotowy tekst do językowego dopracowania. Jednak rdzenne pisanie, przepływ i myślenie – to nadal Torres.

Praktyczne lekcje dla product managerów

Model automatyzacja kontra wsparcie

Przy każdym nowym zadaniu Torres zadaje sobie pytania: czy Claude może to zrobić całkowicie? Czy powinien tylko pomóc? Czy w ogóle chcę to robić, czy wolę oddelegować? To zmusza do refleksji: co lubię robić? Co chcę, żeby robot zrobił za mnie? Im więcej kontekstu dla Claude, tym więcej Claude może zrobić samodzielnie, co stanowi zachętę do dokumentowania.

Torres odkryła, że przez przeniesienie zarządzania zadaniami do Claude, teraz Claude widzi jej zadania. Może dosłownie zacząć dzień od pytania: „Claude, co jest na mojej liście do zrobienia, co możesz po prostu zrobić za mnie?” Albo: „Co jest na mojej liście, gdzie powinnam zastanowić się, jak możesz pomóc?” Nie wszystko spoczywa na niej w kwestii wymyślania, jak używać AI. Claude jest jej partnerem AI.

Strategia /clear gdy AI nie słucha

Torres używa clear nadmiernie często. Gdy Claude się zacina i rozmowa krąży w kółko, nie ma sensu kontynuować. Slash clear. Czysta karta. Start od nowa.

Dlatego pliki kontekstowe są kluczowe. Bez nich każdy restart oznacza ponowne wyjaśnianie wszystkiego. Z nimi restart to czysta karta, ale z pełnym tłem dostępnym na żądanie. Torres zbudowała wskazówki i triki, by stale tworzyć dokumentację tego, co robi, właśnie po to, żeby móc używać /clear bez konsekwencji.

Torres żartuje: szkoda, że nie mogę robić tego w ludzkich rozmowach. Mamy wszystkie informacje, których potrzebujemy. To nie prowadzi nas do porozumienia. Po prostu slash, clear, start.

Co dokumentować i jak

Na zakończenie każdej sesji: „Claude, czego się dzisiaj nauczyłeś, co powinniśmy zapisać?”. Claude wykonuje ciężką pracę. Torres współtworzy, poprawia i weryfikuje. Stopniowo, w czasie. Nie należy próbować stworzyć idealnej biblioteki kontekstu od razu. Trzeba budować stopniowo. Gdy wyjaśniasz coś Claude drugi czy trzeci raz – to znak, że potrzebny jest plik kontekstowy.

Wspólna praca we wszystkim

Inżynierowie robią pair programming. Torres prowadzi wspólne zarządzanie zadaniami, wspólne pisanie, wspólnie wszystko. Ta zmiana mentalności zmienia sposób myślenia o AI. Nie narzędzie do konkretnego celu, lecz partner do każdego przepływu pracy. To kluczowa lekcja z używania Claude Code – idea pair programming z AI rozszerza się poza kod na wszystko.

Indywidualny system zadań

Torres mocno wierzy, że każdy powinien zbudować własny system zadań. Sposób, w jaki zarządzamy zadaniami, jest tak idiosynkratyczny, że to idealny przypadek dla niestandardowego rozwiązania. Może działać dokładnie tak, jak chcesz, czego żadne SaaS nie zapewni. Dlatego jest tyle startupów zajmujących się zarządzaniem zadaniami – każdy chce czegoś innego.

✅ LISTA KONTROLNA: Jak zbudować własny system zadań w Claude Code

Krok 1: Podstawowa struktura

• Stwórz folder Tasks z plikami markdown
• Zdecyduj, jakie pola mają mieć Twoje zadania (termin, etykiety, status)
• Wybierz format front matter (YAML w Obsidian lub inny)
• Ustal taksonomię etykiet i zapisz ją w Claude.md projektu

Krok 2: Polecenie /today

• Napisz polecenie opisujące, co ma robić /today
• Zdefiniuj, jakie zadania mają się pojawiać (dzisiejsze, zaległe, w toku)
• Zdecyduj, gdzie zapisywać codzienny przegląd
• Stwórz slash command w Claude Code

Krok 3: Integracja z istniejącymi narzędziami

• Jeśli używasz Trello/Asana/etc – zdecyduj czy importować dane
• Oceń, które dane potrzebujesz zachować lokalnie
• Zaplanuj migrację lub okres współistnienia systemów

Krok 4: Tworzenie zadań naturalnym językiem

• Wyjaśnij Claude w projekcie Claude.md, jak mają wyglądać Twoje zadania
• Przetestuj tworzenie zadań naturalnym językiem
• Sprawdź, czy etykietowanie działa automatycznie
• Doprecyzuj instrukcje jeśli trzeba

Krok 5: Testuj i dostosowuj

• Używaj systemu przez tydzień
• Po każdej sesji pytaj: „Claude, co powinniśmy udokumentować?”
• Zapisuj wnioski w plikach kontekstowych
• Dopasowuj przepływ pracy do swoich potrzeb

✅ LISTA KONTROLNA: Konfiguracja przeglądu badań (opcjonalny)

Faza przygotowawcza

• Zdefiniuj tematy, które chcesz śledzić
• Stwórz plik konfiguracyjny ze słowami kluczowymi dla każdego tematu
• Przygotuj strukturę folderów: /research/nazwa_tematu/sources i /notes

Automatyzacja wyszukiwania

• Napisz lub dostosuj skrypt Python do przeszukiwania arXiv
• (Opcjonalnie) Dodaj wyszukiwanie w Google Scholar
• Skonfiguruj cron job do codziennych/cotygodniowych uruchomień
• Przetestuj czy wyniki zapisują się poprawnie

Podsumowania artykułów

• Napisz polecenie dla Claude z naciskiem na metodologię i wielkość efektu
• Stwórz wieczorny skrypt szukający nowych PDF-ów
• Zintegruj z poleceniem /today
• Przetestuj przepływ: wyszukiwanie → ręczne pobieranie → automatyczne podsumowanie

Codzienny tok pracy

• Rano: przeglądaj przegląd badań (5-10 min)
• Pobieraj interesujące PDF-y do /sources
• Następnego dnia: czytaj podsumowania w pliku Today
• Zapisuj wnioski do /notes

Inne narzędzia i źródła wiedzy

Oprócz Claude Code Torres używa kilku innych narzędzi:

VS Code – gdy koduje, preferuje IDE z kolorowymi diffami, więc nie zawsze pracuje w ciemnym terminalu.

Descript – do edycji video. Torres uważa, że to jeden z niewielu produktów AI nie pochodzących od firm foundationowych, które naprawdę kocha. Edycja video poprzez edycję transkryptu to według niej najbardziej magiczna rzecz, jaka istnieje.

ChatGPT – okazjonalnie, gdy robi coś w przeglądarce i łatwiej przeskoczyć do ChatGPT niż się przełączać.

Trello – nadal używa do koordynacji z zespołem, natomiast nie do osobistego zarządzania zadaniami.

Nie używa Cursor. Wszyscy pytają dlaczego. Odpowiedź pokazuje filozofię Torres wobec nowych narzędzi: zajmuje się nowym produktem tylko wtedy, gdy odkrywa lukę w obecnej konfiguracji. „Odkrywam lukę i myślę: okay, teraz muszę znaleźć coś, co to wypełni.” Claude Code plus Obsidian plus VS Code działa dobrze, dlatego nie szuka rozwiązania, gdy nie ma problemu.

To jej strategia radzenia sobie ze strumieniem informacji pod presją – nie skakać do nowego narzędzia bez powodu.

Lista życzeń: czego brakuje

LinkedIn MCP. Torres nienawidzi treści generowanych przez AI w komentarzach. Czytanie cudzych tekstów generowanych przez AI, jak sama mówi, trochę łamie jej duszę. Jednak prowadzenie biznesu wymaga obecności na LinkedIn – jak zauważa Claire, jeśli chcesz prowadzić biznes jak one, musisz żyć na LinkedIn. To po prostu rzeczywistość.

Torres chce czytać wpisy i komentować bez logowania się do przeglądarki. Zgadza się nawet na reklamy w strumieniu, jeśli tylko mogłaby konsumować treści z terminala. Problem w tym, że LinkedIn API sprawia, że jest to naprawdę trudne.

Generowanie obrazów z poprawnym tekstem. Torres wie, że to się poprawia, jednak nadal nie jest dobre. Chce generowania obrazów z tekstu, gdzie można poprawnie zamknąć cudzysłów w cytatach na obrazach.

Torres zauważa, że sto razy dziennie myśli „dlaczego nie mogę po prostu zrobić tej rzeczy?”. Jednak generalnie z Claude dochodzi bardzo daleko – Claude potrafi nauczyć ją, jak zrobić cokolwiek.

💡 BIBLIOTEKA POLECEŃ: Sprawdzone komendy Torres

Teresa Torres wypracowała zestaw poleceń, które używa codziennie. Oto konkretne przykłady z jej przepływu pracy:

Zarządzanie zadaniami

Start dnia:

Kiedy stosować: Każdego ranka po wywołaniu /today. Pozwala zidentyfikować zadania, które Claude może wykonać automatycznie bez Twojego zaangażowania.

Dynamiczny widok zadań:

Kiedy stosować: Gdy potrzebujesz szybkiego przeglądu zadań z konkretnej kategorii. Dzięki automatycznemu etykietowaniu Claude może wygenerować widok na bieżąco.

Tworzenie zadania naturalnym językiem:

Kiedy stosować: Zawsze gdy chcesz dodać zadanie bez otwierania GUI. Claude sam ustawi termin, doda etykiety i zaktualizuje strukturę.

Wyszukiwanie i organizacja

Wyszukiwanie zapomnianej informacji:

Kiedy stosować: Gdy pamiętasz, że coś zanotowałeś, ale nie pamiętasz gdzie. Claude przeszuka wszystkie pliki i zaproponuje permutacje Twojego zapytania.

Wyszukiwanie z nieprecyzyjnymi słowami:

Kiedy stosować: Gdy nie pamiętasz dokładnej nazwy. Claude znajdzie najbliższe dopasowanie i zapyta czy to tego szukasz (np. „Article Wednesday”).

Dokumentowanie kontekstu

Po zakończeniu sesji:

Kiedy stosować: Na koniec każdej sesji roboczej. Claude zidentyfikuje co powinno trafić do plików kontekstowych, żebyś nie musiał tego robić ręcznie.

Przepływ pracy przy pisaniu

Sprawdzanie faktów podczas pisania:

Kiedy stosować: Podczas pisania, gdy chcesz zweryfikować swoje założenie. Claude robi badania w tle, a Ty wracasz do pisania.

Opinia na wprowadzenie:

Kiedy stosować: Po napisaniu wstępu. Claude przeczyta i zasugeruje jak wzmocnić zaczep bazując na Twoim przewodniku stylistycznym.

Przegląd sekcji:

Kiedy stosować: Po ukończeniu dowolnej sekcji tekstu. Claude da opinię opartą o Twoje udokumentowane cele i przewodnik stylistyczny.

Oszczędne polecenie z kontekstem:

Kiedy stosować: Gdy masz już zbudowany system plików kontekstowych. Claude sam załaduje właściwe pliki (odbiorcy, informacje o produkcie, przewodnik stylistyczny) bazując na temacie wpisu.

Tworzenie plików kontekstowych

Generowanie przewodnika stylistycznego:

Kiedy stosować: Gdy chcesz stworzyć przewodnik stylistyczny. Nie mów Claude kim jesteś – niech sam przeanalizuje Twoje materiały i wyciągnie wnioski. Potem popraw i współtwórz.

Reset rozmowy

Gdy Claude się zacina:

Kiedy stosować: Gdy rozmowa krąży w kółko i nie prowadzi do rozwiązania. Czysta karta, ale dzięki plikom kontekstowym nie tracisz tła.

Zasady skutecznego formułowania poleceń według Torres

1. Buduj kontekst, żeby móc być oszczędnym

Torres może pisać „Claude, przejrzyj wpis na blogu” bez szczegółów, ponieważ Claude ma dostęp do plików z odbiorcami, przewodnika stylistycznego i kontekstu produktowego. Im więcej kontekstu w plikach, tym krótsze mogą być polecenia.

2. Pytaj „co się nauczyłeś?” zamiast dokumentować samemu

Na końcu każdej sesji Torres pyta Claude co powinno być udokumentowane, więc Claude wykonuje ciężką pracę w tworzeniu plików kontekstowych.

3. Nie bój się /clear

Gdy rozmowa nie idzie w dobrym kierunku – resetuj. Pliki kontekstowe zapewnią ciągłość bez konieczności ponownego wyjaśniania wszystkiego.

4. Używaj naturalnego języka

„New task: dziękuję dla Claire” działa tak samo dobrze jak „create task with title 'thank you’ assigned to Claire with due date today”. Claude rozumie intencję.

5. Pozwól Claude dodawać etykiety automatycznie

Nie dodawaj etykiet ręcznie – Claude zrobi to lepiej i konsekwentniej, jeśli ma dostęp do taksonomii w Claude.md projektu.

Kluczowy wniosek

Inżynieria kontekstu zamiast inżynierii poleceń

Standardowo myślimy: Jakość odpowiedzi AI zależy od umiejętności tworzenia skomplikowanych instrukcji (Prompt Engineering) i każdorazowego, precyzyjnego opisywania zadania w oknie czatu.

W praktyce okazuje się, że: Prawdziwą efektywność daje oszczędne formułowanie poleceń (krótkie, niedbałe komendy), które jest możliwe tylko wtedy, gdy wcześniej zainwestujemy w budowę statycznej biblioteki kontekstu – plików indeksujących, przewodników stylistycznych, map wiedzy.

Dlaczego to jest istotne: Torres może pisać „Claude, przejrzyj wpis na blogu” bez dodatkowych instrukcji, ponieważ model ma dostęp do jej przewodnika stylistycznego, profilu odbiorców i kontekstu produktowego. To przesuwa ciężar pracy z każdorazowego wysiłku poznawczego przy pisaniu zapytania na jednorazową budowę architektury informacji, co eliminuje zmęczenie decyzyjne w codziennej pracy.

Test na jutro: Zamiast pisać długie polecenie z instrukcjami jak poprawić Twój tekst, stwórz jeden plik „Zasady-redakcji.md” z Twoimi wytycznymi. Następnym razem załącz go do kontekstu i napisz tylko: „Popraw to zgodnie z zasadami”. Sprawdź różnicę w czasie i jakości odpowiedzi.

Książki i źródła wspomniane w materiale

• „Continuous Discovery Habits” – Teresa Torres (autorka)
• Blog Product Talk – producttalk.org
• Podcast „Just Now Possible” – justnowpossible.com (wywiady z cross-functional product teams o wdrażaniu AI do produkcji)
• Wpis na blogu Torres: „Claude Code: What is it? How it’s different and why non-technical people should use it”

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: How I AI Podcast – odcinek z Teresą Torres