Claude Code komendy: co naprawdę działa a co zmyślił model?

Ultrathink a ultracode: dwa słowa, cztery wspólne litery

Ultrathink to słowo kluczowe w prompcie działające na jedną turę. Wpisujesz je gdziekolwiek w wiadomości, a Claude Code dokłada do kontekstu instrukcję, żeby model myślał głębiej nad tą konkretną odpowiedzią. Nie zmienia effort level sesji. Nie zmienia wartości effort wysyłanej do API. Nie uruchamia żadnego workflow.

Ultracode to coś zupełnie innego. To ustawienie sesji, które oficjalna dokumentacja definiuje jako ustawienie Claude Code, a nie poziom effort modelu. Wysyła do modelu xhigh i dodatkowo daje Claude’owi zgodę na orkiestrowanie workflow przy każdym poważniejszym zadaniu. Włączasz je przez /effort ultracode. Działa do końca sesji.

Dlaczego to rozróżnienie ma znaczenie

Bo koszt jest inny o rząd wielkości. Ultrathink dokłada trochę tokenów na myślenie w jednej turze. Ultracode może rozdzielić jedno zapytanie na kilkanaście równoległych subagentów, z których każdy ma własne okno kontekstu i własny rachunek. Techniczny sufit to 1000 subagentów na jeden przebieg i 16 działających jednocześnie na typowej maszynie.

Praktyczny model myślowy? Ultrathink to skalpel: precyzja przy jednym trudnym problemie. Ultracode to koparka: kiedy trzeba przekopać cały codebase naraz. Jedno pytanie kontra jedno duże zadanie. Choć trzeba uczciwie dodać, że przy pojedynczej edycji pliku, szybkim pytaniu czy czymkolwiek interaktywnym ultracode jest przerostem formy nad treścią, dokłada opóźnienie i koszt, nie dokładając jakości, a w trakcie działania workflow nie da się wtrącić żadnej instrukcji.

Zauważ ostatni wiersz. Ultracode jest celowo wykluczony z każdego mechanizmu utrwalania: nie ma go w ustawieniu effortLevel, nie przyjmuje go flaga --effort, nie działa przez zmienną CLAUDE_CODE_EFFORT_LEVEL. To nie przeoczenie projektantów, tylko bariera kosztowa. Masz świadomie sięgnąć po ten tryb, a nie zostawić go włączonego na stałe.

Drabinka effort ma pięć szczebli, nie cztery tryby myślenia

Cheat sheet, który dostałem, prezentował „thinking modes” jako progresję: think (2-5 sekund), think hard (5-15 sekund), think harder (15-30 sekund), ultrathink (30-60 sekund). Dodawał, że warianty typu think really hard i think super hard też działają. Ładna tabelka. Kompletna fikcja.

Claude Code wykrywa wyłącznie dokładny token ultrathink. Frazy w rodzaju „think”, „think hard” czy „think more” nie są rozpoznawane jako sygnał do zwiększenia głębi rozumowania. Nie ma progów czasowych przypisanych do słów. Nie ma czterostopniowej skali.

To, co istnieje naprawdę, to drabinka effort: low, medium, high, xhigh, max. Domyślny poziom dla Opus 4.8 to high. Ustawisz go przez /effort w sesji, flagą --effort przy starcie albo zmienną środowiskową.

Nie każdy model obsługuje każdy szczebel

Poziom xhigh działa na Fable 5, Opus 4.8 i Opus 4.7. Na Opus 4.6 i Sonnet 4.6 drabinka kończy się na max. Skoro ultracode wymaga xhigh, na tych modelach po prostu nie pojawi się w menu /effort – od wersji v2.1.160 Claude Code chowa opcję zamiast rzucać błędem.

Jest jeszcze auto. Claude sam ocenia zadanie i dobiera poziom, podnosząc go przy niejednoznacznych albo ryzykownych pracach. Oddajesz kontrolę w zamian za to, że nie musisz kręcić pokrętłem. Dla większości codziennej roboty medium wystarcza i tak. Nie zawsze jednak wyższy poziom oznacza lepszy wynik: kreatywność tekstu zależy bardziej od tego, jak sformułujesz prompt i jakie przykłady podasz, niż od tego, ile sekund model przeznaczy na rozumowanie przed odpowiedzią.

Komendy, o których polskie poradniki milczą

Zacznę od tej, która najbardziej zmienia sposób pracy. /batch rozbija duże zadanie na 5-30 niezależnych jednostek, każda w osobnym git worktree. Migracja pięciuset plików przestaje być jedną długą sesją, która traci wątek po trzeciej kompaktacji.

/goal działa inaczej niż ultracode, choć obie komendy „nie odpuszczają”. Ultracode rozprasza jedno zadanie na wielu agentów równolegle. /goal trzyma jedną sesję przy pracy turę po turze, aż warunek zakończenia zostanie spełniony. Wpisujesz /goal tests pass i Claude pracuje, dopóki testy nie przechodzą. Równoległość kontra wytrwałość.

Reszta, w kolejności praktycznej użyteczności:

• /rewind: cofa sesję do wybranego punktu. Od wersji v2.1.191 potrafi przywrócić kontekst rozmowy sprzed uruchomienia /clear, nie tylko generyczne checkpointy.
• /fork: rozgałęzia rozmowę do nowej sesji. Nie myl z /branch, który dotyczy gita.
• /checkup: audytuje twoją konfigurację. Czyści nieużywane skille, MCP i pluginy, deduplikuje lokalny CLAUDE.md względem wersji z repo, dzieli rozdęty root CLAUDE.md na pliki zagnieżdżone. Każdą zmianę potwierdza z tobą przed zastosowaniem.
• /code-review ultra: najgłębszy wariant przeglądu kodu. Od v2.1.154 /simplify odpowiada za sprzątanie, a /code-review za znajdowanie błędów – wcześniej /simplify był tożsamy z /code-review --fix.
• /loop: powtarza zadanie w interwałach. /loop 5m check if the deploy finished. Ginie razem z terminalem.
• /team-onboarding: generuje przewodnik wdrożeniowy dla nowego dewelopera na podstawie twojego CLAUDE.md, skilli, subagentów i hooków. Wbudowana, nic nie instalujesz.

Ile tego jest? Ponad sześćdziesiąt komend wbudowanych i pięć dołączonych skilli. Dostępność zależy od wersji, planu i platformy – wdrożenia na Bedrock, Vertex czy Foundry potrafią wykluczać konkretne funkcje. Wpisz / w terminalu; zobaczysz dokładnie to, co obsługuje twoja instalacja.

Custom commands to teraz skille

Od wersji v2.1.101 (kwiecień 2026) niestandardowe slash commands zostały scalone ze skillami. Twoje pliki w .claude/commands/ działają dalej, bez zmian. Ale zalecana ścieżka to .claude/skills/nazwa/SKILL.md.

Jeśli skill i komenda mają tę samą nazwę, wygrywa skill. Istnieje .claude/commands/review.md obok .claude/skills/review/SKILL.md? Zadziała wersja skillowa. Warto o tym pamiętać przy migracji, bo cichy cień jednej definicji przez drugą potrafi kosztować godzinę debugowania.

Zmienna $ARGUMENTS nadal łapie wszystko, co przekazujesz po nazwie komendy. Frontmatter YAML pozwala przypiąć konkretny model, listę dozwolonych narzędzi i hooki. Przypinanie wersji modelu w krytycznych komendach to nie paranoja, tylko realna ochrona przed cichym dryfem, kiedy Anthropic zmieni domyślny model.

Jak sprawdzić, czy cheat sheet kłamie: instrukcja

1. Sprawdź numer wersji – jeśli dokument podaje wersję Claude Code, porównaj ją z /release-notes w swoim terminalu. Rozbieżność o sto wersji oznacza, że reszta też jest nieaktualna.
2. Wpisz komendę w terminalu – autouzupełnianie po / pokazuje wyłącznie to, co faktycznie istnieje w twojej instalacji. Komenda, której nie ma na liście, nie istnieje.
3. Szukaj konkretnych liczb bez źródła – „Pro=5/dzień, Max=15/dzień” brzmi wiarygodnie, dopóki nie poprosisz o link. Halucynacje modeli są najbardziej przekonujące właśnie w postaci precyzyjnych liczb…
4. Zweryfikuj zmienne środowiskowe – echo $CLAUDE_CODE_EFFORT_LEVEL nie powie ci, czy zmienna istnieje w kodzie. Ale dokumentacja model-config powie.
5. Nie ufaj narracji – „użytkownicy zbuntowali się po deprecacji, więc funkcja wróciła” to opowieść, nie fakt. Zmiany funkcji są w changelogu; jeśli nie ma ich tam, prawdopodobnie się nie wydarzyły. Sprawdzenie zajmuje minutę, a oszczędza wieczór debugowania komendy, której nigdy nie było.