| name | dev-autopilot |
| description | Automatyczny pipeline: execute->review->fix per faza, potem complete i compound. Uzywaj przy 'uruchom autopilot', 'wykonaj caly plan', 'autopilot', 'odpal pipeline'. |
| argument-hint | [sciezka-do-folderu np. 'docs/active/auth-refaktor'] |
| disable-model-invocation | true |
Autopilot — automatyczne wykonanie calego planu
Autonomicznie wykonuje wszystkie fazy zadania: execute -> review -> fix -> nastepna faza -> ... -> complete -> compound.
Zmienne
- SCIEZKA_ZADANIA: $1
- AKTUALNA_FAZA: numer (int) + nazwa bieżącej fazy — utrzymywany jako stan orkiestratora
- cykle_historia: mapa {faza_N: liczba_cykli_fix} — do raportu końcowego
Konfiguracja
- MAX_FIX_CYKLI: 2 (maksymalnie 2 cykle fix->review per faza)
- Licznik
fix_cykl jest LOKALNY dla fazy. Resetuje się na 0 przy przejściu do nowej fazy (krok 1a Execute).
Instrukcje
Faza 0: Inicjalizacja i resume
-
Walidacja git:
git branch --show-current — sprawdz aktualny branch- Przeczytaj wymagany branch z dokumentacji w
$1/ (szukaj "Branch:" w plikach)
- Jesli branch sie nie zgadza — poinformuj uzytkownika i zapytaj czy przelalczyc
git status --short — sprawdz czy nie ma niezacommitowanych zmian
-
Przeczytaj plan i wylicz AKTUALNA_FAZA:
- Przeczytaj
$1/*-plan.md — wyciagnij liste [(numer, nazwa), ...] dla wszystkich faz
- Przeczytaj
$1/*-zadania.md — parsuj statusy checkboxow per faza:
- Faza z WSZYSTKIMI zadaniami oznaczonymi jako ukonczone (
- [x]) = faza UKONCZONA
- Faza z JAKIMKOLWIEK zadaniem nieoznaczonym (
- [ ]) = faza DO_WYKONANIA
- Ustaw
AKTUALNA_FAZA jako pierwsza niekompletna: {numer: int, nazwa: string}
AKTUALNA_FAZA to jawny stan orkiestratora. Kazdy agent (execute, review, fix) dostaje ten numer jako explicit parametr. Nie polegaj na tym ze skille same go wyliczaja.
-
Sprawdz stan review:
- Sprawdz czy istnieje plik
$1/review-faza-{AKTUALNA_FAZA.numer}.md
- Jesli istnieje i zawiera nierozwiazane P1/P2 (sekcja "Do poprawy po review fazy N" w zadaniach ma niezaznaczone checkboxy) → ustaw flage
rozpocznij_od_fix = true
-
Zbuduj kolejke faz:
- Pominj fazy ze wszystkimi zadaniami ukonczonymi
- Zacznij od
AKTUALNA_FAZA
- Jesli
rozpocznij_od_fix == true — przejdz bezposrednio do kroku 1d (Fix), z pominieciem 1a Execute
- W przeciwnym razie zacznij od 1a Execute
-
Wyswietl plan pracy:
Autopilot: {nazwa-zadania}
Fazy do wykonania: X/Y
Faza 1: [nazwa] — UKONCZONA
Faza 2: [nazwa] — DO WYKONANIA (start)
Faza 3: [nazwa] — DO WYKONANIA
Faza 4: [nazwa] — DO WYKONANIA
Rozpoczynam...
Faza 1: Petla Execute -> Review -> Fix
AUTONOMICZNOSC: Dla KAZDEJ fazy z kolejki, wykonaj ponizsze kroki sekwencyjnie. NIGDY nie pytaj usera o kontynuacje miedzy krokami (1a->1b->1c->1d->1e). Po zakonczeniu jednego kroku NATYCHMIAST przejdz do nastepnego. Jedyny powod do zatrzymania sie to STOP w obsludze bledow.
Na poczatku kazdej nowej fazy:
fix_cykl = 0 — zresetuj licznik cykli naprawczych (lokalny dla fazy)- Re-parsuj
$1/*-zadania.md zeby zweryfikowac ze AKTUALNA_FAZA.numer nadal jest niekompletna (stan mogl sie zmienic po poprzedniej fazie)
- Jesli
AKTUALNA_FAZA jest juz ukonczona → inkrementuj do nastepnej niekompletnej
1a. Execute
Uruchom Agent (general-purpose, foreground) z promptem:
Jestes czescia pipeline'u dev-autopilot. Wykonujesz faze implementacji.
Folder zadania: {$1}
AKTUALNA FAZA: numer {AKTUALNA_FAZA.numer} — "{AKTUALNA_FAZA.nazwa}"
Wywolaj skill /dev-docs-execute z argumentem "{$1}".
Uzyj narzedzia Skill: Skill("dev-docs-execute", args: "{$1}").
Skill sam wybiera nastepna niekompletna faze na podstawie checkboxow.
Orkiestrator oczekuje ze wykonana zostanie faza {AKTUALNA_FAZA.numer}
— jesli skill wybierze inny numer, ZATRZYMAJ sie i zglos rozbieznosc.
Wymagania wykonania:
- Zaimplementuj kod dla wszystkich niezaznaczonych checkboxow (z wyjatkiem "Weryfikacja:")
- NAPISZ testy dla checkboxow z prefixem "Test:" RAZEM z kodem
- NIE wykonuj checkboxow "Weryfikacja:" — sa dla Agent 5 w review
- Uruchom pelna walidacje przed commitem (typecheck, test, expo-doctor — NIE eas build, to zbyt drogie)
Nie pytaj uzytkownika o potwierdzenie — dzialaj autonomicznie.
Po zakonczeniu zwroc:
- Potwierdzenie numeru ukonczonej fazy (musi == {AKTUALNA_FAZA.numer})
- Commity (hashe)
- Wynik testow (PASS/FAIL z liczbami)
- Czy byly checkboxy Test: — ile napisano
- Czy byly checkboxy Weryfikacja: — ile pozostaje dla review
- Ewentualne problemy
Po zakonczeniu agenta:
- Zaweryfikuj ze numer fazy zgodny z oczekiwaniem
- Zaloguj:
Faza {AKTUALNA_FAZA.numer} "{AKTUALNA_FAZA.nazwa}": Execute zakonczony
1b. Review
Uruchom Agent (general-purpose, foreground) z promptem:
Jestes czescia pipeline'u dev-autopilot. Wykonujesz code review fazy.
Folder zadania: {$1}
Numer fazy: {AKTUALNA_FAZA.numer}
Wywolaj skill /dev-docs-review z argumentami "{$1} {AKTUALNA_FAZA.numer}".
Uzyj narzedzia Skill: Skill("dev-docs-review", args: "{$1} {AKTUALNA_FAZA.numer}").
Skill uruchomi 5 agentow review rownolegle (security, performance,
architecture, test coverage, E2E browser verification).
Nie pytaj uzytkownika "Czy wykonac poprawki?" — tylko wykonaj review i zwroc wyniki.
Po zakonczeniu zwroc USTRUKTURYZOWANY raport:
- Severity gate: BLOKUJE / ZASTRZEZENIA / CZYSTE
- Liczniki: P1={X}, P2={Y}, P3={Z}
- Typy findingow per severity (klasyfikacja dla fix agenta):
* KOD: ile findingow dotyczy implementacji (bledy logiki, bezpieczenstwa, perf, architektury)
* TEST: ile findingow dotyczy brakujacych/niepoprawnych testow (Test:)
* E2E: ile findingow pochodzi z Agent 5 browser-verifier (Weryfikacja:, oznaczenie 🌐)
- Sciezka do raportu: {$1}/review-faza-{AKTUALNA_FAZA.numer}.md
- Wynik E2E: X passed / Y failed (jesli byly scenariusze Weryfikacja:)
Po zakonczeniu agenta zaloguj statystyki review:
Review Fazy {AKTUALNA_FAZA.numer}: {X}x P1, {Y}x P2, {Z}x P3
Typy: {A}x KOD, {B}x TEST, {C}x E2E
Severity gate: {BLOKUJE/ZASTRZEZENIA/CZYSTE}
1c. Decyzja (orkiestrator)
Przeczytaj plik $1/review-faza-{AKTUALNA_FAZA.numer}.md i $1/*-zadania.md.
Krok 1: Weryfikacja kompletnosci E2E.
Sprawdz czy w $1/*-zadania.md zostaly NIEZAZNACZONE checkboxy Weryfikacja: dla biezacej fazy.
Jesli tak — sprawdz czy raport review zawiera findings dla tych checkboxow:
- Jesli review je zawiera (PASS lub FAIL) → OK, policz severity normalnie
- Jesli review NIE zawiera tych checkboxow (Agent 5 je pominil/skipnal/nie uruchomil sie) → Dodaj kazdy brakujacy checkbox jako P2 z opisem:
🟠 [P2-important] 🌐 Weryfikacja: "{tresc checkboxa}" — pominiety przez review (Agent 5 nie uruchomiony)
Krok 2: Policz findings wg severity (lacznie z dodanymi w kroku 1):
- Sa P1 (blocking): -> przejdz do kroku 1d (Fix)
- Tylko P2 (important): -> przejdz do kroku 1d (Fix)
- Tylko P3 (nit) lub brak: -> przejdz do nastepnej fazy (krok 1e)
Zaloguj:
Review Fazy {AKTUALNA_FAZA.numer}: {X}x P1, {Y}x P2, {Z}x P3
-> {WYMAGA POPRAWEK / CZYSTE — kontynuuje}
1d. Fix (warunkowy)
Petla fix:
Jesli fix_cykl >= MAX_FIX_CYKLI (2) — wykonaj logike wyczerpania cykli:
-
Sprawdz pozostale nierozwiazane problemy w sekcji "Do poprawy po review fazy {AKTUALNA_FAZA.numer}":
-
Przypadek A: Pozostaja P1 (blocking) → STOP:
STOP: Faza {AKTUALNA_FAZA.numer} — po {MAX_FIX_CYKLI} cyklach nadal
pozostaja BLOKUJACE problemy P1.
Nierozwiazane P1:
- [lista z checkboxow]
Wymagana reczna interwencja. Szczegoly w:
- $1/review-faza-{AKTUALNA_FAZA.numer}.md
- $1/*-zadania.md (sekcja "Do poprawy po review fazy {AKTUALNA_FAZA.numer}")
ZAKONCZ AUTOPILOTA.
-
Przypadek B: Tylko P2 (important), zero P1 → GRACEFUL CONTINUATION:
Faza {AKTUALNA_FAZA.numer}: GRACEFUL — wyczerpano {MAX_FIX_CYKLI} cykli,
pozostaje {N} problemow P2 (zero P1).
Severity gate review-skill dla samych P2 = "KONTYNUUJ Z ZASTRZEZENIAMI".
Przenosze P2 do known-issues i kontynuuje do nastepnej fazy.
a) Utworz lub zaktualizuj $1/known-issues.md:
# Known issues po autopilocie
## Faza {AKTUALNA_FAZA.numer} — "{AKTUALNA_FAZA.nazwa}"
Wyczerpano {MAX_FIX_CYKLI} cykli napraw. Pozostaje {N} problemow P2.
Review: review-faza-{AKTUALNA_FAZA.numer}.md
- 🟠 [P2] plik:linia — opis
- 🟠 [P2] plik:linia — opis
b) Dopisz do cykle_historia[faza_{AKTUALNA_FAZA.numer}] = "{MAX_FIX_CYKLI} (graceful P2)"
c) Przejdz do kroku 1e (Nastepna faza) z P2 odnotowanymi jako known issues
W przeciwnym razie (fix_cykl < MAX_FIX_CYKLI) uruchom Agent (general-purpose, foreground) z promptem:
Jestes czescia pipeline'u dev-autopilot. Naprawiasz problemy znalezione w review.
Folder zadania: {$1}
Numer fazy: {AKTUALNA_FAZA.numer}
Cykl naprawy: {fix_cykl + 1} z {MAX_FIX_CYKLI}
Przeczytaj plik {$1}/*-zadania.md — znajdz sekcje
"Do poprawy po review fazy {AKTUALNA_FAZA.numer}".
Przeczytaj takze {$1}/review-faza-{AKTUALNA_FAZA.numer}.md zeby zrozumiec
pelny kontekst kazdego findingu.
Napraw WSZYSTKIE problemy oznaczone jako P1 (blocking) i P2 (important).
Pomin P3 (nit).
=== KLASYFIKACJA FINDINGOW — OBOWIAZKOWA ===
Dla KAZDEGO findingu, NAJPIERW sklasyfikuj jego typ na podstawie
opisu problemu w checklist i raporcie review:
┌─ Typ A: KOD (blad implementacji, bezpieczenstwa, perf, architektury)
│ Sygnaly: finding dotyczy konkretnej linii kodu produkcyjnego,
│ wspomina o XSS, N+1, RLS, typowanie, wzorce, SOLID itp.
│
│ AKCJA:
│ 1. Napraw kod zrodlowy
│ 2. Uruchom odpowiednie unit testy (np. `bun test path/to/test`)
│ 3. Odznacz checkbox w zadaniach (- [ ] -> - [x])
│
├─ Typ B: BRAKUJACY TEST (Test:)
│ Sygnaly: finding mowi "brak pliku testowego", "Test: nie napisany",
│ "brakujacy test dla X", pochodzi z Agent 4 (Test Coverage)
│
│ AKCJA:
│ 1. NIE modyfikuj kodu produkcyjnego — on moze byc poprawny
│ 2. Napisz brakujacy test zgodnie z planem technicznym w docs/plans/
│ (jesli istnieje Implementation Unit z Test scenarios:)
│ 3. Test musi miec minimum 1 asercje. NIE pisz assertion-free testow
│ 4. Uruchom test — musi przejsc
│ 5. Odznacz checkbox
│
└─ Typ C: WERYFIKACJA E2E (Weryfikacja: / oznaczenie 🌐)
Sygnaly: finding pochodzi z Agent 5 (E2E browser-verifier),
checkbox ma prefix "Weryfikacja:", oznaczenie 🌐,
opis wspomina visual regression, responsywnosc,
interakcje, nawigacje klawiatura
AKCJA:
1. Znajdz przyczyne (zwykle w kodzie UI/stylu/a11y/interakcji)
2. Napraw przyczyne
3. Re-uruchom weryfikacje na emulatorze PRZEZ Maestro:
- Sprawdz czy emulator iOS/Android jest uruchomiony
- Sprawdz czy aplikacja jest zainstalowana (preview build)
- Zlokalizuj lub utworz flow YAML: `.maestro/<feature>-<scenario>.yaml`
- `maestro test .maestro/<flow>.yaml`
- Zbierz screenshoty z `.maestro/screenshots/` (zapisz do $1/)
- Zweryfikuj exit code (0 = pass) + ze wszystkie `assertVisible` przeszly
4. Odznacz checkbox Weryfikacja: DOPIERO po Maestro PASS.
NIE odznaczaj na podstawie samego "naprawilem kod" —
to jest antywzorzec (test weakening).
=== KOLEJNOSC NAPRAW ===
1. Napraw wszystkie Typ A (kod) — najszybsze
2. Napisz brakujace testy Typ B
3. Napraw Typ C i zweryfikuj w przegladarce
=== PO WSZYSTKICH NAPRAWACH ===
1. Uruchom pelna walidacje (typecheck, test, expo-doctor — komendy z package.json; NIE eas build)
2. Commituj zmiany: `fix([nazwa-zadania]): poprawki po review fazy {AKTUALNA_FAZA.numer} (cykl {fix_cykl + 1})`
3. Staguj tylko pliki zmienione w tym cyklu fix — nie uzywaj `git add .`
Nie pytaj uzytkownika o potwierdzenie — dzialaj autonomicznie.
Zwroc ustrukturyzowany raport:
- Naprawione: X findingow (A={a}, B={b}, C={c})
- E2E re-weryfikacja: X/Y passed
- Wynik pelnej walidacji: PASS/FAIL
- Commity (hashe)
- Findings ktorych nie udalo sie naprawic (jesli sa) z powodem
Po zakonczeniu agenta:
- Inkrementuj
fix_cykl
- Zaloguj:
Fix Fazy {AKTUALNA_FAZA.numer} cykl {fix_cykl}: naprawiono {X}, pozostaje {Y}
- Wracaj do kroku 1b (Review) — ponowny review weryfikuje skutecznosc napraw
1e. Nastepna faza
Zaktualizuj cykle_historia[faza_{AKTUALNA_FAZA.numer}] = fix_cykl.
Zaloguj postep:
Faza {AKTUALNA_FAZA.numer} "{AKTUALNA_FAZA.nazwa}": UKONCZONA
Execute: OK
Review: {CZYSTE / X poprawek w Y cyklach / GRACEFUL — N P2 do known-issues}
Commity: {lista hashes}
Nastepna faza: {AKTUALNA_FAZA.numer + 1} — {nazwa}
Inkrementuj AKTUALNA_FAZA do nastepnej niekompletnej fazy.
Kontynuuj petle od kroku 1a (z resetem fix_cykl = 0).
Faza 2: Zakonczenie
Po ukonczeniu WSZYSTKICH faz:
2a. Walidacja koncowa
Uruchom Agent (general-purpose, foreground) z promptem:
Wykonaj pelna walidacje calego projektu po autopilocie.
=== KROK 1: Odkryj komendy projektu ===
Przeczytaj konfiguracje projektu zeby ustalic komendy — NIE zgaduj:
1. Jesli istnieje `package.json`:
- Przeczytaj sekcje `scripts` — szukaj: typecheck, lint, test, check
- Wykryj package manager:
* `bun.lockb` → `bun run <script>`
* `pnpm-lock.yaml` → `pnpm <script>`
* `yarn.lock` → `yarn <script>`
* `package-lock.json` → `npm run <script>`
- Jesli brak skryptu typecheck → sprobuj `tsc --noEmit` (jesli tsconfig.json istnieje)
- Jesli brak skryptu test → pomin z adnotacja "brak"
- Stack mobile (Expo): zamiast `build` uzywaj `bunx expo-doctor`. NIE odpalaj `eas build` (cost + czas).
2. Jesli istnieje `Makefile` → uzyj `make <target>` (typecheck, test)
3. Jesli istnieje `pyproject.toml` → uzyj narzedzi Python (mypy, pytest, ruff)
4. Jesli istnieje `Cargo.toml` → `cargo check && cargo test`
Jesli nie mozesz ustalic komend — ZATRZYMAJ i zwroc "brak konfiguracji" jako FAIL.
=== KROK 2: Wykonaj walidacje ===
Uruchom w kolejnosci (zatrzymaj przy pierwszym FAIL, nie kontynuuj dalej):
1. Typecheck: <wykryta komenda>
2. Lint (jesli skrypt istnieje): <wykryta komenda>
3. Test: <wykryta komenda>
4. Validation (mobile): `bunx expo-doctor` (sprawdza deps compat z Expo SDK; szybkie, free)
=== KROK 3: Obsluga bledow ===
Jesli ktores FAIL:
- Przeanalizuj blad
- Jesli mozesz naprawic (np. prosty typecheck, brakujacy import) — napraw, commituj, uruchom ponownie
- Jesli nie mozesz — zwroc liste bledow z lokalizacjami
=== ZWROC USTRUKTURYZOWANY RAPORT ===
- Wykryte komendy: <lista>
- Typecheck: PASS/FAIL (komenda: ...)
- Lint: PASS/SKIPPED/FAIL
- Testy: PASS/FAIL (X/Y przeszlo, komenda: ...)
- expo-doctor: PASS/FAIL (lub n/a)
- Naprawione bledy (jesli byly): lista commitow
- Pozostale bledy (jesli sa): lista z lokalizacjami
Jesli walidacja FAIL i agent nie moze naprawic → STOP z raportem.
2b. Complete
Uruchom Agent (general-purpose, foreground) z promptem:
Jestes czescia pipeline'u dev-autopilot. Archiwizujesz ukonczone zadanie.
Wywolaj skill /dev-docs-complete z argumentem "{nazwa_zadania}".
Uzyj narzedzia Skill: Skill("dev-docs-complete", args: "{nazwa_zadania}").
{nazwa_zadania} to nazwa folderu z $1 (ostatni segment sciezki).
Jesli skill zapyta "Archiwizowac mimo to?" — odpowiedz TAK.
Jesli skill zapyta o /dev-compound — NIE uruchamiaj go (zrobi to orkiestrator).
Nie pytaj uzytkownika o potwierdzenie — dzialaj autonomicznie.
Zwroc:
- Sciezke do archiwum (docs/completed/...)
- Liste zaktualizowanej dokumentacji
2c. Compound
Uruchom Agent (general-purpose, foreground) z promptem:
Jestes czescia pipeline'u dev-autopilot. Dokumentujesz rozwiazane problemy do bazy wiedzy.
Wywolaj skill /dev-compound (bez argumentow, tryb compact).
Uzyj narzedzia Skill: Skill("dev-compound").
Skill automatycznie:
- Wyciagnie kontekst z sesji i git diff
- Sklasyfikuje kategorie problemu
- Zapisze dokumentacje w docs/solutions/<category>/
- Oceni czy problem jest rule-worthy (min 2 z 5 kryteriow)
- Jesli tak → doda regule do .claude/rules/learned-patterns.md
(chyba ze limit 50 regul osiagniety lub duplikat)
Nie pytaj uzytkownika o potwierdzenie — dzialaj autonomicznie.
Zwroc USTRUKTURYZOWANY raport:
- Sciezka do zapisanego pliku: docs/solutions/<category>/<filename>.md
- Kategoria problemu
- Status reguly learned-patterns:
* "dodana: <tytul reguly>" — reguta dodana do learned-patterns.md
* "pominieta: nie rule-worthy" — problem nie spelnial kryteriow
* "pominieta: duplikat" — podobna regula juz istnieje
* "pominieta: limit 50" — osiagnieto limit, zasugeruj /dev-compound-refresh
* "brak — nie udalo sie utworzyc docs" — compound nie udalo sie
Faza 3: Raport koncowy
Zbierz dane ze stanu orkiestratora:
cykle_historia — mapa faz i liczby cykli fix- Wynik walidacji koncowej z kroku 2a
- Sciezka archiwum z kroku 2b
- Sciezka docs/solutions + status reguly learned-patterns z kroku 2c
- Zawartosc
$1/known-issues.md jesli istnieje (graceful P2)
Wyswietl podsumowanie:
Autopilot zakonczony: {nazwa-zadania}
Podsumowanie:
Fazy: X/Y ukonczone
Cykle fix per faza: Faza1(0), Faza2(1 cykl), Faza3(2 cykle, graceful P2), ...
Commity: N
Walidacja koncowa: PASS / FAIL
Archiwum: docs/completed/{nazwa}/
Solutions: docs/solutions/{kategoria}/{plik}.md
Regula learned-patterns: {dodana: "tytul" / pominieta: nie rule-worthy / pominieta: duplikat / pominieta: limit 50 / brak}
Known issues (graceful P2): {liczba lub "brak"}
{jesli sa: lista pierwszych 3-5 problemow z known-issues.md + sciezka}
Problemy wymagajace uwagi: {lista lub "brak"}
Obsluga bledow
| Sytuacja | Reakcja |
|---|
| Agent zwraca blad | STOP. Zaloguj ktora faza i krok sie nie powiodl. Wyswietl blad. |
| Testy nie przechoda po fix | Kontynuuj petle fix (jesli < MAX_FIX_CYKLI). Po wyczerpaniu -> zachowanie zalezy od severity (patrz ponizej). |
| P1 po 2 cyklach fix->review | STOP. Wylistuj nierozwiazane P1 z checkboxow. |
| Tylko P2 po 2 cyklach fix->review | GRACEFUL: zapisz P2 do $1/known-issues.md, kontynuuj do nastepnej fazy. |
| Numer fazy z execute != AKTUALNA_FAZA | STOP. Zaloguj rozbieznosc. Wymaga recznej interwencji. |
| Git conflict | STOP. Poinformuj uzytkownika o konflikcie i sciezce do pliku. |
| Brak faz do wykonania | Przeskocz do Fazy 2 (complete/compound). |
| Skill tool nie dziala w Agent | FALLBACK: Agent czyta .claude/skills/{nazwa}/SKILL.md i wykonuje instrukcje bezposrednio. |
| E2E Agent 5 zwraca FAIL | Traktuj jako P2. Fix agent musi re-uruchomic Maestro flow po naprawie kodu i zweryfikowac na emulatorze przed odznaczeniem checkboxa. |
| E2E Agent 5 SKIP / nie uruchomiony (brak dev server, env error) | Orkiestrator w kroku 1c MUSI wykryc niezaznaczone checkboxy Weryfikacja: i dodac kazdy jako P2. Agent 5 SKIP != brak problemow — to niezweryfikowane wymagania. |
Fallback: Jesli Skill tool nie dziala w Agent
Jesli Agent nie moze uzyc narzedzia Skill (blad, brak dostepu), zmien prompty agentow na:
Przeczytaj plik .claude/skills/dev-docs-execute/SKILL.md.
Wykonaj instrukcje z tego pliku na sciezce {$1}.
Dzialaj autonomicznie — nie pytaj uzytkownika.
Ten fallback zapewnia ze autopilot dziala niezaleznie od dostepnosci Skill tool w kontekscie Agent.
Resumability
Autopilot jest wznawialny. Ponowne wywolanie /dev-autopilot {sciezka}:
- Czyta aktualny stan z
*-zadania.md (checkboxy)
- Sprawdza istniejace
review-faza-*.md
- Pomija ukonczone fazy
- Kontynuuje od ostatniej niekompletnej fazy
- Jesli faza ma review z P1/P2 — zaczyna od fix, nie od execute
Nie wymaga zadnego dodatkowego pliku stanu — caly stan jest w dokumentacji zadania.
