Prospere AI - AI Automation Solutions for Business Growth

Claude /goal — jedna komenda, AI kończy zadanie

Claude /goal: jedna komenda, która zmusza AI żeby SKOŃCZYŁ zadanie

Większość ludzi promptuje Claude jak ChatGPT. Pytanie, odpowiedź, stop. Power userzy używają jednej komendy — /goal — i to zmienia wszystko.

W tym poście pokażę dokładnie:

  • Co robi /goal i jak różni się od /loop i Stop hook
  • 4 zasady, bez których komenda jest bezużyteczna (3 z oficjalnej dokumentacji + 1 z praktyki)
  • 3 sprawdzone prompty do copy-paste (QA, feature, refactor)
  • 5 realnych zastosowań — od overnight bug fixing po migracje API
  • Dlaczego to ekonomicznie zmienia agencję AI

Komentuj GOAL pod karuzelą na moim Instagramie — wyślę Ci pełny toolkit (10 promptów + diagram workflow + cheat sheet best practices) w DM.

Co to jest /goal

/goal to wbudowana komenda w Claude Code (wymaga wersji v2.1.139 lub nowszej). Ustawiasz warunek ukończenia i Claude pracuje dalej automatycznie aż warunek jest spełniony — bez konieczności promptowania każdej iteracji.

Mechanika z oficjalnej dokumentacji Anthropic:

  1. Wpisujesz /goal plus warunek (do 4 000 znaków)
  2. Po każdej turze mały, szybki model (domyślnie Haiku) sprawdza czy warunek jest spełniony
  3. Jeśli nie — Claude startuje kolejną turę z reason'em "dlaczego jeszcze nie" jako wytyczną
  4. Jeśli tak — goal się czyści, w transkrypcji ląduje achieved entry
  5. Podczas pracy widzisz wskaźnik ◎ /goal active z czasem trwania

Evaluator nie wywołuje narzędzi. Ocenia tylko to, co Claude wyniósł do konwersacji. Dlatego warunek musi być czymś, co output Claude'a może udowodnić.

To, co w społeczności programistycznej nazywa się "Ralph loop" — wzorzec, w którym AI samo weryfikuje swoją robotę zamiast deklarować "wygląda OK". Anthropic udostępnił to jako oficjalną komendę.

Czym /goal różni się od /loop i Stop hook

Trzy sposoby utrzymują sesję działającą między promptami. Wybierasz wg tego, co ma uruchamiać kolejną turę:

Komenda Kiedy startuje kolejna tura Kiedy się zatrzymuje
/goal Po skończeniu poprzedniej tury Gdy model potwierdzi warunek
/loop Po upływie określonego czasu Gdy Ty zatrzymasz lub Claude uzna pracę za skończoną
Stop hook Po skończeniu poprzedniej tury Twój własny skrypt lub prompt decyduje

/goal to session-scoped shortcut — działa tylko w bieżącej sesji. Stop hook żyje w pliku settings i działa w każdej sesji w danym scope.

/goal warto łączyć z Auto mode — który zatwierdza wywołania narzędzi w obrębie tury. Auto mode usuwa pytania per-tool, /goal usuwa pytania per-turn. Razem = pełna autonomia.

Pobierz pełen toolkit — diagram workflow + 10 promptów + cheat sheet zasad. Zostaw email niżej, wyślemy PDF na maila.

4 zasady, bez których /goal nie działa

Tu jest haczyk. Jakość komendy = jakość outputu. Oficjalna dokumentacja wymienia 3 elementy dobrego warunku. W praktyce dorzucam czwartą — time budget. Bez wszystkich czterech komenda się zacina, kombinuje albo zatrzymuje przedwcześnie.

Zasada 1 — Measurable end state (mierzalny stan końcowy)

❌ "Popraw kod" ✅ "Wszystkie testy w test/auth przechodzą + lint jest czysty"

Z docs: "one measurable end state — a test result, a build exit code, a file count, an empty queue". Coś, co ma binarną odpowiedź: tak albo nie.

Zasada 2 — Stated check (sposób sprawdzenia)

❌ "Zrób żeby działało lepiej" ✅ "npm test exits 0, coverage > 90%, lint clean"

Z docs: "a stated check: how Claude should prove it, such as 'npm test exits 0' or 'git status is clean'". Konkretna komenda lub stan pliku do weryfikacji.

Zasada 3 — Constraints (ograniczenia)

❌ "Refaktoryzuj API" ✅ "Refaktoryzuj API do v2. NIE usuwaj testów. Max 15 plików zmienionych. Performance ±5%."

Z docs: "constraints that matter: anything that must not change on the way there". Bez tego Claude może "skrócić sobie drogę" — usunąć przeszkadzające testy.

Zasada 4 — Time budget (limit z praktyki, NIE z docs)

❌ Brak ograniczenia czasowego — sesja może się ciągnąć godzinami ✅ Dodaj or stop after 20 turns lub or stop after 60 minutes do warunku

Z docs: "To bound how long a goal runs, include a turn or time clause in the condition". Claude raportuje progress vs tę klauzulę i evaluator ją widzi.

3 prompty do copy-paste

Skopiuj, dostosuj do swojego projektu, odpal w Claude Code z Auto mode włączonym (Shift + Tab cyklicznie w CLI: default → acceptEdits → plan → auto).

Prompt 1 — QA / autonomous bug fixing

/goal all tests in test/auth pass and the lint step is clean, or stop after 20 turns

To minimum. Idealne dla "zostaw na noc, rano sprawdź". Praktyczny use case: po większym merge testy auth padły — odpalasz /goal, idziesz spać. Rano Claude pokazuje co naprawił + reason każdej iteracji w transkrypcie.

Prompt 2 — feature implementation z weryfikacją

/goal implement dark mode matching the Figma spec, all components updated,
test coverage >90%, no console errors, performance impact <5ms on load,
do not modify existing API contracts, or stop after 30 turns

Claude nie tylko buduje feature — musi też udowodnić testami że działa. Dostajesz feature + test coverage + benchmark perf w 1 sesji.

Prompt 3 — refactor / migration

/goal migrate all API calls to the new v2 client, update error handling,
all existing tests pass, add 3 new integration tests, no new TypeScript errors,
do not delete any existing tests, max 25 files changed, or stop after 40 turns

Najtrudniejszy use case — duża migracja. Z /goal Claude robi to systematycznie i sprawdza progres po każdej zmianie.

Ważne komendy operacyjne

Status check

Wpisz /goal bez argumentów żeby zobaczyć:

  • Aktualny warunek
  • Czas trwania
  • Liczba ewaluowanych tur
  • Token spend
  • Ostatni reason od evaluatora

Czyszczenie goal

/goal clear

Aliasy: stop, off, reset, none, cancel. Pełen /clear (nowa konwersacja) też usuwa aktywny goal.

Resume sesji

Sesja zresumowana przez --resume lub --continue przywraca aktywny goal. Resetują się jednak: licznik tur, timer, baseline token spend. Goal już ukończony lub wyczyszczony nie wraca.

Non-interactive mode

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

Działa w headless mode i przez Remote Control.

5 zastosowań w realu

1. Autonomous QA / bug fixing

Klasyk. "Naprawa testów" zwykle zżera 2-3 godziny. Z /goal — odpalasz przed snem, rano gotowe. Sesja 8h Claude'a > 30 min Twojego sprawdzenia.

2. Large refactor / migration

Design system migration, library upgrade, pattern changes w całym kodzie. Tradycyjnie 2-3 dni roboty. Z /goal + jasnymi constraints — pełen sweep w 1 sesji.

3. Feature implementation z proof

Buduj funkcję + udowodnij testami. Bez /goal dostajesz "działa" deklarowane przez Claude. Z /goal dostajesz testy które to potwierdzają — bo evaluator widzi w transkrypcie.

4. Tech debt cleanup z quality gates

Backlog burn-down. Ustaw /goal na "popraw N items z backloga, każdy musi przejść test X, nie wprowadzaj nowych warnings". Claude metodycznie zamyka tickety.

5. Long autonomous sessions

Odpalasz /goal z dużym zakresem przed obiadem albo przed snem (najlepiej w Auto mode), zostawiasz w spokoju. Rano sprawdzasz output i achieved entry w transkrypcie.

Wymagania (z oficjalnej dokumentacji)

/goal nie zadziała jeśli:

  • Wersja Claude Code < v2.1.139
  • W workspace nie zaakceptowałeś trust dialog (evaluator to część hooks system)
  • disableAllHooks jest ustawione na dowolnym poziomie settings
  • allowManagedHooksOnly jest aktywne w managed settings

Auto mode (która pozwala /goal pracować bez przerw na permission prompts) wymaga:

  • Plan Max, Team, Enterprise lub API (NIE działa na Pro)
  • Nie działa na Bedrock, Vertex, Foundry
  • W CLI/JetBrains: cyklowanie przez Shift + Tab (default → acceptEdits → plan → auto)
  • W VS Code: enable "Allow dangerously skip permissions" w extension settings
  • W Desktop: mode selector obok przycisku Send

W każdym przypadku jeśli /goal nie zadziała — komenda powie Ci dlaczego zamiast cicho ignorować.

Dlaczego to zmienia ekonomię agencji AI

Standardowe promptowanie Claude'a — nawet w Claude Code — to często "mid-task drift" i przedwczesne zatrzymywanie. Co naprawiasz przez 3-5 sesji.

/goal kotwiczy Claude'a do persistent success criteria. Claude działa jak senior engineer wyceniany na $200/h — taki, który kończy robotę zamiast mówić "looks good to me, let me know if you need anything else".

Konsekwencja praktyczna dla agencji AI:

  • Wcześniej: 5 sesji × 30 min = 2.5h Twojego czasu na 1 task
  • Z /goal: 1 sesja × 5 min setup + autonomicznie w tle = ~5 min Twojego czasu

To 20-30× improvement w productivity dla typowego refactor / feature task.

Ekonomicznie: zamiast wyceniać projekt na "godziny + nadgodziny ratownicze" — wyceniasz strategię + sprawdzony deliverable. Hours billed → outcome delivered.

Koszt evaluatora jest typowo znikomy w porównaniu do głównych tur (Haiku jako default). Tokeny ewaluatora są billowane na osobnym małym modelu.

Najczęstsze błędy (i jak je naprawić)

Błąd 1 — vague goals → vague output

"Zrób żeby było lepiej" → Claude wymyśla. Nie konwerguje, evaluator nie ma jak ocenić.

Fix: ZAWSZE applicuj wszystkie 4 zasady. Warunek musi być czymś co output Claude'a może udowodnić w konwersacji.

Błąd 2 — brak constraints → Claude kombinuje

Bez "NIE usuwaj testów" Claude może usunąć testy które przeszkadzają, żeby przejść check.

Fix: Wymień explicit jakich rzeczy NIE wolno robić. "Nie usuwaj X, nie modyfikuj Y, zachowaj Z intact, max N plików zmienionych".

Błąd 3 — warunek wymaga rzeczy nieobecnych w transkrypcie

Evaluator nie wywołuje narzędzi. Nie czyta plików niezależnie. Ocenia tylko to, co już zostało powiedziane w konwersacji.

Fix: Każdy warunek MUSI zawierać explicit "show proof" które Claude musi wynieść do transkrypcji. Np. "uruchom npm test i pokaż 0 failures w output".

Błąd 4 — Auto mode wyłączony → Claude pyta o każdą zmianę

Bez Auto mode Claude prosi o approval każdej operacji terminal. Loop się nie zamyka, bo czeka na Twoje OK.

Fix: Włącz Auto mode (Shift + Tab cykluje przez modes w CLI). Wymaga Max/Team/Enterprise/API plan.

Błąd 5 — brak time budget → goal się ciągnie godzinami

Bez or stop after N turns goal może się ciągnąć bez końca jeśli warunek niemożliwy do spełnienia.

Fix: Zawsze dodaj or stop after 20 turns (lub time clause) jako safety net.

Co dalej

Komenda /goal jest jednym z fundamentów które power userzy Claude Code wykorzystują codziennie. Pełen workflow — w połączeniu z /loop, Stop hookami i Auto mode — to autonomous engineering, którego większość agencji jeszcze nie zaimplementowała.

Jeśli budujesz produkt / aplikację / system w 2026 — albo używasz Claude'a w agencji — /goal powinno być pierwszą rzeczą, której się nauczysz po podstawowych promptach.

Komentuj GOAL na moim Instagramie (@prospere.ai_) pod karuzelą o /goal — wyślę Ci pełen toolkit:

  • 10 sprawdzonych promptów /goal (PL + EN) — gotowe do copy-paste, per use case
  • Diagram workflow /goal + /loop + Stop hooks + Auto mode
  • Cheat sheet 4 zasad best practices
  • Bonus: ekonomia agencji z /goal — case study

Albo zostaw email niżej — wyślemy PDF na maila + 5-dniową serię deep-dive'ów (autonomous overnight runs, common pitfalls, jak debugować /goal gdy nie konwerguje).

Źródło oficjalne: code.claude.com/docs/en/goal (Anthropic, weryfikacja 2026-05-21).

Bartek — prospere.ai · linkedin.com/in/bartlomiej-golebiowski