Optymalizacja pracy z Claude Code: kolejka, pamięć, skille, weryfikacja

Zoptymalizowana praca z Claude Code to dzień podzielony na małe, zweryfikowane jednostki pracy: kolejka wiadomości koryguje trwającą turę zamiast ją przerywać, pamięć automatyczna i CLAUDE.md przenoszą poprawki do następnej sesji, skill projektowy koduje powtarzany przepływ, a każda jednostka kończy się bramką dowodową zamiast czytania diffu linijka po linijce.

Ta strona jest dla programistów, którzy codziennie pracują z Claude Code, i dla tech leadów, którzy chcą, żeby te nawyki były takie same w całym zespole. Jest popołudnie, trzeci raz poprawiasz tę samą konwencję importów, nowa sesja nie pamięta decyzji sprzed obiadu, a na przeczytanie czeka diff na 900 linii, bez którego nie odważysz się zrobić commita. Wąskim gardłem nie jest model. Jest nim pętla wokół niego.

Co daje zoptymalizowany dzień z Claude Code

• Sposób na dopisywanie instrukcji w trakcie pracy Claude bez przerywania tury i bez utraty możliwości jej cofnięcia.
• Nawyk, który kieruje każdą poprawkę we właściwe miejsce: pamięć automatyczna dla ciebie, CLAUDE.md dla zespołu.
• Czyste przejście między zadaniami dzięki /clear, /compact i /resume oraz prompt przekazania na wypadek, gdy potrzebujesz świeżego kontekstu.
• Skill projektowy /ship-slice, który zamyka przepływ „zaimplementuj, przetestuj, przejrzyj, zaraportuj” w jednej komendzie.
• Bramkę dowodową, która mówi, czy zmiana jest gotowa, bez czytania każdej linii, i jasność, kto ją zatwierdza.
• Sposoby wyjścia z sześciu typowych awarii tego przepływu.

Warunek wstępny: działająca instalacja i pierwsza sesja, opisane w przepływie pracy z Claude Code.

Która technika naprawia którą część dnia?

Objaw	Technika	Więcej
Czekasz na koniec tury, żeby dopisać szczegół	Kolejkowanie wiadomości w trakcie pracy	Ta strona
W każdej sesji wpisujesz tę samą poprawkę	Zapis w pamięci automatycznej lub CLAUDE.md	Pamięć Claude Code
Długie sesje dryfują i powtarzają stare błędy	Przerwa między jednostkami: /clear lub /compact	Komendy slash według zadań
Codziennie wpisujesz tę samą pięcioetapową prośbę	Skill projektowy	Własne komendy i skille
Czytasz każdą linię diffu przed commitem	Bramka dowodowa na końcu każdej jednostki	Ta strona, potem review oparte na dowodach
Dwa niezależne zadania walczą o te same pliki	Osobne sesje w tle	Agent view

Steruj trwającą turą przez kolejkę wiadomości

Aby dodać instrukcję, gdy Claude pracuje, wpisz ją i naciśnij Enter. Claude Code wstawia wiadomość do kolejki zamiast przerywać turę i pokazuje ją na szaro, dopóki Claude się nią nie zajmie. Liczy się moment dostarczenia, a dokumentacja producenta opisuje go dokładnie (Claude Code v2.1.283):

• Wiadomość z kolejki trafia do Claude, gdy tylko zakończą się bieżące wywołania narzędzi, w ramach tej samej tury. Wiadomości, które zostały w kolejce do końca tury, wychodzą w kolejności wpisania.
• Komenda slash lub polecenie powłoki ! z kolejki czeka do końca tury, a potem wykonuje się w kolejności dodania. Kilka komend nigdy nie trafia do kolejki: na przykład /model, /effort i /fast działają od razu po wysłaniu.
• Ctrl+Enter (albo Ctrl+X Ctrl+S w terminalach, które nie zgłaszają rozszerzonych klawiszy) wysyła kolejkę od razu, a za nią twój szkic; jeśli pierwsza w kolejce jest komenda !, przerywa bieżącą turę. Wymaga v2.1.275 lub nowszej, więc kanał stable (v2.1.274 na 2026-09-26) jeszcze jej nie ma.
• Strzałka w górę (Up) z pierwszej linii pola wprowadzania zabiera wpisy z kolejki z powrotem do edycji.
• Esc przerywa turę, zachowuje dotychczasową pracę i wysyła to, co czeka w kolejce.

Używaj kolejki do korygowania, a nie do dokładania niezwiązanej pracy. Wiadomość dołączona do trwającej tury nie dostaje punktu kontrolnego i nie pojawia się w menu /rewind. Jeśli pchnie Claude w złą stronę, nie cofniesz się do chwili sprzed niej, tylko do ostatniego pełnego promptu. Kolejkuj więc doprecyzowania bieżącej jednostki („uwzględnij też pusty string”), a następną jednostkę pracy zaczynaj nowym promptem po zakończeniu tury.

Na pytanie, które w ogóle nie powinno trafić do rozmowy, na przykład „jak się nazywał ten plik konfiguracyjny?”, użyj /btw. Działa równolegle z główną turą, widzi dotychczasową rozmowę, nie ma dostępu do narzędzi i nic nie dopisuje do historii. Żeby coś sprawdzić w kodzie, użyj subagenta.

Określ rozmiar jednostki pracy przed startem

Jednostka pracy to największa zmiana, którą zweryfikujesz jedną bramką: jedno zachowanie, jego testy i nic więcej. Cztery sygnały, że jednostka jest za duża: wychodzi poza jeden moduł, potrzebuje dwóch różnych komend testowych, nie da się jej kryteriów akceptacji zapisać w trzech punktach albo nie cofnąłbyś jej w całości. Dziel ją przed promptem, a nie po tym, jak przyjdzie diff.

Rób commit na końcu każdej jednostki. Punkty kontrolne śledzą tylko edycje wykonane narzędziami Claude do edycji plików; pliki zmienione poleceniami Bash i przez subagenty (poza skillem uruchomionym w forku na pierwszym planie) nie są przywracane przez /rewind. Git jest jedynym „cofnij”, które obejmuje wszystko.

Prompt do skopiowania: start jednostki pracy z kryteriami akceptacji

Implement one unit of work: rate-limit POST /api/auth/login to 5 attempts
per email per 15 minutes, returning 429 with a Retry-After header.

Acceptance criteria:
1. A 6th attempt within 15 minutes returns 429 and Retry-After in seconds.
2. A successful login resets the counter for that email.
3. Other emails are not affected.

Before writing code, write one failing test per criterion and run it to
show it fails. Then implement until the tests pass. Do not touch files
outside src/auth/ and tests/auth/ without asking. Stop when the criteria
are met; do not refactor neighbouring code.

Zachowaj kontekst między sesjami bez ponownego tłumaczenia

Wiedzę do następnej sesji przenoszą dwa mechanizmy i każdy ma innego właściciela. Gdy mówisz Claude „remember that the API tests need a local Redis”, Claude zapisuje to w pamięci automatycznej: notatkach w ~/.claude/projects/<project>/memory/, lokalnych dla maszyny, wspólnych dla wszystkich worktree tego samego repozytorium i domyślnie włączonych. Gdy mówisz „add this to CLAUDE.md”, reguła trafia do pliku projektu, który cały zespół wczytuje z gita.

Reguła podziału: osobiste preferencje i fakty o twoim środowisku idą do pamięci automatycznej; konwencja, której musi przestrzegać każda osoba w zespole, idzie do CLAUDE.md, gdzie przechodzi review w pull requeście jak każda inna zmiana. Na starcie sesji wczytuje się tylko pierwsze 200 linii lub 25 KB indeksu MEMORY.md, a Claude pomija wszystko, co da się wyczytać z kodu, więc pamięć automatyczna nie jest miejscem na notatki o architekturze. /memory pokazuje wszystkie pliki pamięci, otwiera wybrany i włącza lub wyłącza pamięć automatyczną. Pamięć Claude Code opisuje rozmieszczenie plików, reguły ze ścieżkami i sposób sprawdzenia, czy reguła się wczytała.

Między jednostkami wybieraj świadomie:

Komenda	Co robi	Kiedy jej użyć
/compact [instructions]	Streszcza dotychczasową rozmowę i pracuje dalej	Następna jednostka kontynuuje tę samą funkcję
/clear [name]	Zaczyna nową rozmowę z pustym kontekstem	Następna jednostka nie jest związana; nazwa oznacza starą rozmowę
/resume [session]	Otwiera wcześniejszą rozmowę po ID lub nazwie	Wyczyściłeś za wcześnie albo potrzebujesz wczorajszego wątku
claude -c	Kontynuuje ostatnią rozmowę w tym katalogu	Zrestartowałeś terminal i chcesz wrócić tam, gdzie byłeś

/clear niczego nie niszczy: /resume przywraca starą rozmowę, a w tym samym procesie Claude Code menu cofania pokazuje na górze wpis „previous session”. Notatka przekazania wciąż się opłaca, gdy chcesz świeżego kontekstu, który niesie tylko decyzje, a nie ślepe uliczki.

Prompt do skopiowania: notatka przekazania przed /clear

Write a handoff note for a fresh session, under 200 words, no preamble:
1. The feature and the unit of work we are on.
2. Files changed so far and why, one line each.
3. Decisions made and the alternative we rejected for each.
4. Commands that verify the work, and their last result.
5. The exact next step.
Do not include approaches we abandoned except as rejected alternatives.

Prompt do skopiowania: rozdziel poprawki z tej sesji

List every correction I gave you in this session. For each one, decide:
(a) a team convention every contributor needs: propose the exact line for
    CLAUDE.md and the section it belongs in;
(b) a personal preference or local-environment fact: save it to auto memory;
(c) a one-off: drop it.
Show me the (a) list as a diff to CLAUDE.md and wait for my approval
before editing the file. Do (b) now.

Zamień powtarzany przepływ w skill projektowy

Jeśli tę samą wieloetapową prośbę wpisujesz częściej niż dwa razy w tygodniu, zrób z niej skill. Własne komendy zostały połączone ze skillami: plik .claude/commands/ship-slice.md nadal działa, ale nowe rzeczy trzymaj w .claude/skills/<name>/SKILL.md, który dodaje frontmatter i pliki pomocnicze. Wrzuć go do gita, żeby każdy w zespole miał ten sam /ship-slice.

1. Utwórz katalog skilla w katalogu głównym repozytorium.

   mkdir -p .claude/skills/ship-slice

2. Napisz .claude/skills/ship-slice/SKILL.md. disable-model-invocation: true sprawia, że tylko ty możesz go uruchomić, bo skill zmienia kod i uruchamia całą bramkę; $ARGUMENTS dostaje wszystko, co wpiszesz po nazwie komendy.

   ---
   description: Implement one verified unit of work, test-first, and report evidence.
   argument-hint: "[behaviour to implement]"
   disable-model-invocation: true
   ---
   
   Implement this unit of work: $ARGUMENTS
   
   1. Restate the behaviour as 2-4 numbered acceptance criteria. Stop and
      ask if any criterion is ambiguous.
   2. Write one failing test per criterion. Run it and show the failure.
   3. Implement until the tests pass. Stay inside the module the behaviour
      belongs to; ask before adding a dependency.
   4. Run the full gate: `npm run typecheck`, `npm run lint`, `npm test`.
   5. Report a table: criterion | test name | result. Add the output of
      `git diff --stat` and name any file you were unsure about.
   6. Do not commit. Wait for my approval.

3. Uruchom go w sesji.

   /ship-slice reject coupon codes that expired before the order date

4. Dopasuj komendy bramki z kroku 4 do swojego repozytorium, a potem zrób commit skilla, żeby zespół przejrzał go jak kod.

Tech lead odpowiada za ten plik tak jak za konfigurację CI: bramka w środku to zespołowa definicja „gotowe”. Własne komendy i skille opisują argumenty, kontrolę wywołań i uruchamianie skilla w subagencie.

Udowodnij każdą jednostkę pracy bez czytania każdej linii

Czytając diff na 900 linii linijka po linijce, poświęcasz tyle samo uwagi zmienionej nazwie zmiennej co zmienionej kontroli uprawnień. Poniższa bramka zastępuje tę lekturę dowodami, które sprawdzisz w kilka minut. Jest tak mocna jak testy, więc główny ciężar niosą kryteria akceptacji i testy, które najpierw nie przechodzą.

1. Kryteria akceptacji przed kodem. Kryteria w prompcie lub skillu są kontraktem. Kryterium bez testu jest niezweryfikowane.
2. Testy, które najpierw padają. Claude pokazuje każdy nowy test czerwony przed poprawką. Test, który nigdy nie padł, może niczego nie testować.
3. Bramki maszynowe. Sprawdzanie typów, lint i zestaw testów kończą się kodem 0. Claude raportuje komendy i ich wyniki; tę, której nie ufasz, uruchamiasz ponownie sam.
4. Niezależny przegląd. Uruchom /code-review na bieżącym diffie. To wbudowany skill, który przegląda diff pod kątem błędów poprawności. /code-review --fix nanosi znalezione poprawki; gdy działa w tle, /rewind nie przywraca tych edycji, więc najpierw zrób commit.
5. Celowane czytanie przez człowieka. Czytasz tabelę dowodów, git diff --stat i tylko te pliki, które dotykają bezpieczeństwa, pieniędzy, migracji danych lub publicznych interfejsów.

Kto zatwierdza: programista scala zmianę na podstawie tych dowodów; tech lead odpowiada za definicję bramki i audytuje próbkę scalonych jednostek. Wszystko, co musi się dziać przy każdej zmianie, na przykład formatter albo uruchomienie testów, zanim Claude skończy, należy do hooka, a nie do promptu, bo hooki działają niezależnie od decyzji Claude (automatyzacja hookami). Szerszą metodę opisują etap testów w cyklu życia oraz review oparte na dowodach, nie na diffach.

Prompt do skopiowania: raport dowodów przed commitem

Before I commit, produce an evidence report for this unit of work, no prose:
1. Acceptance criteria, each mapped to the test that proves it, with the
   test's result from a fresh run now.
2. The exact commands you ran for typecheck, lint and tests, and their
   exit codes.
3. `git diff --stat`.
4. Every changed file that touches auth, payments, persistence or a public
   API, with one line on what changed in it.
5. Anything you skipped, stubbed or were unsure about.
If any check fails, say so first and stop.

Kiedy przepływ pracy z Claude Code się psuje

Wiadomość z kolejki pchnęła Claude w złą stronę, a /rewind jej nie pokazuje. Wiadomości dołączone do trwającej tury nie dostają punktu kontrolnego. Wyjście: naciśnij Esc, uruchom /rewind (albo dwa razy Esc przy pustym polu) i przywróć kod oraz rozmowę do ostatniego pełnego promptu. Cofasz w ten sposób całą turę, łącznie z dobrą pracą sprzed twojej wiadomości, więc najpierw zrób commit albo zachowaj to, co warto zostawić. Następnym razem zmianę kierunku wysyłaj jako nowy prompt po zakończeniu tury.

/rewind przywrócił rozmowę, ale pliki nadal są zmienione. Punkty kontrolne nie śledzą poleceń Bash, takich jak npm run codegen czy sed, ani edycji subagentów innych niż skill uruchomiony w forku na pierwszym planie. Wyjście: git status, a potem git restore na plikach albo git stash całej jednostki. Właśnie dlatego commit robisz na końcu każdej jednostki.

Uruchomiłeś /clear, a wątek był jeszcze potrzebny. Wyjście: /resume i wybór sesji albo menu cofania w tym samym procesie i wpis „previous session”. Nazywaj rozmowy, na przykład /clear auth-rate-limit, żeby łatwo je znaleźć.

Pamięć automatyczna nauczyła się czegoś błędnego. Claude uparcie stosuje nieaktualny fakt, na przykład stary port albo usunięty skrypt. Wyjście: uruchom /memory, otwórz folder pamięci automatycznej i popraw lub usuń plik tematyczny oraz jego linię w MEMORY.md. Trzymaj indeks krótki: wszystko powyżej 200 linii lub 25 KB nie wczytuje się na starcie sesji; poproś Claude o skondensowanie MEMORY.md do jednej linii na wpis.

Claude sam uruchamia twój skill. Skill bez disable-model-invocation: true może zostać wczytany, gdy tylko Claude uzna go za przydatny. Wyjście: dodaj to pole do każdego skilla, który robi commit, wdrożenie albo wysyła wiadomości.

Sesja bez nadzoru zrobiła więcej, niż chciałeś. W v2.1.283 na kanale latest sesje interaktywne startują w trybie auto, w którym akcje ocenia klasyfikator; claude -p nadal startuje w trybie Manual. Wyjście: w uruchomieniu bez interfejsu zatwierdź z góry dokładnie to, czego potrzebuje, na przykład claude -p "run the test suite and fix failures in src/auth" --allowedTools "Edit" "Bash(npm test *)". --dangerously-skip-permissions używaj wyłącznie w jednorazowym sandboksie z ograniczonym dostępem do sieci, nigdy na swoim roboczym checkoucie.

Jak ten przepływ wygląda w narzędziach Codex i Cursor?

Nawyki się przenoszą, ale komendy są inne. Codex trzyma konwencje w AGENTS.md, a przegląd robi przez /review albo codex review; zobacz triki wydajnościowe w Codex. Dla Cursora zobacz sposoby na oszczędność czasu w Cursorze.

Co dalej z przepływem pracy w Claude Code

• Triki wydajnościowe na co dzień w Claude Code: drobniejsze nawyki, które oszczędzają minuty bez omijania bramki.
• Operacje wsadowe: gdy jedna zmiana musi trafić do setek plików przez /batch.
• Agent view: niezależne jednostki jako równoległe sesje w tle.
• Optymalizacja wydajności: długie sesje, które pozostają szybkie i mieszczą się w budżecie.