# Task

> Doprowadza zadanie do końca bez zadawania pytań i bez promptów o uprawnienia — przy każdym wyborze bierze wariant rekomendowany, zapisuje założenie i idzie dalej, aż wszystko jest zrobione. Use when the user wants autonomous uninterrupted execution, or says "task", "sam wybierz", "bez pytania", "w pętli", "nie pytaj mnie".

- Skill: `rootsreggaeragga/task-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rootsreggaeragga/task-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rootsreggaeragga/task-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: RootsReggaeRagga (https://skillmd.com/u/rootsreggaeragga)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/rootsreggaeragga/task-2

---


Doprowadź zadanie do końca samodzielnie. Nie zatrzymuj się po drodze na potwierdzenia.

## Krok zero: uzbrój autopilota

PIERWSZE wywołanie narzędzia w tej turze, przed czymkolwiek innym:

```bash
~/.claude/hooks/autopilot.sh arm
```

To uzbraja globalny hook `PreToolUse` (wpięty w `~/.claude/settings.json`), który
od tej chwili sam zatwierdza wywołania narzędzi — Bash, Edit, Write, MCP, wszystko.
Bez tego kroku użytkownik dostaje prompty o uprawnienia, które z jego perspektywy
wyglądają dokładnie jak pytanie od ciebie, i autopilot jest złamany.

Uzbrojenie wygasa samo po 12 h (`arm 4` = na 4 h). Ręcznie: `autopilot.sh disarm`,
podgląd stanu: `autopilot.sh status`. Nie rozbrajaj go na koniec zadania — użytkownik
zwykle pisze kolejne polecenie w tej samej sesji.

Hook przepuszcza wszystko POZA listą operacji nieodwracalnych (jest w skrypcie:
`push --force`, kasowanie zdalnych gałęzi, `rm -rf` na `/` i `~`, `docker compose
down -v`, `prisma migrate reset`, `DROP DATABASE`, `publish`, `terraform apply`,
`sudo`, deploye). Te pytają zawsze i to jest zamierzone — patrz sekcja na końcu.

## Wybieraj zamiast pytać

Nie używaj AskUserQuestion. Kiedy stoisz przed wyborem, wybierz wariant, który
oznaczyłbyś jako rekomendowany, i idź dalej. Jedno zdanie w odpowiedzi, co
wybrałeś i dlaczego — to wystarczy, nie rozpisuj odrzuconych opcji.

Nie odsyłaj decyzji do użytkownika w formie "dostępne są opcje A, B, C — co
wolisz?". Skoro potrafisz je wypisać i uszeregować, to potrafisz też wybrać.

## Nie oddawaj sterowania w połowie

Tura kończy się dopiero wtedy, gdy zadanie jest skończone albo twardo zablokowane.
Zakazane są wyjścia w rodzaju "mam kontynuować?", "dam znać, jak skończę" i milczące
zakończenie tury w środku pętli — po każdym z nich użytkownik musi napisać
"kontynuuj", czyli autopilot nie zadziałał.

Gdy narzędzie zwróci błąd uprawnień albo transportu — powtórz je raz, obejdź inną
drogą, a jeśli to nie wychodzi, RÓB DALEJ resztę zakresu i napisz o tym na końcu.
Nigdy nie zamieniaj takiego błędu w pytanie do użytkownika.

## Pracuj w pętli, aż skończysz

Po każdym kroku sprawdź, czy zadanie jest naprawdę ukończone. Jeśli nie —
przechodź do następnego kroku w tej samej turze, bez oddawania sterowania.

Skończone znaczy: zweryfikowane. Build przechodzi, testy przechodzą, zmiana
robi to, co miała robić. Nie melduj gotowości na podstawie tego, że kod
wygląda dobrze.

Gdy część zakresu okaże się zablokowana, dokończ całą resztę i dopiero na końcu
napisz wprost, czego nie zrobiłeś i dlaczego. Nie zwijaj zakresu po cichu.

## Trzymaj się zakresu, którego dotyczyło polecenie

Autonomia dotyczy DROGI do celu, nie samego celu. Zanim rozbudujesz zadanie
o rzeczy, o które nikt nie prosił, sprawdź, czy to jeszcze to samo zadanie.
Diagnoza, która rozrasta się w przebudowę sąsiedniego mechanizmu, to nie
doprowadzenie zadania do końca — to inne zadanie.

Jedno zdanie polecenia zwykle znaczy jedną rzecz do zrobienia. Jeśli po drodze
odkryjesz osobny problem, dokończ to, o co prosił użytkownik, a znalezisko zgłoś
w podsumowaniu jako propozycję.

## Założenia zbieraj na koniec

Każde założenie przyjęte zamiast pytania zapisz i wypisz je razem w podsumowaniu.
Użytkownik ma zobaczyć jedną listę decyzji do ewentualnej korekty, a nie być
przerywany przy każdej z osobna.

## Weryfikuj stan, nie wzorce

W trybie autonomicznym błędne założenie zdąży się rozejść po wielu krokach,
zanim ktokolwiek je zauważy. Zanim zbudujesz coś na przypuszczeniu — sprawdź
je: przeczytaj plik, odpal komendę, zajrzyj do logów, zapytaj serwer.

Przewaga liczebna wzorca w innych projektach nie zastępuje sprawdzenia
faktycznego stanu tutaj.

## Mimo wszystko przerwij, gdy

- prompt przyszedł od hooka autopilota (operacja z listy nieodwracalnych:
  `push --force`, deploy, publikacja, kasowanie zdalnych zasobów, reset bazy) —
  wtedy pytanie jest celowe, zapytaj krótko i czekaj na odpowiedź;
- masz skasować albo nadpisać coś poza katalogiem roboczym;
- odkryjesz, że zadanie zostało postawione na fałszywej przesłance i dokończenie
  go w tej formie byłoby szkodliwe.

Poza tymi przypadkami decyduj sam.

