Jedna strona w Linear zastąpiła pięć miejsc, które kiedyś sprawdzałem

O czym jest ten film

1. Autor prowadzi równolegle sześć spraw: kilku klientów, dwie aplikacje mobilne, kanał na YouTube i stronę internetową — sama praca nie jest problemem, problemem jest każdorazowy powrót do projektu.
2. Kiedyś po takim powrocie musiał obkopywać pięć źródeł: notatki w Obsidian, commity, rozmowy z Codexem i Claude Code, kilka agentów naraz oraz zgłoszenia w Linear — żeby wreszcie wybrać następny krok.
3. Dziś cała wiedza o projekcie mieści się w jednym miejscu: w polu opisu projektu w Linear, pod stałą strukturą — stan, decyzje, następny krok, otwarte pytania i data ostatniej aktualizacji.
4. Kartę utrzymuje pętla (Loop): automatyzacja, która po każdej zmianie statusu zgłoszenia uruchamia agenta Linear i przepisuje stronę projektu.
5. Film pokazuje pełne ustawienie od zera: zasianie pierwszej wersji karty z notatek, przetestowanie zachowania agenta w zwykłym czacie i dopiero potem zamianę rozmowy w automatyzację.
6. Kluczowe ustawienie to zezwolenie na zmiany poza zgłoszeniem wyzwalającym — bez niego pętla w ogóle nie może zapisać nic na stronie projektu.
7. Alternatywa — plik ze stanem projektu w repozytorium — jest darmowa i wersjonowana z kodem, ale odświeża się tylko podczas sesji agenta i nie obejmuje pracy nietechnicznej.
8. Koszt to około 15 centów za uruchomienie, a każda zmiana statusu to jedno uruchomienie; przy wielu projektach lub w zespole lepiej przejść na pętlę uruchamianą raz dziennie według harmonogramu.
9. System ma granice: nie zapisze decyzji, której nikt nie odnotował, a karta jest świeża tylko do ostatniej zmiany statusu — niezamknięte zgłoszenie oznacza nieaktualną stronę.
10. Cała recepta sprowadza się do trzech rzeczy: jedna strona na projekt, jedna pętla ją przepisująca i jeden nawyk — zamykanie zgłoszeń po skończonej pracy.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Przy wielu projektach to przełączanie kontekstu boli najbardziej, nie sama praca

Na czym polega: Autor prowadzi sześć spraw naraz i przy każdej z nich praca idzie dobrze. Prawdziwy problem zaczyna się w momencie powrotu — odtwarzanie w głowie tego, gdzie się skończyło, i wybieranie następnego kroku z rozproszonych źródeł.

Jak stosować: Zanim dorzucisz kolejne narzędzie do zarządzania zadaniami, policz, ile minut pochłania ci każde „wracam i przypominam sobie, co było dalej”. Atakuj ten koszt, a nie brak produktywności.

Na co uważać: Standardowy audyt czasu pokaże wykonaną pracę, ale nie pokaże milczącego kosztu odbudowywania kontekstu — ten trzeba zmierzyć osobno.

2.Cały stan projektu mieści się w jednej, zawsze takiej samej strukturze

Na czym polega: W polu opisu projektu w Linear autor trzyma pięć elementów: czym projekt jest, aktualny stan, podjęte decyzje, dokładnie następny krok i otwarte pytania, plus datę ostatniej aktualizacji. Powrót do projektu zajmuje około 30 sekund.

Jak stosować: Ustal sztywną strukturę nagłówków i wypełniaj ją zawsze w tej samej kolejności — wtedy po przerwie czytasz kartę od góry i wszystko masz.

Na co uważać: Struktura działa tylko, dopóki jest zwięzła. Karta przeciążona detalami przestaje być czytelna w pół minuty i wraca problem, który miała rozwiązać.

3.Następny krok ma być wskazany, a nie wyliczany przy każdej okazji

Na czym polega: Autor po powrocie nie wybiera zadania z listy — karta wskazuje jedno konkretne, z linkiem do zgłoszenia. Agent wybiera je według ustalonej kolejności: krok wskazany wprost → to, co jest „w toku” → szczyt kolejki zadań o najwyższym priorytecie → wyraźny zapis „brak następnego kroku”.

Jak stosować: Zapisz tę kolejność w instrukcji dla agenta, żeby wybór był przewidywalny i zawsze według tych samych reguł.

Na co uważać: Jeśli priorytety w zgłoszeniach są zaniedbane, automat będzie podpowiadał złe zadania — porządek w priorytetach to warunek, żeby system w ogóle zadziałał.

4.Zmiana statusu zgłoszenia jako wyzwalacz — karta aktualizuje się sama

Na czym polega: Pętla w Linear uruchamia agenta za każdym razem, gdy zgłoszenie zmienia status. Autor pracuje w Codexie nad zgłoszeniem, pushuje kod na GitHuba — a kartę projektu w Linear przepisuje automatyzacja. Sam nie otwiera Linear.

Jak stosować: Wybierz zdarzenie, które naturalnie towarzyszy skończonej pracy (u autora: zmiana statusu), i niech to ono odświeża stan projektu.

Na co uważać: Pętla reaguje tylko na zgłoszenia — praca wykonana „obok” systemu, bez zmiany statusu, pozostanie niewidoczna.

5.Najpierw wynik w czacie, dopiero potem automatyzacja

Na czym polega: Linear zaleca własną metodykę: uzyskaj pożądany wynik w zwykłej rozmowie z agentem, sprawdź go dokładnie, a dopiero wtedy każ zamienić rozmowę w pętlę. Autor zrobił dokładnie tak — agent pracował w czacie dwie minuty i poprawnie wybrał następny krok, zanim stał się automatyzacją.

Jak stosować: Wklej prompt, obejrzyj wynik, popraw instrukcję — i dopiero po udanej próbie każ stworzyć pętlę z instrukcjami z tej rozmowy.

Na co uważać: Przejście od razu do automatyzacji bez weryfikacji oznacza, że błędną instrukcję pętla będzie powtarzać przy każdym wyzwoleniu.

6.Nową automatyzację twórz wyłączoną i przetestuj ręcznie

Na czym polega: Utworzona pętla była na początku wyłączona — właśnie o to prosił autor. Przejrzał ustawienia, włączył ją i raz uruchomił ręcznie na wybranym zgłoszeniu (49 sekund), sprawdzając, czy karta aktualizuje się z zachowaniem istniejących decyzji i treści.

Jak stosować: Każ automatyzację wprowadzaj w trzech krokach: przegląd konfiguracji w stanie wyłączonym, ręczne uruchomienie próbne, dopiero potem włączenie na stałe.

Na co uważać: Gdy karta zacznie dziwnie wyglądać, zajrzyj najpierw do historii uruchomień pętli — pokaże, który przebieg był ręczny, a który odpaliła zmiana statusu, zanim zaczniesz poprawiać treść na własną rękę.

7.Uprawnienie do zmian poza zgłoszeniem wyzwalającym

Na czym polega: Pętla uruchamia się przy konkretnym zgłoszeniu, ale pisać chce na stronie całego projektu — czyli poza tym zgłoszeniem. Bez włączonej opcji „zezwól na zmiany poza zgłoszeniem wyzwalającym” automatyzacja nie może zapisać na karcie nic.

Jak stosować: Przy każdej automatyzacji piszącej poza swoim wyzwalaczem świadomie włącz to uprawnienie i ogranicz działanie pętli warunkiem do jednego projektu.

Na co uważać: To samo uprawnienie otwiera furtkę do szerszych zmian w danych — bez warunku ograniczającego pętla może ruszyć przy każdym zgłoszeniu zespołu.

8.Plik ze stanem w repozytorium kontra karta w Linear

Na czym polega: Plik state.md w repo jest darmowy, działa offline i jest wersjonowany z kodem — idealny, gdy masz jeden projekt programistyczny, jedno repo i jednego agenta. Ale odświeża się tylko wtedy, gdy sesja agenta coś do niego zapisze, i nie ma pojęcia o pracy, która nie jest kodem.

Jak stosować: Masz jeden projekt kodowy — trzymaj się pliku. Prowadzisz wiele projektów, a duża część pracy to zadania, sprawy cykliczne i zgłoszenia zmieniające status bez żadnego commita — wtedy karta utrzymywana przez pętlę oddaje rzeczywisty postęp.

Na co uważać: Nie mieszaj obu podejść bez zastanowienia — podwójne źródła prawdy o stanie projektu to dokładnie ten problem, który próbujesz rozwiązać.

9.Rozliczaj koszt uruchomień i przy skali przechodź na harmonogram

Na czym polega: Jedno uruchomienie pętli kosztuje około 15 centów, a każda zmiana statusu to jedno uruchomienie — przejście zgłoszenia przez „w toku” i „gotowe” to około 30 centów. Przy pracy solo rachunki są pomijalne; przy wielu projektach albo zespole przestawiającym dziesiątki zgłoszeń dziennie — już nie. Wtedy lepiej ustawić pętlę raz dziennie: czyta zmiany od poprzedniej doby i przepisuje kartę jednym uruchomieniem.

Jak stosować: Zacznij od wyzwalacza na każdą zmianę statusu, a po dwóch tygodniach sprawdź rachunek. Rośnie — przełącz na cykliczne uruchomienie na początek albo koniec dnia.

Na co uważać: Wersja dzienna oznacza, że w ciągu dnia karta zostaje w tyle za rzeczywistością, a pętla budzi się także w dni, w których nie dzieje się nic.

10.System nie zapisze decyzji, której nikt nie odnotował

Na czym polega: Pętla widzi tylko to, co wydarzyło się w Linear. Jeśli praca została skończona, ale zgłoszenie nie zostało zamknięte ani skomentowane, pętla się nie uruchomi — karta zrobi się nieaktualna i przy następnym powrocie pokaże przestarzały obraz.

Jak stosować: Cała recepta: jedna strona na projekt, jedna pętla przepisująca stronę przy zmianie statusu i jeden nawyk — domykanie zgłoszeń po skończonej pracy. Bez trzeciego elementu dwa pierwsze przestają działać.

Na co uważać: Decyzje podjęte w rozmowie czy w głowie musisz odnotować w zgłoszeniu albo na karcie — inaczej dla systemu nie istnieją.

Redakcyjne tłumaczenie

Sześć projektów naraz i jeden prawdziwy problem

Prowadzę sześć rzeczy równolegle: kilku klientów, dwie aplikacje mobilne, ten kanał na YouTube i stronę internetową. Z samą pracą przy każdej z nich jest w porządku. Problem zaczyna się przy każdym powrocie — muszę sobie przypomnieć, gdzie skończyłem. Zaglądam do notatek w Obsidian. Przeglądam commity albo rozmowy z Codexem i Claude Code (Informacja dodatkowa: Codex i Claude Code to agenty programistyczne, które wykonują polecenia i piszą kod bezpośrednio w projekcie.) — czasem z kilku różnych agentów naraz. Sprawdzam zgłoszenia w Linear, jeśli jakieś są. Z tych wszystkich strzępów muszę złożyć w głowie obraz projektu, a potem wybrać następny krok. Dopiero wtedy zabieram się do roboty.

Po wdrożeniu systemu, o którym opowiem, wszystko to wciąż się dzieje — tylko automatycznie, zanim jeszcze otworzę projekt. Karta czeka na mnie gotowa. Wchodzę i w ciągu trzydziestu sekund mam pełny stan projektu oraz jeden następny krok wskazany z góry, więc mogę od razu siadać do pracy.

Jak to wygląda? Wszystko mieszka w Linear. Każdy projekt, przy którym pracuję, ma swoją stronę, a w polu opisu mieści się całość: aktualny stan, podjęte decyzje, dokładnie następny krok, otwarte pytania i data ostatniej aktualizacji. W pół minuty wiem wszystko, co muszę wiedzieć. Pokażę, jak taki system ustawić. Gotowi? Jedziemy.

Powrót do projektu po kilku tygodniach

Załóżmy, że skonfigurowałem to wszystko dawno temu, potem przez kilka tygodni zajmowałem się czymś innym i od tamtej pory nie otwierałem projektu. Teraz do niego wracam i chcę wiedzieć, co powinienem wiedzieć. Ta jedna strona ma mi dać całą odpowiedź.

Najpierw przypomina mi, czym projekt w ogóle jest. Jaki jest stan? Mam sześć otwartych zgłoszeń, nic nie jest w toku, a najwyższy priorytet ma zadanie „kategorie artykułów”. Świetnie — to pewnie jest to, czym powinienem się zająć. Dalej widzę konkretny krok: wdrożyć sześć stałych kategorii artykułów. Jest link do zgłoszenia; klikam i ląduję dokładnie tam. Od razu wiem, co robić dalej. Mam opis zadania, więc mogę przenieść je do Codexa i zaimplementować.

Pętla, która prowadzi notatki za mnie

Pierwszą wersję tej strony napisałem raz, ręcznie, na podstawie własnych notatek. Od tamtej pory całą kartę przepisuje za mnie pętla, którą ustawiłem. Loop — bo tak nazywa się ta funkcja Linear — to po prostu automatyzacja: gdy wydarzy się coś określonego, uruchamia agenta Linear (Informacja dodatkowa: agent Linear to wbudowane w to narzędzie AI, które można prosić o pracę na zgłoszeniach i projektach; Loops uruchamiają je automatycznie w reakcji na zdarzenie.). U mnie tym „czymś” jest zmiana statusu zgłoszenia.

Wróćmy do zadania z kategoriami. Zostało zrobione — wszystkie szczegóły były w zgłoszeniu, a kod poszedł na GitHuba. Jeśli odświeżę stronę na żywo, zmiana już tam jest. Wdrożone, działa. A co tymczasem stało się ze stroną projektu w Linear? Zrobiłem dokładnie jedno: popracowałem w Codexie nad zgłoszeniem i je zaimplementowałem. Linear nie tknąłem wcale.

Gdy teraz wracam i patrzę na kartę, widzę odświeżony stan. Pięć otwartych zgłoszeń. Kategorie artykułów zrobione, wszystko posegregowane, wdrożenie i weryfikacja odnotowane w komentarzu zamknięcia. Wiem, co zostało zrobione — i ta informacja zapisła się sama. Następny krok brzmi: płetwa rekina w stopce ma być w całości widoczna na każdej szerokości ekranu. To ta płetwa na dole strony — przy bardzo szerokich ekranach przycina ją górna krawędź, więc trzeba to po prostu naprawić. I od razu widzę, że to jest zadanie na teraz. Karta zaktualizowała się przy okazji zamknięcia zgłoszenia z kategoriami, które ma już status „gotowe”.

Całość utrzymuje za mnie agent Linear pracujący w pętli wyzwalanej zmianą statusu. A jeśli chcę zobaczyć, co działo się kiedyś, wchodzę w sekcję Loops, wybieram pętlę tego projektu i sprawdzam historię uruchomień. Pierwsze było ręczne, wszystkie następne — automatyczne: jedno odpaliło się przy zmianie statusu z „do zrobienia” na „w toku”, a kolejne przy zamknięciu zadania, i wtedy przepisała się cała karta.

Krok 1: zasianie pierwszej wersji strony

Teraz ustawienie od zera. Projekt „velvetshark.com” w Linear ma na razie puste pole opisu — a po tym procesie będzie w nim mieszkał cały stan projektu i będzie sam się odświeżał. Ten projekt dotyczy wyłącznie pracy nad stroną velvetshark.com, a stan będzie żył właśnie w opisie, bo to pierwsze, co widzę po otwarciu projektu.

Linear zna zgłoszenia dodane do projektu, ale nie zna decyzji, które stały za tymi zgłoszeniami. Te siedzą w moich notatkach w Obsidian, do których Linear dostępu nie ma. Dlatego podaję agentowi dwie rzeczy z notatek: po pierwsze, czym projekt jest i po co istnieje; po drugie, pierwszą porcję decyzji, od których ruszy praca. Wracam do projektu, otwieram agenta i daję mu prompt: czym jest projekt, jak ma być zbudowany opis, które decyzje zasiać — i żeby nie ruszał żadnych zgłoszeń. Uruchamiam. Agent pracował siedem sekund i cała struktura jest już w opisie: czym jest projekt, jaki jest stan (do zaktualizowania — to na razie miejsce zastępcze), pięć decyzji, następny krok (również placeholder), miejsce na otwarte pytania i data aktualizacji. Pierwsza wersja karty pochodzi z moich notatek — wszystkie następne będą się robić same.

Krok 2: najpierw czat, potem automatyzacja

Teraz właściwa część, którą faktycznie chcę zautomatyzować. Linear zaleca własną metodykę: najpierw uzyskaj pożądany wynik w zwykłej rozmowie z agentem, nie w pętli, sprawdź, czy to dokładnie to, czego chcesz, i dopiero wtedy przerabiaj na automatyzację. Tak robię.

Wklejam prompt opisujący, jak system ma działać. Najpierw — czym system jest, a potem — jak wybierać następny krok. Kolejność jest taka: jeśli krok wskazałem wprost, na przykład w zgłoszeniu, bierzemy go i sprawa jasna. Jeśli coś jest w toku, to właśnie to jest następny krok. Jeśli nie — szczyt kolejki zgłoszeń „do zrobienia”. A gdy otwartych zgłoszeń nie ma wcale, karta ma wyraźnie napisać, że żadnego kroku nie zapisano.

Uruchamiam. Agent pracował dwie minuty i zaktualizował opis; zmiany są podświetlone. Sam wybrał mi następny krok: wdrożenie kategorii artykułów — dokładnie to, co chcę robić. Wybrał po najwyższym priorytecie wśród zgłoszeń do zrobienia, czyli tak, jak należy. I to był jeszcze zwykły czat, nie automatyzacja ani pętla.

Krok 3: zamiana rozmowy w pętlę

Skoro wynik z czatu jest taki, jak chcę, każę Linear zrobić z tego pętlę. Wyzwalacz: zmiana statusu zgłoszenia w moim zespole. Warunek: tylko ten konkretny projekt. Instrukcje: na podstawie poprzedniej rozmowy — wszystkie wytyczne są podlinkowane albo wklejone; prompty znajdziecie w opisie pod filmem. Agent popracował dwadzieścia sekund i stworzył pętlę. Na razie wyłączoną — dokładnie o to prosiłem: najpierw przegląd, dopiero potem włączanie. Ta konkretna pętla dotyczy jednego projektu.

Jedno ustawienie trzeba koniecznie sprawdzić: „zezwól na zmiany poza zgłoszeniem wyzwalającym” (ang. allow changes outside triggering issue). Ma znaczenie, bo pętla uruchamia się przy zgłoszeniu, a pisać chce na stronie projektu — czyli poza tym zgłoszeniem. Gdy to uprawnienie jest wyłączone, pętla nie może zapisać na karcie nic. Wszystko wygląda dobrze — czas włączyć. I gotowe: mamy pętlę.

Na koniec uruchamiam ją raz ręcznie, na zgłoszeniu z kategoriami artykułów. Takie odpalenie symuluje sytuację, jakby to właśnie to zgłoszenie wywołało pętlę. Pracowała czterdzieści dziewięć sekund i zaktualizowała stan bieżący, zachowując istniejące decyzje i całą resztę treści. Dobrze. Karta projektu jest świeża. To całe ustawienie.

Dlaczego nie zwykły plik w repozytorium?

Zostaje jeszcze jedna wątpliwość, którą trzeba rozwiać. Jeśli korzystasz z agentów do kodowania, pewnie myślisz: po prostu trzymaj w repo plik state.md (albo jakkolwiek zwał) i każ agentowi go aktualizować. To ma sens — ale plik w repo zmienia się tylko wtedy, gdy sesja agenta coś do niego zapisze, i sprawdza się wyłącznie w projektach, które są kodem. Ja mam kilka projektów, które kodem nie są. Mam zgłoszenia, listy zadań, rzeczy cykliczne — wszystko w Linear — i kiedy ich status się zmienia, chcę, żeby stan projektu też się odświeżył. Nie ma tu żadnego pusha, żadnego commitu, żadnej zmiany na GitHubie, a projekt i tak posuwa się do przodu. I chcę to widzieć na karcie projektu.

Czym zwykły plik jest lepszy? Jest darmowy, działa offline i jest wersjonowany razem z kodem. Jeśli masz jeden projekt programistyczny, jedno repozytorium i jednego agenta — po prostu używaj pliku, to najprostsza droga. Jeśli natomiast prowadzisz wiele projektów, a duża część twojej pracy to nie tylko kod, i chcesz, żeby to wszystko było odzwierciedlone — wtedy taki system jak mój jest właściwszy.

Ile to kosztuje

Dziś pętla uruchomiła się trzy razy i kosztowało mnie to w sumie 43 centy, czyli około 15 centów za uruchomienie. Każda zmiana statusu to jedno uruchomienie — zgłoszenie, które przechodzi przez „w toku” i „gotowe”, kosztuje więc około 30 centów śledzenia. Przy pracy w pojedynkę, jak u mnie, kwoty są pomijalne. Ale jeśli projektów jest wiele albo zespół przestawia dziesiątki zgłoszeń dziennie, odpalanie pętli przy każdej zmianie może się sumować. Wtedy zamiast wyzwalacza na każdą zmianę ustawiłbym pętlę według harmonogramu: raz dziennie, na początku albo na koniec dnia. Agent czyta wtedy, co się zmieniło od poprzedniej doby, przepisuje kartę — i płacisz za jedno uruchomienie na dobę. Haczyk jest taki, że w ciągu dnia karta zostaje w tyle za rzeczywistością, a pętla budzi się również w dni, w których nie dzieje się nic.

Ograniczenia systemu

System ma jedną istotną granicę: pętla nie zapisze decyzji, której nikt nie odnotował. Karta jest też aktualna dokładnie do ostatniej zmiany statusu. Jeśli skończę coś robić, ale nie zamknę zgłoszenia i nie dodam komentarza, pętla się nie uruchomi — strona zrobi się nieaktualna i przy następnym powrocie zobaczę przestarzałą wersję.

Chcesz spróbować? Oto cały przepis. Jedna strona na projekt. Jedna pętla, która przepisuje całą stronę przy zmianie statusu zgłoszenia. I jeden nawyk: zamykanie zgłoszeń po skończonej pracy. Prompty, instrukcje pętli i reguły dla agentów kodujących znajdziesz w artykule podlinkowanym pod filmem. Możesz je skopiować, dopasować do swojego projektu i zacząć używać jeszcze dziś.

Zamiast rozgrzebywania — praca od pierwszej minuty

Tyle w kwestii stanu projektu, nad którym właśnie pracowałem. Jutro wracam do klientów i innych spraw. Ale następnym razem, gdy otworzę ten projekt, nie będę musiał niczego odtwarzać: ani gdzie skończyłem, ani co jest do zrobienia, ani jaka decyzja czeka, ani jakie pytania wiszą w powietrzu. Po prostu siadam i w ciągu trzydziestu sekund zaczynam pracę od tego, co naprawdę ważne. To jest cały system — i tak ograniczam koszty przełączania między sześcioma rzeczami, które mam w życiu.

A skoro karta mówi, że następny krok to płetwa rekina w stopce, to chyba pora ją naprawić. Zdecydowanie trzeba — nie chcę, żeby płetwę przycinało. Jestem przeciw okrucieństwu wobec zwierząt. No to naprawmy.